Cloudflare and Dome9 Blacklister Scripts (Bash/Python)
One of my servers was under attack from an IP in China recently (some lame automated SQLi), but I figured I’d blackhole the source IP anyway.
My first step was to blacklist in Dome9, which I use to manage that server’s firewall, but after noticing that the attacks were still hitting my server I remembered that because I also use Cloudflare and those attacks were getting tunnelled through their network. So the solution (for that particular attack) was to also blacklist the source IP in Cloudflare. When another stupid attack came in a day or so later, I did the same and realised that it would be much easier if I automated the whole process.
So I threw together a Bash script (and then a Python script) that leverages the Cloudflare and Dome9 APIs to submit a given IP address to one or both services.
I’ve put these into my scripts repo on GitHub. Simply insert your Cloudflare and/or Dome9 API keys into the configuration portion of the script and go. Using this you could conceivably fully automate it by auto-detecting brute-force type attacks using a script on the server and calling this script to make the blacklist updates.
Bearing in mind these were very hastily put together, any feedback/improvements are welcome!
Revoking Chinese CNNIC Root Certificate in Mac OS X
Earlier this month, Google and Firefox both dropped the Root Certificate of Chinese Certificate Authority CNNIC, after it was discovered that it had delegated its authority to an Egyptian intermediary to allow it to fraudulently sign SSL/TLS certificates for the google.com domain (presumably for the purposes of performing man-in-the-middle attacks and snooping on Egyptian internet traffic).
Apple, despite releasing Mac OS X 10.10.3 and iOS 8.3, has yet to remove this rogue CA. I hope that Apple joins in and revokes the CNNIC in an upcoming update, but in the meantime you can remove it from OS X yourself!
Simply run the following command in the Terminal and *poof*, another unnecessary and untrusted CA bites the dust:
sudo security delete-certificate -c "CNNIC ROOT" /System/Library/Keychains/SystemRootCertificates.keychain
It’s worth pointing out that a deleted Root CA cert may re-appear in a subsequent system update (I will check when 10.10.4 comes out). The alternative to this, which can only be achieved using Keychain Access (I believe), is to tell OS X to never trust a given Root CA certificate – a setting that shouldn’t be undone by future updates. To do this:
- Open Keychain Access
- Click on ‘System Roots’ on the left
- Right-click on the Root CA you don’t trust (ie. CNNIC ROOT) and select Get Info
- Expand the ‘Trust’ section
- Select ‘Never Trust’ from the “When using this certificate” dropdown
- Close the panel (OS X will probably ask for your password to authenticate the change)
- You should then see a red X icon next to the untrusted cert.
I personally think that our operating systems and browsers already trust far too many Root CAs, many of which are unnecessary, others are potentially malicious. OS X by default trusts around 204 Root CAs. I’m planning on cutting this down to a short list of CAs that are both (a) trusted and (b) necessary for normal day-to-day use of the Internet. I’ll report back on that when I get time.
Unfortunately, there is no mechanism in iOS to remove certificates from the Root CA store. The list of current trusted Root CAs in iOS can be found here.
Honeyport Python Script with Local Firewall and Dome9 Support
Following on from my linux bash honeyport script (read this first if you don’t know what a Honeyport is), I wanted to write a script that works across platforms to accept connections on a given port and block that IP using the local firewall – IPFW on Mac OS X, iptables on Linux, or Windows Firewall – or using the Dome9 service (I’m hoping to add Unix support soon).
I chose to write this one in Python as the cross-platform language of choice, and it’s compatible with Python 2.7 to 3.4. One feature of this script is that you can optionally configure it to run another Python script whenever a client connects to the honeyport. The client’s IP will be passed to the called script as an argument, allowing you to do whatever you want with it. The script’s output is then sent back to the connected client before they are blacklisted.
Check it out on GitHub, improvements and additional ideas are welcome!
Flashback Malware Exploiting Unpatched Java on Macs [Updated]
There’s a piece of Mac malware, known as ‘Flashback’, that’s going around and takes advantage of a Java vulnerability in order to compromise and infect Macs online. Although the vulnerability isn’t Mac-specific, and was patched back in February, Apple has yet to distribute that update to everyone via Software Update, leaving everyone vulnerable.
Apparently the team behind this malware is quite efficient at updating it, and so they have been successful in spreading it around. Lion doesn’t come with Java by default, so unless you’ve manually installed it, you’re safe. If you have installed Java on Lion however, I don’t know yet whether Lion’s built-in anti-malware is being updated quickly enough to keep up with the new malware variants (although I highly doubt it).
If you are running Snow Leopard (or earlier), or Lion with a manually-installed Java, then the best thing to do is disable it. The majority of web users do not need Java on a regular basis. I recommend disabling Java system-wide by going to Applications > Utilities > Java Preferences and then unchecking all the checkboxes in the General tab. If you use Safari to browse, you can disable Java by going to Safari > Preferences > Security and unchecking ‘Enable Java‘.
Keep an eye out for an upcoming Java update from Apple.
[Updated] Seems all the talk about this has nudged Apple to act! They’ve released Java for OS X Lion 2012-001 and Java for Mac OS X 10.6 Update 7. F-Secure have released a free Flashback remover tool, and Apple have announced they are also working on software to detect and remove Flashback malware.
Source: F-Secure
Apple Releases Slew of Security Updates (OSX, Safari, iTunes, iOS 5, aTV)
I wasn’t going to post about last week’s fairly significant iTunes update, but then Apple went and patched a whole bunch of vulnerabilities across the board. Some of these are fairly significant so I thought I would provide a short breakdown of the changes. Either way, you should definitely be patching all of your Apple devices and software tonight.
Hit the jump for a summary of the key vulnerabilities patched in Apple’s security updates.
Extracting and Cracking Mac OS X Lion Password Hashes [Updated]
The Defence in Depth blog has a post about a flaw in Lion’s redesigned authentication mechanisms and Directory Services. In short, it is possible to change the password of the currently logged in user by simply running the following command in the terminal, and it won’t ask you for the user’s current password:
$ dscl localhost -passwd /Search/Users/<username>
In Lion it is also easy to dump a user’s SHA-512 password hash using the following command:
$ dscl localhost -read /Search/Users/<username>
Then look for the dsAttrTypeNative:ShadowHashData chunk in the output (sample below). The hex string in red is the salt, and the green is the hash.
62706c69 73743030 d101025d 53414c54 45442d53 48413531 324f1044 74911f72 3bd2f66a 3255e0af 4b85c639 776d510b 63f0b939 c432ab6e 082286c4 7586f19b 4e2f3aab 74229ae1 24ccb11e 916a7a1c 9b29c64b d6b0fd6c bd22e7b1 f0ba1673 080b1900 00000000 00010100 00000000 00000300 00000000 00000000 00000000 000060
Cracking password hashes can be done using his custom Python script, or John the Ripper (with the Jumbo patch). Note that even if someone manages to obtain your password hash, if you’re using a strong password it will be extremely difficult for them to recover it. Seems like both of these are important but fairly low-risk flaws introduced into Lion. Hopefully Apple will look into these for the next update.
[Update 1] While waiting for an Apple-supplied security update, it is possible to protect yourself from this vulnerability by adjusting the permissions on dscl:
sudo chmod go-x /usr/bin/dscl
This makes it so that only root can execute dscl. To revert this simply run:
sudo chmod go+x /usr/bin/dscl
[Update 2] This vulnerability was patched in Mac OS X 10.7.2.
Security Update 2011-005 Fixes DigiNotar SSL Vulnerability
Apple has finally issued Security Update 2011-005 to address the recent issues around compromised Dutch certificate authority DigiNotar. It was discovered that at least 531 fraudulent SSL certificates were issued by DigiNotar, leading to their root certificate being revoked in all major operating systems and browsers over the past two weeks. A man-in-the-middle attacker in possession of one of these certs (eg. Google, Skype), would be able to intercept SSL-encrypted traffic to those sites. It is believed that the use of these fraudulent certs may have been limited to the Iranian government.
This patch removes the DigiNotar CA from the trusted root certificates in the Mac OS X keychain (which is also used by Safari) for Lion and Snow Leopard. Unfortunately no patch has been issued for Leopard (10.5) users, leaving them at a heightened risk from these bad certificates. It is recommended that Leopard users delete the DigiNotar CA certificate from the Keychain using the following steps:
- Open Keychain Access (/Applications/Utilities/Keychain Access)
- Click on the System Roots keychain in the top-left hand panel
- Click on Certificates in the bottom-left hand panel
- Type DigiNotar into the search field in the top right.
- Right-click on the DigiNotar Root CA, and select Delete.
# sudo /usr/bin/security delete-certificate -Z C060ED44CBD881BD0EF86C0BA287DDCF8167478C /System/Library/Keychains/SystemRootCertificates.keychain
Firefox users should update to the latest version of Firefox. Here is the full Apple description for this update:
Security Update 2011-005
- Certificate Trust Policy Available for: Mac OS X v10.6.8, Mac OS X Server v10.6.8, OS X Lion v10.7.1, Lion Server v10.7.1Impact: An attacker with a privileged network position may intercept user credentials or other sensitive information
Description: Fraudulent certificates were issued by multiple certificate authorities operated by DigiNotar. This issue is addressed by removing DigiNotar from the list of trusted root certificates, from the list of Extended Validation (EV) certificate authorities, and by configuring default system trust settings so that DigiNotar’s certificates, including those issued by other authorities, are not trusted.
Lion + LDAP = Authentication Bypass
Around a month ago, Mac OS X Lion (10.7) was found to have a fairly severe vulnerability when configured to use an LDAP server for authentication. In such a configuration, the system accepts any username or password upon login. This affects both the user interface, but also remote login such as SSH. This issue does not affect normal Lion users who haven’t set up an LDAP server.
Details of the issue aren’t well known, and as much as I’d like to reproduce the issue, I’m too lazy to set up an LDAP server to do it. My guess is that OSX queries the LDAP server, but a bug in the authentication and authorization code makes it so that the user is granted access regardless of whether a login failure is received from the server. I’ve heard reports that it’s possible to login using any non-existent username (with some errors about invalid home directories), but then it begs the question: who do you end up logged in as, and what privileges do you have? If you login with a known username, then you get access in the context of that user. I can’t say for certain, but this vulnerability should not allow a user using an invalid password to gain access to network resources that rely on that user’s authentication credentials, just the local system.
Apple hasn’t yet acknowledged the issue as far as I know, and it’s surprising that no patch was issued with 10.7.1. Perhaps a fix will come in the form of a security update, or the upcoming 10.7.2 update. In the meantime, consider disabling LDAP authentication on Lion systems to prevent unauthorised access.
Grabbing OSX Passwords Through FireWire
There was a lot of attention given to yesterday’s news of Passware Kit Forensic v11 being able to extract your Lion login password if your computer was locked or sleeping, even with FileVault turned on. It’s worth pointing out that not only is this old news (from 2006), it isn’t even a vulnerability specific to Mac OS X, but rather a vulnerability introduced on computers with FireWire (or iLink) ports. The FireWire specification provides external devices with the interesting ability to interact directly with system memory (without going through the OS). While in theory this could open up interesting uses, in reality it just enables vulnerabilies due to the fact that a computer’s live memory can be used to extract data or manipulate parameters. Windows systems are vulnerable to this attack too, and there are tools (eg. winlockpwn) that exist that allow an attacker to unlock a locked Windows machine, or dump its memory, just by plugging into it via FireWire/iLink.
This flaw definitely has security and privacy implications, but only if the attacker is able to get physical access to your computer. As I’ve pointed out on a number of occasions, if someone gets phsysical access to your computer, it’s game over. Even without a FireWire port, techniques such as the Cold Boot Attack may allow an attacker to recover passwords or decryption keys from live memory. Until Apple completely phases out FireWire in favour of Thunderbolt, this will continue to be an issue to be aware of. Thunderbolt itself, although not fully tested, may yet be found to have some similar issues; although I’m hoping Apple/Intel will have learnt from past mistakes.
There’s not a huge amount you can do to protect yourself apart from:
- Disable automatic login, and shut down your computer when you don’t plan on using it (especially if you’re going to be away from it for a while). Note that for this to really be effective, you’ll need to enable FileVault as well – otherwise the attacker will be able to access your unencrypted HD.
- Block your FireWire port with epoxy – or destroy it altogether.
OS X Lion Released, Brings Improved Security
As you will know by now, Apple has release Lion (OSX 10.7) to the orgasmic jubilation of Mac fans everywhere. Ok, perhaps I exaggerate, but Lion was probably the most anticipated release of OSX since Leopard. Critics will argue that the number of major new features are limited, but in my opinion it’s the refinements that make Lion a great update. And for what it’s worth, the Mac App Store update process went perfectly smoothly on my iMac.
Most importantly, however, are the security improvements that Apple have made to the OS. Leopard and Snow Leopard already had some of these features, but they were not fully developed. In Lion, it seems, many of those issues have been fixed. In fact Lion has been said by several security researchers to now offer superior security over competing operating systems. I’ve said for a while that Apple will wait until OSX is really stable before properly addressing security. It appears Lion is the start.
I’ll start off with the most user-visible security features:
- FileVault 2: Whereas FileVault on Snow Leopard only encrypted users’ home folders (using disk images), leaving the System and Applications vulnerable to attack, Lion now has true block-level Full Disk Encryption (XTS-AES 128 algorithm). FileVault 2 also supports full disk encryption of external USB and FireWire drives. One key new feature is Lion’s “Instant Wipe”, which will allow you to wipe the hard-drive should your computer fall into the wrong hands. Similar to iOS devices, this may tie in to the new Find My Mac functionality.
- Privacy Controls: Apple has sprinkled around some additional privacy controls, giving the user more say in how their data is stored or used. There’s now full control of which applications can make use of the Location Services features of OSX.
- Apple ID Authentication: This is an interesting feature that makes it easier for users to share content with others. Normally actions like Screen Sharing and File Sharing require the connecting user to have an account on the system. Now, you can simply add their Apple ID as an authorised account to give them selective access. It will be interesting to test how this actually works in practice.
- Application Sandboxing: Lion’s sandboxing capability has been greatly improved. Safari, for example, has been updated to include sandboxing, meaning that website content loads in a separate process with limited functionality. This help prevent malicious websites from gaining access to the underlying system. Apple is encouraging third party software developers to start sandboxing their applications.
- Full ASLR: This is a big one. Address Space Layout Randomization is a technique to make exploitation of vulnerabilities more difficult by not using fixed memory addresses for key data areas. In Snow Leopard, ASLR was half-baked and essentially broken. In Lion, it appears that Apple have finally implemented full ASLR (covering 32 and 64-bit application), although how well is yet to be fully determined. Either way this will present an additional barrier to exploits.
Loading ...
