I would like to start off by stating that I take no pity on the individual this story is about. I refer to them as oblivious because to do what they did simply can’t be categorized in any other way.

Let’s back up a week. I’ve been in need of another Android device to do some tinkering with, have a backup for my daily driver, and to have something that my son can play with and not fear total destruction (again of the daily driver). After checking with friends and co-workers if they had any spares – they didn’t – I resorted to Ebay. Long story short, I found an LG Optimus S – a rather sturdy little phone for its age for $7 plus $4 shipping. The description said that it did not boot. Being the hacker that I am, I generally don’t let simple statements like that deter me.

A few days later I had the phone in my mailbox. It even included the battery, which I wasn’t expecting. I attempt to boot it up, and as described – it doesn’t boot. I plug it in to ensure it has a charge. It won’t charge. I pull out the voltmeter and quickly determine the battery is junk. Fast-forward two more days after a visit to Amazon (Prime). A new battery is awaiting me in my mailbox. Plug it in, viola, Android magic!

Immediately after boot up I notice the first notification is a voice mail. Seems the user never did reset the device. Being nosey, I check the notification. Something about John borrowing the truck for an extra day. I hope Sam¹ didn’t miss that voice mail. I check the contacts, and once again, it is full of names and addresses of people I’ve never heard of. Popping into the app drawer, I notice that not only does all the user data remain, but so do the apps. At this point I’m ready to simply go ahead and do a hard reset as I have zero interest in any of the previous owner’s old apps or information. But then this catches my eye:

Chase Android App

That’s right, the Chase Banking app. Immediately, my heart sinks. I already start to dread what I presume I’m going to find. I open the app, click the login button, and literally face-palm. Username jxxxxx, Password ********. The user’s login details were saved in the application. I’m now one click away from being in someone else’s bank account. At this point I’m feeling extremely paranoid, and my white-hat mindset kicks in. I pull the battery, put it back in, and proceed to hold the home key, volume down key, and power it into the recovery screen. A couple more volume clicks later, and the device is completely formatted and returned to its factory settings. The old data is wiped.

As I mentioned, I was already fairly certain as to what I was going to find before ever even entering into that Chase app. Why? Most people do not understand the consequences of their actions, especially when it comes to security. Nor do they even consider it when dealing with the majority of technical things they do on a day-to-day basis.

So for those of you wondering, let’s review some of the steps that Sam¹ should have taken.

1. Upon boot up, the device went straight to the launcher. No pin, password, or swipe gesture was required. You should always protect your devices with some sort of locking feature. This is especially true if you have sensitive data stored on your device. If you use your device to access your company email or remotely connect to your company network, this should definitely be part of the company policy. It’s easy to configure within Exchange as well.
2. The user stored sensitive credentials within apps. Storing your password for something like your gaming account is one thing. Even allowing Android to automatically log into your email is a little risky, but saving the username AND password to your banking application? That’s just asking for trouble. NEVER store credentials in any application that you wouldn’t want someone else having access to! End of story.
3. The user sold a device (knowingly) without performing a reset or wiping the data. This policy holds true for more than just cell phones. But let’s face it; we are all even more connected to our phones today than ever before. I’d go as far as to say some even use them more than their actual computers (for personal tasks). If/when you sell electronic devices, you should always perform a format, or wipe of all stored data, whether this is a factory reset of a phone, a format and reinstall of a laptop OS, or even a full DoD multiple pass wipe. Always destroy your data before releasing your devices to the public.
4. The fact that Sam¹ even had his banking app on his phone can be viewed as a flaw – but I’ll let that one slide. I personally choose not to keep anything on my devices that can associate me to what my banking information may be. I go even as far as to ensure that any emails I get from my banks are sent to an email address that isn’t associated with my default Android account. Paranoid, perhaps. Secure, you bet!

I will take a slight bit of leniency on Sam¹ based solely on the fact that he thought the device was toast. But this is even more reason why you should take the steps necessary to ensure the device is wiped clean before getting rid of it. And for the average Joe (Sam) it’s not always obvious how to do these tasks. I had to look it up myself for this specific device (Android tends to vary the button combination per device). But in this case because the phone wouldn’t boot with the dead battery, Sam wouldn’t have even been able to perform the reset without some other form of digital magic.

Moral of the story: Wipe your devices, lock your devices, and don’t store credentials to sensitive information!

¹ Sam is a made up name, unless his name really was Sam, in which case it is purely coincidental.

