Information Security News
On Monday, a federal judge in Nebraska sentenced the former acting director of cybersecurity for the US Department of Health and Human Services to 25 years in prison on child porn charges.
Timothy DeFoggi, who was convicted back in August 2014, is the sixth person to be convicted in relations to a Nebraska-based child porn Tor-enable website known as PedoBook. That site’s administrator, Aaron McGrath, was sentenced to 20 years last year by the same judge. McGrath famously did not have an administrator password, a mistake that federal investigators were easily able to make use of.
DeFoggi's attorneys did not immediately respond to Ars' request for comment, but he was almost certainly unmasked via an FBI-created malware exploit designed to expose him and other PedoBook users.
by Lee Hutchinson
Ladar Levison is probably most well-known to Ars readers as the founder of the secure e-mail service Lavabit, which he shut down in mid-2013 in an effort to avoid being forced to comply with a US government demand to turn over users’ e-mails. But his latest project is a lot grander in scope than a single hosted e-mail service: Levison is attempting, with the aid of some fellow crypto-minded developers, to change e-mail at large and build encryption into its fundamental nature.
As one of the members of the Darkmail Technical Alliance, Levison—along with Jon Callas, Mike Janke, and PGP designer Phil Zimmermann—is working on a project collectively referred to as DIME, the Dark Internet Mail Environment. DIME will eventually take the form of a drop-in replacement for existing e-mail servers that will be able to use DMTP (the Dark Mail Transfer Protocol) and DMAP (Dark Mail Access Protocol) to encrypt e-mails by default.
Conceptually, DIME applies multiple layers of encryption to an e-mail to make sure that the actors at each stage of the e-mail’s journey from sender to receiver can only see the information about the e-mail that they need to see. The e-mail’s author and recipient both know who sent the message and where it was bound, but the author’s e-mail server doesn’t—it can only decrypt the part of the message containing the recipient’s e-mail server. The recipient e-mail server knows the destination server and the recipient, but it doesn’t know the sender. So if you arrange the four steps in a line from left to right—author, origin server, destination server, and recipient—each step in the line is only aware of the identity of the entity directly to its left or right.
An interesting discussion is occurring on reddit on whether Secure Shell (SSH) should be deployed on a port other than 22 to reduce the likelihood of being compromised. One interesting comment is that security by obscurity is not a security measure, but a way to delay the attacker, so it provides little value. While it is true that it is difficult to stop a determined attacker who is targettingyou, any measure that stops the random script kiddies and scanners from poking at your SSH is not completely useless.
The truth is that I have been deploying SSH on non-standard ports (typically 52222) for more than 15 years on the Internet facing servers I manage. Of course this is not the only security measure I employ. use hosts.allow where practical, keys and passphrases instead of passwords, and deploy DenyHosts. Do I deploy on a non-standard port because of the security advantages to be had by security by obscurity? Not at all! I deploy SSH on a non-standard port because it eliminates all the noise that is every present on port 22. The continual scanning and attempted brute forcing of SSH that has been on the Internet since the beginning of time, and seems to get worse every year, generates a lot of noise in the logs and is at best a nuisance and at worst service affecting for the server. Why put up with it if you dont have to?
It decreases the volume so much that I often have to test my defenses to be sure they are working.
-- Rick WannerMSISE- rwanner at isc dot sans dot edu- http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Gogo has been caught issuing a fake digital certificate for YouTube, a practice that in theory could allow the inflight broadband provider to view passwords and other sensitive information exchanged between end users and the Google-owned video service.
Normally, YouTube passwords, authentication cookies, and similar site credentials are securely encrypted using the widely used HTTPS protocols. A public key accompanying YouTube's official HTTPS certificate ensures that only Google can decrypt the traffic. The fake certificate Gogo presents to users trying to access the video site bypasses these protections, making it possible for Gogo to decipher data. It has long been Gogo's policy to block access to streaming sites and other bandwidth-intensive services. A company official said the fake YouTube certificate is used solely to enforce the policy and not to collect data intended for YouTube. Security and privacy advocates criticized the technique anyway, characterizing it as heavy-handed.
The certificate came to light late last week when Adrienne Porter Felt, an engineer in Google's Chrome browser security team, posted a screenshot of the HTTPS certificate Gogo issued her when she visited YouTube. Rather than being signed by a recognized certificate authority, the credential was signed by Gogo itself. In fairness to Gogo, the fake certificate would generate warnings by virtually all modern browsers. Still once users click an OK box, the bogus credential would allow Gogo to decrypt any traffic passing between end users and YouTube.
A CIO's 7 new year's resolutions
ITWorld Canada (blog)
Clearly, each of these organizations has a large infosec budget, but were not able to sufficiently protect their clients' data. This is the year to redouble efforts to protect our organization's data. 3. Acknowledge. IT work is difficult. Very ...
Google goads Microsoft as Project Zero pokes holes in its program patching
"Security researchers have been using roughly the same disclosure principles for the past 13 years (since the introduction of 'Responsible Disclosure' in 2001), and we think that our disclosure principles need to evolve with the changing infosec ecosystem.
Google Discloses Unpatched Windows Vulnerability
Social Engineering: The dangers of positive thinking
CSO Online recently spoke to a person working in the security field with a rather unique job. He's paid to break into places, such as banks and research facilities (both private and government), in order to test their resistance to social engineering ...
Google Discloses Unpatched Windows Vulnerability
"Security researchers have been using roughly the same disclosure principles for the past 13 years ... and we think that our disclosure principles need to evolve with the changing infosec ecosystem. In other words, as threats change, so should our ...