This post is the second in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements in the Metasploit Framework over the course of 2013.
If you are reading this blog post, I reckon you are somewhat a geeky security person, and you use some sort of application like KeyPass, Keychain, LastPass, etc, to manage your passwords. After all, we all know too well password stealing is a major security issue, and sometimes this is more than enough to get you to all kinds of wonderful places like the domain controller, the CEO's laptop, and all the goodies along the way. It also makes my heart die a little (in a good way, I guess?) when I hear professional penetration testers compromising the entire network by just stealing passwords, reuse or pass-the-hash and all that, while we spend intense amount of time building awesome exploits that they don't actually have to use. I mean, come on, man! :-) But of course, Metasploit creates more than just exploits, it covers the whole offensive package, so password stealing is definitely always on the menu.
Recently, I came across an article from SecureList about the discovery of Apple Safari storing session states un-encrypted. The "ah-ha, jackpot!" moment kicked in because stuff like this is such an easy win, and I decided to take a look. The problem is simple: So Apple Safari has this feature that allows you to reopen all the windows from last session with a click on a button, and the magic behind that is by storing these session states in a file named LastSession.plist. This is a binary property list that can be manually converted into a more human readable format by using the built-in plutil command in OS X, and then your session data can be found encoded in Base64. And you don't really have to be a computer genius to decode this, there are tools available online, just let me google that for ya.
And yes, I also just described how to write that module. I have been told the best crackers in the world can write this under 60 minutes, but fortunately I've already written it for you, so you can steal this under 60 seconds. Woohoo!
Another eye-candy thing is the researcher of the discovery (Mr. Vyacheslav Zakorzhevsky) demonstrated stealing a Gmail credential with the flaw, his screenshot is this:
Look closely, and you'll see words like "Email=kaspersky_login&Passwd=kaspersky_passwd", "application/x-www-form-urlencoded", "accounts.google.com"... yeah, those are quite lovely. In case you're curious where this data is from, you can simply find it in Google's login form, specifically at https://accounts.google.com/ServiceLogin, I hope you like HTML:
To trigger Safari storing your session data, here's an example of how to do that safely in case you want to test it yourself:
- Go to https://accounts.google.com/ServiceLogin
- Enter an invalid username and password, click "Sign In"
- Google should tell you the credential is bad, now press refresh.
And now that session state should be stored in ~/Library/Safari/LastSession.plist. If you're lazy like me, you can just run Metasploit's post/osx/gather/safari_lastsession module:
The above test was conducted against Apple Safari version 7.0.1 (9537.73.11) on OS X 10.9.1. Yes, it is the latest version of Safari. Yes, someone did say this was patched in Safari 6.1, except not really. We've already informed the appropriate party to verify this patch information, and I'm sure this will be resolved shortly. Meanwhile, if you are a Safari user, please do this:
- Open Safari
- On your top left corner, click on "Safari" -> "Preferences"
- Click on the "Privacy" tab, and you should see the following - I want you to click that "Remove All Website Data" button real hard and make sure your LastSession.plist is cleared:
Last but not least, if you're still wondering if LastSession.plist is still storing some sensitive data, you can always run the Metasploit module and test it out yourself. Metasploit can be downloaded here if you're new to the game. If you are already a Metasploit user, please make sure to run the msfupdate and that baby will be yours.
Oh, and if you do actually extract some username/password, remember to clear your ~/.msf4/loot/ directory. Because the username/password (in plain text) will be stored there, too. The post module should tell you precisely where this file is.