The Underground Economy: Priceless (pdf) touches on the subject in a great amount of detail, even explaining the importance of reputation and the lengths people take to avoid prosecution.

Essentially, public and private servers host communities of individuals who offer their services for a fee. Maybe one person will help someone else cash out an entire bank account (for a 50% cut). And maybe another person will deliver ill-purchased goods to a safe location (for a 30% stake). In the mix are also those who initially did the work (or wrote the code) to capture the information, as well as people who specialize in forging IDs, curious researchers, law enforcement… the list goes on. Compromised financial data seems to lead to a very deep chain of events that attracts many people with varying skillsets, most of whom are simply offering to perform the same hustle(s) over and over. It is a system where both information and skills are bartered/exchanged and high risk is accepted for high returns on investment.

But not all participants are highly skilled– there should be some low-hanging fruit in there too, right? Surely, there are people who aren’t as cautious or who miscalculate their risk of exposure, yet we still have trouble keeping up with even a fraction of the online fraud. While I’m glad we are focusing efforts on preventing information from being compromised in the first place, I feel like there is a growing opportunity to focus a lot more research on thwarting these high-risk behaviors directly. Sometimes you have to treat both the symptom and the cause.

Remove a CA Cert from Android System
The bouncycastle library will be required, you can grab it here:
BouncyCastle Library

You’ll need the Android-SDK as well in order to utilize ADB. It can be found here if you don’t already have it:
Android SDK

1. Move the jar into the $JAVA_HOME%\lib\ext folder. It’s most likely in a place like this:
    

   C:\Program Files (x86)\Java\jre6\lib\ext\

    

2. Connect your USB cable to your phone and verify with adb that it is seen as attached. [%android-sdk% is the location of the Android SDK installed on your system]
    

   %android-sdk%\tools> adb devices

    

3. You’ll need to grab the cacerts.bks file from your phone using adb:
    

   %android-sdk%\tools>adb pull /system/etc/security/

   cacerts.bks cacerts.bks

    

4. Now let’s extract the cacerts.bks to a human readable format (there are other ways of reading bks files, but this is an easy route)

 

%android-sdk%\tools>"%JAVA_HOME%\keytool.exe" -keystore

cacerts.bks -storetype BKS -provider org.bouncycastle.jce

.provider.BouncyCastleProvider -storepass changeit -v

-list > calist.txt

 

5. Open the newly created calist.txt file and search for the desired CA Cert ( DigiNotar CA in our case). You’ll want to identify the alias name number. You’ll use this to identify the certificate so that you can remove it with keytool.exe:

 

*******************************************
Alias name: 61

Creation date: Feb 8, 2011

Entry type: trustedCertEntry

Owner: C=NL,O=DigiNotar,CN=DigiNotar Root CA,E=info@diginotar.nl

Issuer: C=NL,O=DigiNotar,CN=DigiNotar Root CA,E=info@diginotar.nl

Serial number: c76da9c910c4e2c9efe15d058933c4c

Valid from: Wed May 16 17:19:36 UTC 2007

until: Mon Mar 31 18:19:21 UTC 2025

Certificate fingerprints:

MD5:  7A:79:54:4D:07:92:3B:5B:FF:41:F0:0E:C7:39:A2:98

SHA1: C0:60:ED:44:CB:D8:81:BD:0E:F8:6C:0B:A2:87:DD:CF:81:67:47:8C

Signature algorithm name: SHA1WithRSAEncryption

Version: 3
*******************************************

 

%android-sdk%\tools>"%JAVA_HOME%\bin\keytool.exe" -keystore

cacerts.bks -storetype BKS -provider org.bouncycastle.jce.

provider.BouncyCastleProvider -storepass changeit -v -delete

-alias <alias name number>

 

For example:

%android-sdk%\tools>"%JAVA_HOME%\bin\keytool.exe" -keystore

cacerts.bks -storetype BKS -provider org.bouncycastle.jce

.provider.BouncyCastleProvider -storepass changeit -v

-delete -alias 61

 

You’ll probably want to repeat this process for the Comodo certificates as well if you’re really security minded (of course you are).

6. Once you’ve removed the certificate you can push the cacerts.bks back to your phone for usage:

 

%android-sdk%\tools>adb remount

 

%android-sdk%\tools>adb push cacert.bks /system/etc/security/

 

7. The final step will require you to reboot your phone so that Android can reload the cacerts.bks.
8. Enjoy!

