So you’ve been hearing lately about how some Android applications are going rogue and being used to steal users’ data and infiltrate their phones, to sit idly by only to wreak havoc when the user least expects it (ok, so maybe I exaggerated a little there). But there has been a lot of buzz lately about certain apps not playing by the rules, or including certain calls to leach user information. A lot of this buzz has been spun as backlash against Google for allowing these types of applications to exist (instead of having some asininely draconian filtering process like some ‘other’ phone provider).

Well, to help defend Google (which they’ve done a decent job of doing themselves), this one falls back on the users. If you’re an Android user, you’ve most definitely seen a screen similar to this.

This screen tells you exactly (mostly) [kinda] what the application you’re installing has access to, and how far it can reach. It’s your (the user’s) obligation to agree with this and install, or not agree, and cancel out. See those two buttons at the bottom? If you don’t agree and see something that has “Cost Money” in this section and you presumed it was a completely free (as in beer) app, then you’d better click the right (Cancel) button.

(more…)

Last year I discovered an unusual but useful method for writing web application code: non-alphanumeric JavaScript. This technique has been pioneered by several script ninjas on the hackers forum sla.ckers.org and lets you write scripts without directly using letters or numbers. Application filters or sandboxes may catch typical attacks by monitoring for requests such as “document.cookie,” but they may let non-alphanumeric code slip through.

How does it work? First, you can use blank objects or arrays to generate basic values. For instance, +[] evaluates to the number zero, while !{} returns the boolean value false. You can also combine these simple results to create strings, such as [!{}]+[+[]] == "false0". By treating these strings as arrays, we can grab individual letters. From our previous example, "false0"[0] == "f", so we can use ([!{}]+[+[]])[+[]] == "f" instead.

Once we have enough of the alphabet available as strings, we can start combining letters to reference more useful objects and functions, thanks to JavaScript’s flexibility. For instance, if you wanted to load the sort function for an array, you’d probably use a [].sort() syntax. But []['sort'] works equally well, and even []['s'+'o'+'r'+'t'] loads fine.

In fact, if we set _=[]['sort'] (variable names need not require letters and numbers either!) and call _() in Firefox, we’ll get back the window object, opening up many more possibilities. Accessing this object also means we don’t have to write all of our code without the benefit alphanumeric characters, since we can load data from window.name or window.location. For instance, if we load http://server/page.html#alert(document.cookie), the hash is only seen by the client (and our script), not the server.

This means that if a server is vulnerable to cross-site scripting and doesn’t filter our non-alphanumeric script, we can execute arbitrary JavaScript even though we only send non-alphanumeric code to the server.

If you’re interested in more details, check out the sla.ckers.org threads on optimizing code, cheat sheets, and the Great JS Wall (researchers have found that you couldn’t load arbitrary scripts if you draw from a set of less than six characters). Also, several of the people who contributed to those threads are releasing a book on this method and other attack strategies later this year, entitled Web Application Obfuscation.

A few months ago, I described how the Firefox add-on HttpFox could be used for basic traffic monitoring. Another helpful add-on that complements nicely with HttpFox is called HackBar.

HackBar adds a toolbar underneath the main address bar that can be toggled on or off with the F9 key. When enabled, the toolbar provides a miniature console of sorts for various testing tasks. A resizable textbox gives you plenty of room for editing URIs, and you can also issue POST requests or spoof the referrer. Menus across the top of the bar provide common functions for working with different types of data, such as hash algorithms or encoding and decoding in Base64, URI format, and even hexadecimal.

Using HackBar has its limits, and for comprehensive penetration testing you’ll probably need better tools. But if you just want to poke around a web application or send a quick POST request, HackBar is pretty handy to have around. Combined with HttpFox, you may be surprised at how much testing you can accomplish right in your browser.

Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!

If you haven’t already heard about LIGATT security, you need to.  I won’t do them a favor of linking to them from this blog post, but I would like to provide some information about why I’m afraid of them.  No, it’s not because they have the world’s #1 hacker.

There is a lot of terrific information about the company, its misgivings and wrongdoings on attrition.org’s Charlatan page for Gregory Evans, the LIGATT founder and CEO.  Convicted of wire fraud in the beginning of last decade, Mr. Evans made good upon his release from prison by… marketing a caller ID spoofing service starting two days after the US House of Representatives made caller ID spoofing illegal.

Another fantastic resource is the book review issued today by Ben Rothke on Gregory Evans’ book How To Become The Worlds No. 1 Hacker.  In the review, Rothke explains:

In short, this is merely a work of cut and paste.  In the parts of the book where the author attempts to write original text, it’s ripe with various errors.  I could list many such errors, but why bother… But the real offense is the author’s blatant use of unattributed sources.  I am not talking about a paragraph here or there, it is about wholesale plagiarism, often taking the form of an entire chapter.

So what scares me about them?  No, it’s not that they have the “#1 hacker for hire”.  I’m more scared of my own employees than this joker. It’s because they are a marketing machine that is escaping the ire of the media.  In fact, they’re getting fluff pieces on Fox News and publicizing frightening commercials, taking out full page ads in hakin9 magazine, talking on radio stations, and issuing press releases and ALL CAPS tweets regularly. There’s even a movement to get LIGATT profiled on Oprah.

They proclaim on their front page “LIGATT Security is a leader in cyber security.” If anyone treats and respects this company as a “leader” it will put the community of hard working information security professionals many steps behind.  Organizations like this give the whole security community a bad rap.

For starters, let me just say that I personally have three Mac systems and three Windows systems I interact with on a regular basis.  I’m writing this blog post from a Macbook Pro.  However, there is a wide and growing misconception about the security of Mac systems vs. the security of Windows systems.  I just came across the following post in PC Magazine’s Security Watch blog, and there is a lot of good information in there; specifically the following quote which I want to share:

In the abstract, Macs are every bit as vulnerable as Windows systems, perhaps more so. But in the real world Mac malware is so rare that it actually makes news. Hundreds of Windows trojans like OpinionSpy come out every day. Mac users are generally “irresponsible” about such things, but for now they can afford to be.

My neighbor mentioned the other day that she got a Mac and loved it because (a) it was easier to use, and (b) it was more secure. Point (a) can be argued both ways, some things are easier to do on Windows and some are easier on Mac… but point (b) is something that troubles me.  The lack of publicized vulnerabilities and attacks does not mean more security.  Joe User wasn’t concerned about the advanced persistent threat before Google released information about the Aurora attacks.

The bottom line I try to keep telling people: there are more vulnerabilities written for Windows because that is where the market share is; the attackers are going after the largest market out there.  As the market dries up they will focus their efforts on OSX, and when that happens, beware.  Mac users, don’t be too comfortable.  Get an anti-malware product. Turn on your firewall. Turn on FileVault. Disable automatic logon. Don’t make yourself the easy target when the bad guys turn their attention to Macs.

In evaluating web application security, I’ve built up a toolbox of Firefox add-ons that make testing and experimenting much easier than manual techniques. One of my favorites is a little tool called HttpFox.

While no match for a professional HTTP sniffer, HttpFox provides enough functionality for many basic testing situations. If you want to see what’s happening behind the scenes for a given web application, HttpFox lets you pull up a traffic log without leaving your browser. The plug-in displays a panel right in the lower half of the window and captures a list of every HTTP request made during a given session. (You control the capture through start and stop buttons.) Highlighting an individual request brings up detailed information on headers, cookies, GET or POST parameters, and content returned.

The biggest downside to HttpFox is the lack of any real export or save feature, though for individual requests it’s easy to copy useful information to the clipboard. Still, HttpFox can be handy for checking traffic quickly, and it’s a free download with source code available under GPL v2. Firefox users can install the plug-in by visiting the Mozilla add-on page.

Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!

Chances are, if you read 10 articles or blog posts about the 2010 RSA conference, you will hear the term “cloud computing” ten times. The cloud was clearly the dominant theme of most of the presentations, product demonstrations, and discussions which took place at the Moscone Center in the first week of March 2010. However, another theme was nearly equally present in presentations and discussions: Cybercrime.

(more…)

Today Slashdot had a story about how a news story about an Australian transportation plan was broken early by a newspaper. The transport minister said the access of this information was akin to the newspaper trying to “pick the lock off a secure office and take highly confidential documents”.  What was the brilliant security plan that was supposed to be protecting this information?  The information was all stored on an unpublished URL with no security or authentication in place.

We in the security industry call this “security by obscurity“.  And it is not security at all. (more…)

The first night of ShmooCon is a wrap, at least for the presentations. First off, my shout-outs to all those that actually made it this year. The DC weather hasn’t been too kind to any of us, especially those traveling in specifically for this Con. But to those who made it, I salute you (even more so to those who had to walk a couple miles to get to their hotel because they didn’t make or take reservations at the Marriot).

(more…)

On Saturday, October 10, 2009, James Madison University hosted their second annual Cyber Defense Competition. This year, there were three teams made up of JMU students, and two teams made up of high school students with JMU student advisors. The attackers were played by employees of Gemini Security Solutions, Computer Sciences Corporation, some JMU alumni, and other friends.

The competition is based loosely on the setup of National Collegiate Cyber Defense Competition events. Each team is scored on their ability to correct problems on their network of machines, perform IT-related business tasks, keep critical systems operating, and defend their networks from the attackers. In the JMU competition, the defenders are allowed to work to secure their systems for one hour before the attackers are permitted to perform attacks. This is opposite what typically occurs in the national competitions – the attackers get to probe and attack the systems before the defenders are called in.

Last year we chronicled how the event transpired. This year, there were some differences in what worked, and what didn’t.

• Default Passwords: This was far less successful an attack than the year prior. Most every team had changed every externally-accessible password from its default. What was a cakewalk last year was quickly frustrating (for the attackers) this year.
• Running Older (vulnerable) Software/Processes: This was also less common. The only time these attacks were successful were when systems had to be rebuilt because they were damaged beyond the team’s ability to repair them, the teams forgot to re-patch the servers.
• Installing Unknown Software: The teams were once again given a business task to install software on a server, but the digital signature on the email was invalid. Only two teams installed this software, and both quickly noticed it was not what was expected and removed or patched it.
• Physical Access: A physical attack we performed – erasing the drives on all firewall machines by inserting a DBAN disc – turned out to be the difference in the competition. One team thwarted this attack by disabling the keyboard on their firewall. We only had 5 minutes of uninterrupted access to their systems and failed to get the drive erased on one team’s system. Being the only team standing while the others had to rebuild their firewalls completely allowed them to score enough points to win the competition.
• Web Application Security: The E-Commerce Site/Engine that was installed by default on the team servers was not well understood by the defenders. The attackers used knowledge of the system and its back-end firewall to install back doors and disable the site. Most teams either never got the web application running, or had it disabled for the entire competition.
• Not finding the real problem: This was less of a problem this time. The teams were effective at rooting out the causes of attacks and defending against them.

The teams were all very effective in configuring their firewalls to prevent attacks, and prevent successful privilege execution even when attacks were successful. For example, we had compromised one of the web servers and the ability to run system-level commands on it. Unfortunately, their firewall would not let us use any mechanism to download additional attack tools to the system (we tried ftp, telnet, ssh, tftp among others). As a result, while we could take down the website (which was already at our mercy), we couldn’t use this to attack other systems.

All in all, I believe everyone had an enjoyable and educational time. We look forward to the next competition!