Not much larger than a quarter, the technology behind it is comprised of a micro controller and other associated electronics (memory, I/O, etc). The result is a very functional, yet flexible, USB thingamabob that can let people program their own logic to run their own routines, commands, and instructions.

Teensy was recently used in a unique demonstration of some interesting security implications that arise from exploiting the USB-to-OS trust relationship. By programming Teensy to identify itself as a keyboard, someone could trigger it to send automated keystrokes at will (or set via timer).

But this has been possible for years. In fact, for this example in-particular, it’s probably desirable for users to not have to do any real configuring to get their keyboard or mouse to work. Perhaps the underlying issue is that many vulnerabilities are introduced when trying to balance convenience with security.

But the flip side might be that real change is coming from the other direction. As technology evolves, it gives attackers more tools with which to express their creativity. A few short years ago, programming logic into a USB device like this might have cost a few hundred dollars of equipment and a good amount of coding, just to do something simple.

Teensy is dirt cheap and there is a software library already written for it. This makes it easy to jump right in and start making stuff because the barrier to entry for this vector has been lowered by better technology. As a tool, a device like Teensy offers potential that is only limited to what the creative individual can fit into the on-board flash memory module. In a way, the bad guys get new toys, while the good guys just get more stuff to patch, secure, and protect against.

And that’s not… a teensy problem.

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.

Now, the real concern here is what exactly do these actually mean.  If you see a label for “Phone Calls,” should you freak out and immediately think the app is going to start calling your friends, or start making unauthorized long distance phone calls? No (though it might).

This is one area where I think Android needs to step it up. It’s great that they tell you what permission groups are affected by this application. But to be honest, there are quite a few scenarios that could exist in each group. The given example for Phone Calls really only monitors the state of the telephony portion of the OS e.g.: An application could automatically monitor the state of the phone and reject any incoming calls if this happened to be some sort of navigation app, and felt that receiving calls while driving was too much of a distraction. – That’s a fairly obscure example, but it just goes to show what lengths these permission groups can go to. Obviously this same app would most likely pop up the Location group in this section as well as it would be requiring access to the course or fine GPS data.

So what determines which permission groups show up here, and how can you be sure that the developer wasn’t trying to be sly and hide the fact that their application is using the GPS data? Well, the people at Google thought of that. When developing an application, you need to specifically state which permissions groups your application needs in the AndroidManifest.xml file.

<manifest xlmns:android...>
...
<uses-permission android:name="android.permission.LOCATION"></uses-permission>
</manifest>

If this is not included in the manifest, you’re not even allowed to make calls to the classes that implement the functionality located within that permission group. The code simply won’t compile until the manifest file is edited accordingly.

So it seems Google has covered their end fairly well. It’s just up to the users to keep an eye on what they’re installing. Though as stated, I do think they could increase the level of detail that is displayed for each group.

Included below is a table showing all the permission groups. Also if you’d like to have a deeper look at what’s inside each group, have a look at the Android developer site for a full list of all the constants that would indicate what features are being used.

Android Permission Class

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.

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!

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.

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.

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!

What was clear if you listened for cybercrime instead of being deafened by the cloud is that the problem is getting worse, not better. Cybercrime attacks are increasing in frequency, becoming more effective, and becoming more profitable all the time. Cybercrime is increasingly in the news thanks to Operation Aurora and Google’s public disclosure. The APT buzzword is flying around and driving some in the security industry a little batty (although I did get and wear a pretty cool shirt).

As I mentioned in earlier posts, a few of the RSA keynotes mentioned cybercrime. Most of these mentions were aimed at telling us that cybercrime is getting more profitable and is not going away. Cybercrime is definitely the elephant in the room these days at security events. The security industry itself largely knows how to protect itself from attacks (but isn’t immune by any stretch of the imagination) but has a hard time finding ways to educate others and provide them the necessary tools to make cybercrime less profitable for the criminals. And the current state of tools just isn’t sufficient:

Traditional security products are simply not much help against APT attacks, said Alex Stamos, a partner with Isec Partners, one of the companies investigating the APT attacks. “All of the victims we’ve worked with had perfectly installed antivirus,” he said. “They all had intrusion detection systems and several had web proxies scan content.”

At the RSA 2010 exposition, the Symantec booth had a section dedicated to cybercrime called the Black Market. Inside you could see a storefront where physical representations of online information were available to put in your shopping cart, with prices and descriptions abounding. Everything from credit cards (with guaranteed freshness and CVV2 codes) to full online dossiers (with photos, addresses, social security numbers, etc.) and of course customized malware. You step behind a hidden door and find the laboratory where the cybercriminals are at work – with their botnet controlling software, developing new malware, and printing new fraudulent credit cards. It was a powerful visual representation at the industry which has sprung up around the illicit trading of valued information.

I’ll be writing two more articles within the next week about the other education I received about cybercrime during RSA 2010 which I’ll link in the comments once they are complete. The first is about the briefing I attended by Mikko Hyppönen, Chief Research Officer of F-Secure about targeted malware attacks. The second is about a talk called “Your computer is worth 30¢” by Gunter Ollmann, VP of Research at Damballa which was presented at the Security BSides unconference.

Unfortunately, the discussions, presentations, and demonstrations around cybercrime were not as upbeat as the discussions about cloud security. While individuals and businesses see the move to the cloud as an opportunity to improve security, there are far fewer positives on the cybercrime front. The security industry seemingly has a worthy adversary in the cybercrime industry. Contrary to what Howard Schmidt says, we are at war.

