There are quite a few tools readily known to the Android reversing community. The primary one is most likely smali/baksmali. It’s an open source tool which will decompile/compile an android dex format which is used by dalvik the native Android VM, into a format known as smali, which is very similar to an assembly language. A lot of people even like dex2jar, which further enhances the experience and takes a broken down apk, and pulls out the compiled dex classes. With dex2jar you can further that and attempt to get some readable jar files. If you wanted to make it even simpler you continue with that jar and use something like JD-GUI to read those jars back into native java code and be off running. For the lazy, there’s also the apktool which does most of the above for you in a simple one-stop-shop.

These are all great tools, but what else is out there? That’s what I’ll be covering in the next few articles. Today I’d like to point your attention to JEB (http://java-decompiler.com). I discovered this back in February when it made its first public release. At the time, I was knee deep in doing Android Application Security Assessments as part of our IPA process. I was still primarily using the tools mentioned above, so it was nice not only to find something different (it doesn’t use the open source smali as the decompiler), and it’s a nice all-in-one solution for exploring the code, as well as analyzing it.

JEB Interface

Some of the main features include the following, which I’ll go into more depth and why they add more benefit to this tool. The first is the Dalvik decompiler. From day one, I was immediately able to notice a difference between it and the smali decompiler. It uses some of the built-in properties and metadata of the DEX file and uses that to help interpret some of the code. I’ve also seen this change over the past couple months as they’ve improved it, or made other changes. It’s been optimized quite a few times. For me the code decompiled for JEB was broken down further and easier to read, even as a java programmer I’d prefer code to be in the simplest form when trying to analyze it, especially when dealing with unknown classes or libraries, not to mention any obfuscated code.

JEB has a few built in features which make analysis great as well allowing you to examine cross-references, rename methods, fields, classes and packages, navigate between code and data, add comments anywhere and even a notes tab. Putting this into practice is quite easy as well. I’d give a few examples but JEB’s video does a great job itself.

JEB not only gives you assembly and decompiled java views, it breaks down the entire apk, giving you access to all the assets, manifests, string lists and constants as well. Again, the other tools are capable of this, but you’re simply left with the basic file directories, in JEB you get a tab for each item listed out.

JEB also listens to its users with frequent updates, and added features or changes coming directly from the community. The JEB team listens and is active in development.

JEB Style Configuration

I think the only things I’ve noticed that I don’t like about JEB are mostly personal and nit-picky. First is because it’s much like an IDE in its layout, there’s no easy way to change the styling of the code views. Yes you can change it, within the options, but you have to go through every item individually and change them separately (comments, keyword, string, etc.). I did this once, but then accidentally overwrote those settings when I did an update. Which brings me to the second item; the update system requires you to download the latest version, which is archived with a password specific to you, you then unpack it, and do what you want from there. JEB does a check on load to tell you if there’s an update or not, but you still have to update it manually. I’ve spoken to the developers and this is something they’re working on but it’s not a priority. Lastly the decompiler omits any try/catch statements. It will leave a comment saying where they were, but it doesn’t actually leave any information that might have been needed. Specifically if an application spits out an error message in a catch block, that string isn’t there. Sometimes that string is useful for pinpointing certain items.

Otherwise JEB has been a great additional to my toolset; it’s one of the first things I go to if I need quick analysis of an APK. I’m just scratching the surface on this introduction to JEB, and will be doing a follow-up comparing it more deeply with some of its competitors and other tools I’ll be listing in these articles as well. Stay tuned!

On Saturday I was saved by a second factor of authentication.
 
I was playing the new SimCity game on my home computer in the basement, when my gaming session (surprisingly, it was playable that day) was abruptly terminated because my account had been logged on in a different location.
 
Seeing as how I only had one computer with the Origin software installed, I was surprised by this, so I restarted the game. It told me that I was logged on somewhere else, and if I logged on it would log me off the other location. “Sure, sure, whatever.”
 
A minute or two later, the same thing happens. Then I realize what’s going on.
 
I’ll admit, my Origin.com password was horrible. It was four characters long. That said, I was surprised that someone had bothered to capture it. The only game I have is the new SimCity, and it’s problematic as I alluded to in the earlier link.

So I again logged on, forced out the other user, and then went straight to the “change password” link. Here’s where things get fun. Origin’s password reset system requires you to not only have the current password, but also have the answer to your “secret question”. The problem is, my secret question was currently in cyrillic. (Looks like this isn’t uncommon.) So, I didn’t know the answer.

Luckily, the “I forgot my password so please send it to my email” link does not require the secret question to get involved. So I clicked that, got the email, and used the link in the email to reset my password. After that, I spent 30 minutes waiting for an EA technician on chat support to help me change the “secret question”. So now I feel like my account is safe.

Then I walked upstairs and was greeted by 6 voicemail messages on my cellphone. All of them were just strings of digits. This is one of the messages. It turns out, the attacker tried then to gain access to my email account by using the password I had used on Origin, and had kicked off some password reset attempts. Since I had configured my email to require a second factor of authentication (call to my cellphone) before allowing the password to be changed, my email account remained under my control – for now.

So the moral(s) of the story? Use a better password than I did, and make sure you set up second factors of authentication on all the accounts you can. As Smokey the Bear would say if he switched his focus to information security: “Only you can prevent account hijacking.”

Last week at the RSA Conference I had the opportunity to attend the “Mobile Security Battle Royale“, featuring a great panel of experts on mobile phone security. Moderated by Zach Lanier, the panel featured Tiago Assumpção and Collin Mulliner paired off against Charlie Miller and Dino Dai Zovi (co-authors of iOS Hacker’s Handbook). 

As many great panels typically do, this panel featured no slides and no set talking points. Instead, Zach asked the panel some great questions to just get the ball rolling, and the panel started firing off great quotes left and right. I got busy live-tweeting the session and got (and re-tweeted) a few great quotes from many of the panel members which I have embedded below.

One of the recurring themes was “which is better”, comparing iOS to Android. BlackBerry/RIM got a few mentions as well since Tiago worked for RIM for a long time. The panelists did not come to any final conclusion, all the platforms have their benefits and their drawbacks. However, as a “battle royale”. there was a certain amount of desire from the moderator and the audience to declare a winner. My belief is that currently iOS is currently ahead, but the battle is close. The reason I’d tip my hat toward iOS at this time is for two reasons. First, it is slightly more expensive and difficult to get an app into the Apple App Store than Google Play, which makes things slightly more difficult for malware developers. Second, Apple iOS devices are generally running the latest version of the operating system, unlike the fractured Android ecosystem which has over half of the active devices running multiple major revisions behind.

Enjoy these quotes (paraphrased a little, I don’t have an eidetic memory) from this great panel discussion. I look forward to the rematch at next year’s conference.

“Apple disallowing downloaded code to be put into runtime was a hugely prescient decision.” – @dinodaizovi #RSAC

— Peter Hesse (@pmhesse) February 28, 2013

“Talking about antivirus for mobile, it just doesn’t make sense.” – @0xcharlie #RSAC

— Peter Hesse (@pmhesse) February 28, 2013

“We’ve proven that we can get to the moon. I personally don’t have the resources so the moon is safe from my attacks.” @dinodaizovi

— DennisF (@DennisF) February 28, 2013

Good point by @collinrm there are 3 parties needed to upgrade android: carrier, hw manufacturer, and Google, only 1 has incentive to upgrade

— Peter Hesse (@pmhesse) February 28, 2013

“The amount of web traffic that goes to phones is minuscule. So we might as well be talking about rhinoceros attacks.” @dinodaizovi #RSAC

— DennisF (@DennisF) February 28, 2013

“Jailbreaking should be legitimized, and the way to do it is compartmentalization.” – @coconuthaxor #RSAC

— Peter Hesse (@pmhesse) February 28, 2013

I saw this article come across my news feed today, and I thought to myself “what a great idea for an article!” The title is The Petraeus Affair: Human Nature Beats IT Security Every Time.

I was thinking the article was going to be how General Petraeus and Paula Broadwell out-foxed the IT security measures in place at their various organizations to engage in (what they thought was) clandestine electronic communication. I figured the CIA would block access to GMail for security reasons, and yet these individuals were so determined to communicate they would have found a way. After all, most security controls can only defend against those willing to play by the rules.

Reading the article disappointed me because it wasn’t about that at all. Instead it was a simple attack on human nature. The following is a quote from the article:

No matter how much you try to drill security into your co-workers and families, human nature can always countermand common sense and security measures will be rendered worthless.

Saying phrases like “users are the weakest link”, “we have a layer 8 problem”, and “there’s no patch for stupid” elicits knowing head-nods from security consultants everywhere. I believe this mindset and approach toward security awareness is fundamentally wrong. Yet, it seems to be the majority view of the “thought leaders” of the information security industry.

Why is this a bad thing? Quite simply, it sets “security professionals” against the people they are seeking to protect.

• Arguing with negativity creates derisiveness and creates a negative feedback loop. Take political campaign commercials as an example. While they may create short-term popularity boosts, ultimately they divide the two parties further apart.
• Calling people “users” objectifies them and creates distance as was so eloquently written about by Michael Santarcangelo.
• When you call individuals stupid and state they can’t help but “render security measures worthless”, you create a self-fulfilling prophesy. Children believing the negative things they are told about themselves is a contributing factor in generational cycles of poverty and poor education performance.

I wish our industry would realize that we are all on the same team. We will never be able to address all the threats and risks to our information systems if we do not have the support and willingness of every individual which uses them. Why do we think it is a good idea to alienate them?

An attack on the South Carolina Department of Revenue exposed 3.6 million social security numbers, and about 387,000 credit and debit card numbers of South Carolina residents. Data breaches like this are so common, they are barely newsworthy… and we certainly try not to cover every single data breach event on this blog.

However, today’s followup to the story is what made it interesting. Governor Nikki Haley went on the record in a press conference trying to defend their lack of good practices. I’ve embedded the video below and hopefully it will start at the good part, 12:43 into the video:

This is a really good example of sending the wrong kind of message. I understand her desire to defend the state workers that failed to foresee this type of breach, and adequately protect their citizens’ information. I also agree that she might be right – there are many situations in which social security numbers don’t get encrypted. However, I’d like to break down some specific problems with the way she made this statement.

• By saying “a lot of banks don’t encrypt” she is essentially lumping the practices of the banks in with the practices by the S.C. Department of Revenue. However, I don’t think I’m going out on a limb by saying most banks have better security controls and incident response capabilities than the S.C. Department of Revenue. Not encrypting is not the same as not protecting, and there are definitely different ways to protect information.
• Another statement she made against encryption was “because it is very complicated.” Yes, these days we are facing complex challenges and sometimes the actions we have to take in response are also complex. Encryption is meant to be complicated. You wouldn’t want just anyone to get those social security numbers, right?
• “It is cumbersome and there’s a lot of numbers involved with it.” Again, making too much of how complicated it is. Never mind the fact that encryption is actually pretty easy these days, you have a social, governmental, and fiduciary responsibility to protect that information. And “a lot of numbers”? Really? Are we channeling Teen Talk Barbie?
• “It’s not just that this was a Department of Revenue situation, this is an industry situation.” Actually, this is just a Department of Revenue situation. The industry is working to get better. The industry and government are working together to pass standards and regulations. Forward-thinking organizations are proactively assessing themselves and trying to get better. The industry is being held accountable, and so should the state of South Carolina.

Governor Haley, you sent the wrong message to the public today. You tried to deflect blame and throw other organizations and the industry under the bus. Instead, you need to take a long look at what you’re doing to protect information and promise to your citizens that you’ll work to do better.

Yesterday, this story on Wired was making the rounds: How a Google Headhunter’s E-mail Unraveled a Massive Net Security Hole. Sure, the title is probably hyperbole, but it is an interesting story. At a high level, mathematician Zach Harris noticed that emails from Google – and from several other prominent domains including eBay, PayPal, Yahoo, Amazon, etc. – could be spoofed.

Anyone who has ever run telnet to port 25 and sent an email from santaclaus@northpole.net or billgates@microsoft.com knows that email has always been pretty easy to spoof. Given the rise in unsolicited emails also known as spam, something had to be done. In 2006, a working group was founded to try and create a standard that would make email harder to spoof. It is called  DomainKeys Identified Mail or DKIM. The way DKIM works is that the sending email server applies a digital signature to the mail message headers (completely transparent to the user). The public key which can be used to verify the signature appears in the sending email server’s DNS record.

Since it uses some fancy technology like a digital signature and relies on DNS – a core capability of the internet – email with a valid DKIM signature can generally be trusted that it is legitimately from the domain listed in the From field… Well, that is if you’re doing DKIM correctly.

Mr. Harris found that the DKIM signatures for a number of popular domains used such weak cryptography that it was very easily cracked. While the DKIM standard calls for 1024 bit keys, he found popular domains with 768 bit, 512 bit, and even 384 bit keys. As he points out in the article, he was able to crack the 384 bit keys on his laptop, and for $75 he cracked some 512 bit keys by outsourcing the computing power to Amazon Web Services.

The best quote in the entire article, and the reason I bring this story to your attention is the following:

“People who use cryptographic tools need to realize that local configurations need to be maintained just like software updates need to be maintained,” he says. “In 1998 it was an academic breakthrough of great concerted effort to crack a 512 bit key. Today little old me can do it by myself in 72 hours on AWS. The field of cryptography keeps developing and breaking new ground just like everything else, and you can’t just install a private key, or select a hash algorithm, and expect it to be good forever.”

Wise words, indeed. If connected to any network, you must consider your operating system, your software, and your cryptographic algorithms and keys all as perishable items. They need to be examined for mold and rot periodically, and replaced when necessary. You can no longer afford to “set and forget” anything and consider it dependable.

tl;dr Abstract

To improve performance, particularly for mobile users, many websites have started caching app logic on client devices via HTML5 local storage. Unfortunately, this can make common injection vulnerabilities even more dangerous, as malicious code can invisibly persist in the cache. Real-world examples of this problem have now been discovered in third-party “widgets” embedded across many websites, creating security risks for the companies using such services – even if their sites are otherwise protected against attacks. Striking a balance between security and performance can be difficult, but certain precautions may help prevent an attacker from exploiting local storage caches.

Background

Throughout the history of web development, people have found ways to use and abuse various technologies beyond their intended purposes. Before CSS gained widespread support, many developers created complex layouts with HTML tables. Now that browsers provide far more presentation-layer tools, one can recreate complex images using only CSS. Such tricks can at times be very helpful in overcoming the limits of a browser-based environment, but they can also inadvertently create security issues.

(more…)

The current “hot word” in security is SCADA (Supervisory Control And Data Acquisition) systems. The rumors of Russia attacking a water pump system in Illinois and the actual attack of a water treatment plant in Houston have all been in the news in the last few months.

SCADA systems are used in many industrial applications – water treatment, chemical manufacturing, product manufacturing, etc. More and more industries are becoming automated with robots and all kinds of other neat technologies replacing humans (and theoretically human error). Something has to control these systems, otherwise, you’re just replacing the labor force with folks who know how to control these automation tools. But something important to take away is that SCADA systems can literally control life and death situations – water treatment, medical device manufacture, chemical creation. If something goes wrong with these systems, the resulting device/product may kill someone.

The life and death situation is relatively new in the “hacker” community. Generally, the goal is money, and while it would really suck to not have money in your bank account, it’s very rare that that situation would directly kill you. What’s also new is that the makers of these automation tools have decided that having these tools connected to a network would be useful – without considering the security implications.

These devices have not historically been connected to a network. A computer sat on the manufacturing floor that controlled the device(s), and humans walked up to the computer and programmed it, or read data from it, or whatever needed to be done. Now, this computer is networked and takes commands from and sends data to other systems on the network. Computers are fundamentally dumb things – they do what they’re told, and in the case of SCADA systems, don’t necessarily check to see who told them to do something. So, if an attacker gets onto the same network that these automation devices are on and can figure out how to send commands (trivial for most attackers), they can make the device do what they want.

So, how do you protect against this? Until the automation device makers come up with better security – you want to keep these devices in an “inner sanctum”, protected from the rest of your network. Use a firewall with very specific rulesets – based on IP address or use sneakernet to transfer data from the systems on USB/hard drive. At the same time, ask your vendors for timelines on when they expect to have security built into their systems. You may not be able to replace all of your systems, but you can not buy from vendors who don’t take security seriously when you need new/replacement systems.

One of the biggest complaints I’ve had with VMWare vSphere and VMWare ESX/ESXi over the last few years is that managing my virtual machines from my Mac computer was a hassle. The VMWare management utilities are all Windows-only, and even the few web-based tools either do not work or are extremely limited from a Mac. While it isn’t perfect yet, VMWare vSphere 5 has made it so you can actually do just about anything you need to using a Macintosh computer; you just need to go through a few hurdles.

To enable the administration of your various virtual machines, storage, clusters, datacenters, and the like, you can now use the vSphere 5 Web Client. Before it can be used, it must be authorized; the best instructions I found for this are here. Follow the steps in the “Authorizing the vSphere Web Client (Server)” section. This is a one-time configuration necessary to enable the vSphere Web Client.

Once authenticated, you will see something that looks very similar to the Windows-based vSphere Client running in your browser.

This will satisfy most of your management needs, but it leaves out an all-important capability; the ability to remotely view the console of the systems. There’s a Console button, but it won’t work on a Mac. Once you’ve installed a machine, you can typically enable some sort of remote desktop capability in the operating system, but what do you do before then? If you’re running Windows, you use the vSphere client and open a console, but on a Mac, you’re out of luck. Right? Wrong.

There is an under-documented feature of vSphere that allows the capability of opening up VNC connections from the host directly to the console of the virtual machine. To perform this, we first have to enable incoming connections to your vSphere server, as vSphere 5 has an integrated firewall. This is the one step you will actually need to use the Windows vSphere Client; everything else can be done using the Web Client. This step needs to be executed once for each vSphere or ESXi host running virtual machines you want to access using VNC.

In the Windows vSphere client, choose the host you wish to enable VNC connections on. Choose the Configuration tab and on the left choose Security Profile. On the right, next to Firewall click Properties… As VMWare does not include VNC as a protocol, it is not listed as an available option. However the ports allowed by the gdbserver protocol will suit our purposes. Check the box next to gdbserver. (It is also wise to highlight the gdbserver line and click the Firewall… button and lock down where you will allow these VNC connections to take place from; in ours I restricted this to our intranet.) Click OK and you’ve now enabled the incoming ports to be used for VNC.

Finally, enabling VNC access to the console machines is a matter of setting advanced configuration parameters on each virtual machine, which can only be done when the virtual machine is off. To open up the advanced configuration:

• In the Windows vSphere client, choose the machine, click Edit Settings…, click the Options tab, choose Advanced->General on the left, and click Configuration Parameters… on the right.
• In the Web client, choose the machine, click Edit Settings… under the VM Hardware section, click VM Options, click Advanced, and click Edit Configuration….

In both cases, you now want to add three rows by clicking the Add Row button.

Once you’ve added these rows and click OK, you can now use a VNC client to connect to the console of the machine. Power up the machine, and then using Finder on the Mac, choose Go->Connect to Server (or hit Command-K), and type the following:

vnc://<ip or name of esxi host>:<port chosen in configuration settings>/

and click Connect. You will be prompted for your password, and depending on your client/version of OSX you may receive a warning about how keystroke encryption is not enabled. Accept the warning, and you will see the console of the virtual machine! (And note, since Macs don’t already use the three-finger salute, you can safely just press Ctrl-Alt-Del in that VNC-window to log into Windows systems!)

Once you’ve installed the operating system of choice, and enabled that OS’ remote desktop capability, you may want to disable this VNC access. Just shut down the VM, go back into the advanced options and change the RemoteDisplay.vnc.enabled setting to false.

Hopefully at some point soon, VMWare will enable a true web-based console application (which doesn’t require host-specific plugins to be installed) to go with their nice new web client. Until then, this is a reasonable workaround for accessing virtual machines using a Mac.

Security researcher Mario Heiderich (also creator of the HTML5 Security Cheatsheet and lead developer for PHPIDS) has been posting some interesting cross-site scripting challenges lately that highlight aspects of security on the client side. The most recent, called XSSMe², involved a page with a reflected XSS vulnerability that allowed one to insert arbitrary HTML – no filters applied by the server. The goal? Retrieve a particular bit of data, originally stored in document.cookie, without any user interaction. I say “originally,” because the page included JavaScript which attempted to lock down access to the data by removing it from document.cookie and hiding it unless retrieved by a user click. The code used evolved as bypasses were found, with several tricks employed along the way.

One trick was to hide the variable in a closure. In JavaScript, every function has its own local scope. If you define a variable within a function block, that variable is distinct from one defined in the global scope. In a way, the variable is hidden from code executed in the global scope, though the function can provide a gatekeeper method to access it. Consider this block of code:

document.cookie = "secret";

var Safe = function() {
    var cookie = document.cookie;
    this.get = function(magicWord) {
        if (magicWord === "please") {
            return cookie;
        }
        return null;
    }
}
window.Safe = new Safe();

document.cookie = "";

alert(document.cookie);
alert(Safe.get(""));
alert(Safe.get("please"));

The first alert returns nothing – document.cookie has been set to an empty string. The second alert only returns null, given the if statement in the definition of Safe.get. But with the third alert, the statement return cookie gets executed – and that statement is in the local scope of the function, so it returns the cookie variable defined in that scope, which is “secret”. This is the concept of a closure – the local variable of the function lives on as it was defined in that context.

Initially, this may seem to be a good defense against cross-site scripting, since the power of XSS comes from all a page’s scripts executing in the same scope. But as entries in the challenge demonstrated, a script has many resources for attacking itself. For instance, the challenge included code that checked whether a function requesting the secret variable was a mouse click event initiated by the user. That last bit came from checking the isTrusted property on the event, which should tell you whether the click came from a script or from the user.

But in JavaScript, new objects are created by cloning a model object called a prototype. If you change a particular prototype, any new variety of that object will inherit the changes you made. In this case, changing the isTrusted property of a mouse event’s prototype to always be true meant any spoofed clicks generated automatically by a script would fool the protective code and retrieve the secret value.

With each new bypass, Mario updated the code with new protections to block them. Eventually, he created a Firefox-specific version that essentially rewrote the entire page to get rid of the original Document Object Model and all its loopholes. If you’re interested in reading more about other bypass techniques and the challenge’s implications for client-side filtering, researcher Krzysztof Kotowicz has an excellent write-up that covers more details. But the challenge is also worth studying as a way of understanding more about web scripting and XSS. I certainly learned more about closures and event spoofing by tackling the puzzle, and it helps illustrate the difficulties of trying to protect against code running in the same origin and same scope. We may be moving towards DOM features that provide enough security to block even client-side attacks, but for right now, any untrusted script has myriad ways of overcoming client-side protections.