If you have root access and don’t feel like going through ADB and all the SDK installation, the GuardianProject has created an Android app (CACertMan) that is targeted at doing the above for you and letting you manage your certs yourself. You can check it out here. It is still in beta and isn’t 100% compatible yet, hence the manual instructions above.

Another case of a certification authority (CA) issuing a certificate they never should have has surfaced. You may remember when we discussed the Comodo incident earlier this year. Now, a certificate issued by DigiNotar has surfaced in the wild, being valid for *.google.com – meaning it could be used to secure any transaction with any Google web property, including GMail. According to this pastebin post, this certificate “is being used in the wild against real people in Iran *right* now.” DigiNotar has issued a statement. Here is some information about why this is bad, and what steps you should take to remove this issuer from your trust lists.

What does this mean?

SSL, or TLS, is used to perform two things. First, it provides authentication of the web server to the web browser. (It can optionally provide authentication of the browser to the server, too, but that’s less common.) This means that the web browser knows that it is talking to a trusted web server and can share sensitive information with it. Second, it provides transport-layer encryption, so that the communications between the web browser and the web server are encrypted. This means that other parties cannot read what is being sent between the server and browser. This is widely used for most logins, because you don’t want your username and password being sent to the server “in the clear”. Anything sent “in the clear” can be read by anyone else on your network (or within range of your wireless network), or by anyone on any network that your traffic is routed through between you and the server.

In this case, a fraudulent certificate has been issued for *.google.com by a certification authority which is completely trusted by most modern web browsers. This means that the web browser will see this certificate, consider it valid for all traffic with Google (and GMail), and go ahead and create that little lock icon everyone has been trained to look for, which indicates your communication is secure.

Except, it’s not.

Google does not own this certificate. Google did not pay for this certificate. Therefore, when you communicate using this certificate, it’s not with Google. It’s with whoever managed to get that certificate issued, which according to the pastebin, is by groups wishing to do harm to individuals in Iran.

Personally, I don’t want to take a chance on whether it might be used against me, as well.

What should I do about it?

It is my opinion that issuance of a certificate such as this is an unforgivable sin.  Certification authorities must have the appropriate technical controls, and checks and balances, to prevent this from ever happening. There are plenty of certification authorities out there, and it is time to remove this one from my system and all systems I manage.

The good news is that the browser manufacturers also think this is a bad thing and are rushing to put together information on how to ensure you won’t trust this certificate.

• Mozilla is updating Firefox, Seamonkey, Thunderbird, and others to remove this; they also provide a link for manual removal.
• Apple hasn’t stepped up with information about it yet that I can find. If you’re running a Mac OSX machine, you should set your system to never trust the Diginotar certificate. Run Keychain Access, and on the left choose your “login” keychain. Down below, choose “All Items”. Then in the search box, search for DigiNotar. You should see one or two results for DigiNotar Root CA. Double-click it. Expand the Trust arrow, and where it says “When using this certificate:” choose Never Trust. Close the window and you will likely be prompted to enter your password to update the login keychain. Repeat for all occurrences of DigiNotar certificates. Update: It’s worse than I thought. This method does not work for EVSSL certificates in Safari. See this link for more information. Stay tuned for any updates Apple might make about this, a patch to Safari is probably necessary.
• Microsoft tells you you’re protected if you’re running Vista or later. If you’re not and still running XP or Windows 2000/2003, you should remove the certificate manually. The easiest way to do this is to launch Internet Explorer, and choose Tools->Internet Options. (Or just launch “Internet Options” from your control panel.) Go to the Content tab and click the Certificates button. Click the Trusted Root Certification Authorities tab. Find the DigiNotar Root CA and double-click it. (If it’s not there, you’re safe!) Click the Details tab and click the Edit Properties… button. Choose Disable all purposes for this certificate and click OK.
• Google Chrome users, you will benefit from the rapid updates to Chrome which will mark DigiNotar as untrusted. You can (should?) also take the Apple or Microsoft manual removal steps above to be sure you’re safe.

Additional good commentary (as always) from Moxie Marlinspike and Jacob Appelbaum.

Now, the biggest loss from someone stealing my netbook is in data; the hardware really isn’t all that expensive. My netbook doesn’t just contain personal information; it’s also full of important business data. I can and do perform regular backups to make sure I don’t lose any of the data, but I don’t want anyone else reading what I’ve got, either.

That’s where file encryption comes in. If properly encrypted, my data won’t be accessible even if someone has the hard drive. So, with that in mind, I’m looking at three different utilities for encrypting my drive:

TrueCrypt – TrueCrypt is kind of the grand-daddy of Whole Disk Encryption; it’s currently on release 7. Being free for download, it’s rather popular. It offers a range of features, including the ability to perform whole disk encryption, and the ability to create hidden volumes and hidden operating systems, meaning that even if you’re compelled to divulge passwords, your attacker won’t know about these volumes and thus won’t know to get access to them. In addition, TrueCrypt comes with a pretty impressive set of encryption algorithms, including AES-256.

AxCrypt – Another piece of freeware, AxCrypt doesn’t offer quite as much as TrueCrypt. Unlike TrueCrypt, AxCrypt exists for encrypting files and doesn’t have a whole disk option. Also, it’s limited to AES-128 which is not bad but certainly not as secure as 256. It seems to have a bit more open UI, however, letting users execute scripts on it. It’s also more oriented toward online shares and network storage – so if you want to put encrypted files on online repositories, AxCrypt may be the one for you.

PGP – The third tool I’ve been looking at is Symantec’s PGP. Unlike the other two, PGP costs – roughly 90USD per license. What do you get for $90? Well, it looks like it’s not a bad piece of software. As with TrueCrypt, Whole Disk Encryption is an option. It also has centralized management options, so it seems the best of the three for large-scale implementations. In addition, it has a host of certifications, notably FIPS 140-2 compliance. If you’re in an environment where that’s required, this is likely the way to go. While the online information is not immediately forthcoming on encryption algorithms, FIPS-140-2 compliance means that at minimum it offers AES-128.

For my purposes, I’m likely going to use TrueCrypt. AxCrypt and PGP both have their place. But the most important thing? Implement something. It’s easy to put off such a step, but you never know when your mobile device might be lost or stolen.

The “attack” (if you can really call it that), required a logged in user to simply modify the URL of an authenticated session to change a plaintext URL parameter containing their account number to another account number. That was all that was required – no coding, phishing, social engineering or other technique that requires any thought was needed. Anyone with a rudimentary understanding of how URL parameters work could have figured this out. I’m amazed nobody figured it out sooner.

What bothers me about the article, though, is that the “expert” and law enforcement representatives who are quoted make it sound like this was a sophisticated intrusion.

One expert, who is part of the investigation and wants to remain anonymous because the inquiry is at an early stage, told The New York Times he wondered how the hackers could have known to breach security by focusing on the vulnerability in the browser.
He said: ‘It would have been hard to prepare for this type of vulnerability.’
…
Law enforcement officials said the expertise behind the attack was a ‘sign of what is likely to be a wave of more and more sophisticated breaches’ by high-tech thieves.

(Emphasis added)

Nothing about changing a plaintext URL parameter requires expertise, and it would have been trivial to prepare for that kind of vulnerability. It’s nigh unbelievable that a financial institution would have such a bad security implementation, although if this is the state of expertise in this field, I suppose I shouldn’t be as surprised as I am.

It’s ironic: Apple computers were the predominant home computers when computer virii and malware were invented. And yet, the first malware kit for the MAC OS (or, more accurately, OS X), Weyland-Yutani BOT, was only released earlier this month. For obvious reasons, I’m not about to download it and play around, but preliminary reports indicate that this kit may have caused a significant increase in OS X malware. And supposedly, kits for iPad and Linux are just around the corner.

To be honest, I find the iPad more disturbing. An increased awareness of mobile OSes in the black hat community can only mean more malware for those platforms. Various experts have been predicting widespread malware in mobile devices like phones and tablets for some time now. With the release of Weyland-Yutani BOT, we’re that much closer. The exact development cycle for such kits is hard to pin down, but a spike in mobile device malware is likely in the very near future. If you haven’t already, now would probably be a good time to look at anti-malware for all of your computing devices – Weyland-Yutani BOT is just the beginning.

But this brings to light an increasing problem: the erosion of standalone functionality. PSN customers have not been able to access online content since April 20th. This is, of course, to be expected – if you shut off the network, the network is not available. Unfortunately, this extends to content which isn’t actually hosted on Sony’s network, since PlayStations use the PSN to connect to outside servers. Still, though, not surprising.

Vexingly, however, a certain amount of offline content has also been rendered unavailable, specifically several Capcom games which apparently need internet connection even for single-player mode. This seems to be an increasing trend in the software industry, in games of course, but in other software as well. Even software which has no need to be online, such as a word processing suite, increasingly needs to authenticate with a server in order to install. In fact, you might have noticed that most builds of MS Windows have just such an authentication requirement. And this is continuing to the next level: the Google CR-48 laptop as almost no functionality without an internet connection. Woe betide the user who truly does not want to ever connect a machine to the Internet!