We in the security industry call this “security by obscurity“.  And it is not security at all. Security by obscurity is basically counter to Kerckhoffs’ principle which basically states “secrets do not remain secret, so the design–not the secret–must provide the security”. While arguments can be made in certain situations for withholding or obscuring information or processes, it cannot be the only thing protecting your private information.  I have seen security by obscurity practiced wrongly in these situations:

• The implementer does not have confidence in their security protections and controls.  Therefore, they protect the knowledge of whatever these controls are, hoping that they won’t be revealed. Ultimately these efforts usually fail, the weak countermeasures are discovered and exploited.
• The implementer believes that they have done something “new and improved” or “groundbreaking” when it comes to security.  Whether this is a brand new way to do encryption over wireless networks or a different way of authenticating users, it often would benefit of having a couple–or a few thousand–extra eyes look at it and check their work.
• The implementer or user feels a sense of safety because of their use of obscure or proprietary systems or protocols. For example, “nobody can crack my system because they would never expect someone to develop something in MUMPS that authenticated using the gopher protocol.”
• The implementer or user feels that the secret renders them invisible. The case above, an unpublished URL was no protection. Similarly, telling your wireless network not to broadcast an SSID, or using a username that isn’t related to your real name are attempts to hide information which generally won’t be successful.

And yet, there are some situations where security by obscurity is a useful thing–but only when combined with other efforts.

• Changing well-known usernames and network ports.  Why not stop automated attacks and script kiddies if you can?  I see countless failed login attempts on systems which expose the ssh port. Moving ssh to a non-standard port won’t stop a determined attacker from finding it, but it will stop the constant failed login attempts.
• Use non-default usernames for privileged accounts.  In a similar way, it is easy to try an exhaustive password attack against Administrator (Windows) or root (*nix), but may be harder for the attacker to realize that the Administrator account is actually disabled and the username used for administration is “gocrazy”.
• Do not expose information about system use and value. Naming your accounting server “accountingserver” and the system you keep your confidential information on “topsecretstorage” only helps your attacker.
• Change installation defaults. If you are installing a piece of software which might be an attack vector, try changing some of the installation defaults – change the directory structure, the name of configuration files, use non-standard environment variables, etc.

The above bits can help obscure key parts to help protect you, but those alone won’t protect you–whether your adversary is a newspaper seeking a scoop, or some other advanced persistent threat.  You still need to have a strong security policy, and concentrate on security at every phase of your development lifecycle. And/or <shameless plug>involve some others who can help</shameless plug>.

Bruce Potter opened up with the event schedule and went on into his own little opening that had a common theme of “common sense”. He used the recent hiccups in the TSA as the base analogy. Basically the metric that we’re using to try and fix today’s security problems is solely based on the amount of money that we throw at it. Simply – the future looks grim if we continue the way we’ve been going.

Collin Brack kicked off the actual presentations with one titled: GPU vs. CPU Supercomputing Security Shootout. I was actually looking forward to this talk. Sadly, I was a little disappointed. I guess I was looking for some more in-depth technical slides or live demonstrations on how GPU vs. CPU compare. It was basically a link-filled slide hyping GPU. Nothing against Collin here, I’m sure it was a great presentation for those who had no clue that GPUs could be used for computation calculations, just didn’t have my vote. Key points: GPUs are great for many small calculations.

Larry Pesce, Mick Douglas followed up with “Information disclosure via P2P networks: Why stealing an identity via Gnutella is like clubbing baby seals”. This was a pretty good presentation. They showed what types of personal information they were able to find simply by parsing the P2P networks with a bit of command line scripting and mutella. It was entertaining and informative. Key point: careful with what you share on P2P, don’t share your entire C drive.

At this point I needed to stretch and take a small break, so I used this time to make my donation for my ShmooCon t-shirt. Also, I’m not entirely sure who or what the presentation was at this time. I thought I remembered Bruce mentioning one of the speakers not making it. And all the others were on the schedule, so this block was a blank to me.

I did return for Dan Crowley’s talk about “Windows File Pseudonyms”. It was a good presentation about the many different ways you could reference files without actually using a ‘C:\file.txt’ notation. Most involved some sort of ‘//’ notation or localhost network traversal. Some of this information I knew, but it was good to see it put to actual usage. He demonstrated with a php file upload attack exploiting file name safeties in the code. Key point: watch out for string comparisons for file checks, actually do a file/directory check for paths and files.

Doug Wilson’s “Learning by Breaking: A New Project for Insecure Web Applications” was probably the quickest presentation in ShmooCon history. I say this because as I stepped out for about 8-10 minutes figuring I’d come back just in time for the good stuff, the presentation was already over and he was taking questions. I was really kinda ticked at myself for this one as this was exactly something I was looking forward to seeing as I’ve attempted to set up my own WebApp test environments in the past. I’ll definitely be looking back over the recorded presentation for this one and checking out the site. Key points: Don’t be late for the presentations you WANT TO SEE!

“Guest Stealing…The VMware Way” by Justin Morehouse and Tony Flick brought to the surface an old attack involving a directory traversal vulnerability in VMware Server. They basically explained how they came across it, along with a live demonstration. It’s something that’s long been patched, but it was good to see it in action anyways. Key points: Patch!

The final keynote “Closing the TLS Authentication Gap” presented by Steve Dispensa and Marsh Ray was a very good look into the actual process of discovering a real (and major) vulnerability, and the process it takes to disclose this information in a timely and yet safe manner without simply dropping it as a 0-day for the world to engulf. They discovered many of the issues weren’t technical at all, simply getting vendors and companies to cooperate with what needed to be done. It was a great view into the process and something I think all of us should look into. It gives a good showing at how hard it is to be an actual White Hat.

So, the fun continues tomorrow at 10am EST – I’m beat from a long day and not looking forward to trudging back through the snow, but hey, it’s ShmooCon!