TAG | computer security
Engineers at Golden Frog recently discovered that Cricket wireless was automatically disabling their email encryption.
It is not at all clear why they were doing this, but we do know how. When an email client attempts to make a secure connection to a server, it sends a STARTTLS command. If the server never sees the STARTTLS, then it assumes you just wanted an insecure connection. (more…)
Arstechnica reports on the discovery of signed malware designed for surveillance on the Mac laptop of an Angolan activist.
The malware was a trojan that the activist obtained through a spear phishing email attack. The news here is that the malware was signed with a valid Apple Developer ID.
The idea is that having all code signed should substantially reduce the amount of malware on the platform. This works because creating a valid Apple Developer ID requires significant effort, and may expose the identity of the hacker unless they take steps to hide their identity. This is not trivial as the Developer ID requires contact information and payment of fees.
The second advantage of signed code is that the Developer’s certificate can be quickly revoked, so the software will be detected as invalid and automatically blocked on every Mac world wide. This limits the amount of damage a given Malware can do, and forces the attacker to create a new Apple Developer ID every time they are detected.
This has been seen to work fairly well in practice, but it is not perfect. If a target is valuable enough, a Developer ID can be set up just to go after that one person or small group. The malware is targeted to just them, so the likelihood of detection is low. In this case, it would continue to be recognized as a legitimates signed valid application for a very long time.
In the case of the Angolan activist, it was discovered at a human rights conference where the attendees were learning how to secure their devices against government monitoring.
The Washington Post has a good article on social engineering attacks. It is a good treatment of the topic.
Short answer, humans are the weak link, and can be defeated with extremely high probability.
The take away from this whole thing is that we need to be building security systems that don’t rely on humans not being tricked into compromising their own security. A lot of security architects take a “blame the victim” stance. User’s have other things to worry about than security. We need to make sure security happens even if they are not paying attention to it.
Despite all the work on dual factor authentication and other new security methodologies, in general our passwords are the keys to the kingdom.
In many cases, such at ATMs, we are limited to 4 digit numeric PINs.
This post to DataGenetics does a good job of analyzing how bad we are at picking PINs and how easy we make things for the attackers.
It is worth a read.
Short answer: you can hack a over 10% of accounts by guessing “1234”.
Here is a really nice analysis of the recent security breach at Lockheed Martin. The short version is that is looks like their SecureID tokens got duplicated. This is almost certainly related to the security breach at EMC / RSA.