But why would someone want to keep their computer offline?

Well, security, for one. The “airwall” remains the strongest form of security available; no code can ever bridge the gap of a true lack of connection. This isn’t solely the province of super secret government facilities, after all: medical facilities, industrial applications, and numerous other facilities can achieve higher security by dint of simply not connecting machines to the Internet when it is not needed.

Some may not be able to achieve an Internet connection, either due to cost or lack of infrastructure. As amazing as it may seem in 2011, Internet access is not available everywhere, nor to everyone.

But the most important reason is highlighted by this PSN debacle: why should Internet access be necessary? The Internet is a powerful, pervasive tool – but it’s not the end-all of the computing experience, and even now there’s no reason that a computer should be rendered a paperweight by simple lack of connection.

Comptroller Susan Combs offered another apology Thursday for the information breach in her agency, saying she now is offering a year of free credit monitoring to the 3.5 million people at risk of identity theft after their data was exposed on a public computer server…She announced in a written statement April 11 that the Social Security numbers and other personal information of 3.5 million people were left exposed for a year or more in a publicly accessible computer server at her agency.

Dallas News

According to this article in the Dallas Morning News, 3.5 million identities were left free for the taking on a public server for at least a year. That is a colossal security lapse. However, it is a fairly responsible remediation that credit monitoring is being made available for the affected users. (Contrast this with Sony’s recent Playstation Network breach; Sony won’t even confirm whether or not credit card information was accessed in their attack.) Still, had literally any effort been put into keeping that information secured, the state of Texas wouldn’t have to spend an estimated $21 million for the credit monitoring services.

The security arena is one in which the maxim “an ounce of prevention is worth a pound of cure” holds especially true. How much would it have cost to audit that server deployment? A few thousand dollars? Tens of thousands of dollars? Hundreds of thousands? Any answer less than “21 million dollars” means that this should never have happened.

If you haven’t, here’s a brief rundown with a few links:
A security firm, HBGary (or, more accurately, HBGary’s subsidiary HBGary Federal) announced that they had discovered the names of some of the supposed ringleaders of the “hacktivist” organization Anonymous.
This “angered the hive” and – rather than the generally low-risk and unsophisticated DDOS attacks for which Anonymous is better known – Anonymous used a combination of social engineering, SQL Exploits, and password cracking to compromise one of HBGary’s servers. They leveraged that to get into multiple servers, ultimately gaining access to HBGary’s email and no few internal documents – including business plans and proposals to potential clients.
Anonymous then published the information they found – all of it. This embarrassed and scared off most, if all, of HBGary’s potential clients, ruined ongoing negotiations, and exposed activities which indicated questionable ethics and which might be illegal.
HBGary’s actions after this compromise might charitably be called “unfocussed” or possibly “unplanned”. “Foolish” or “Crazy” would possibly be more accurate. The HBGary CEO even engaged with some Anonymous members via IRC, to dubious results. Perhaps the best testament to this incident is the current state of HBGary Federal’s website.

Remarkably, there aren’t any new lessons to be learned here.
HBGary Federal’s first mistake was in taunting Anonymous: no matter how secure you think you are, you’re better off WITHOUT people trying to break down the gates.

The second mistake was in underestimating the enemy. Although Anonymous as a group has mostly engaged in DDOS attacks, they did so using a modified version of a professional load-testing tool: clearly some of their members have always had access to such tools and the ability to modify them. In other words, at least some of Anonymous are clearly highly capable.

The third mistake – or rather, set of mistakes – was likely the most common. HBGary’s infrastructure wasn’t properly secured. They were vulnerable to social engineering, and an important server could be compromised with an SQL injection exploit, and – worst of all – the attackers were able to use that one compromise to access nearly everything else. This is not a very good security posture, especially for a security firm.

Lastly, they didn’t have a recovery strategy. While this sort of compromise is one of the worst-case scenarios, it clearly behooves a company to plan for it, at least in a general fashion, and respond in an organized fashion which helps rebuild client trust and reduce the damage.

While these aren’t new lessons, it’s still worthwhile to look them over again: don’t encourage attacks, maintain a realistic awareness of the attackers you’re facing, harden your infrastructure, and have a recovery plan. Remember that it CAN happen to you, and act accordingly.