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…)

A colleague lent me his most recent copy of IEEE’s Computer magazine.  Inside was an article entitled A Web 2.0 Model for Patient-Centered Health Informatics Applications (IEEE membership required to read).  Some possible benefits of their proposed approach were listed, including:

• Run deeper analytics across physicians groups and facilities, which can include relevant patient data…
• Provide a wide community of health professionals with feedback on the use and effectiveness of protocols…
• Share similar and alternative protocols and their analyses across many medical facilities and individual providers…

Anyone want to guess what’s completely missing from their approach?  You guessed it, any mention of security.  The commonly misunderstood (and frequently misspelled) HIPAA makes it pretty clear that the privacy and confidentiality of personal health information must be protected.  Even without HIPAA, it would just make good sense to be extra careful when sharing information and running data mining and analytics across large sets of health information.

The only mention of keeping information safe in the article is the fact that there is a division of data between the protocol, protocol modifications, and actual patient data – but it is very difficult to draw such bright, clear lines considering medical records and information.  How can you be sure the protocol modification a doctor submits won’t include information on the patient he tried it on?  Without even mentioning or considering the need for the protection of privacy, confidentiality, and data integrity within such a system, the authors of this article have done themselves and the software community a disservice.  Security requirements and threats must be considered at every phase of the life cycle, especially during the architecture phase.  As Kenneth Van Wyck and Mark Graff put it in their book Secure Coding: Principles and Practices,

As a general rule, the hardest vulnerabilities to fix are those resulting from architectural or design decisions. You may be surprised at how many of the vulnerabilities you have heard of we ascribe to errors at “pure think” time.

By developing an 8 page article published in a respected technical journal without any mention of the need for security controls in such a system, the authors of this article have once again helped me with my job security.  It is still difficult for me to foresee the day where security and risk management training programs won’t be necessary, and we won’t need an information security industry.

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!

PDF files have become commonplace on the Internet and in the business world, but they have also become favorite tools for attackers to deliver malicious payloads. While some problems may be mitigated by using an alternative PDF reader, many people have little choice but to use the standard Adobe Reader. In that situation, you can help protect yourself from many PDF-based attacks by following a few basic steps.

1. Make sure you have an up-to-date anti-malware program installed and running with automatic download of new virus definitions. Older tools may not scan for recent PDF-based threats.
2. Make sure you have the latest version of Adobe Reader. Enable automatic updates by opening Reader and choosing Edit > Preferences > Updater. Adobe regularly issues patches against new vulnerabilities.
3. Disable JavaScript in PDF files. This may affect certain features at times, such as PDF-based forms, but it’s better to enable JavaScript only when needed. In Reader, click Edit > Preferences > JavaScript and uncheck the box for “Enable Acrobat JavaScript.”
4. Disable Flash and multimedia in PDF files. Once again, this may prevent a few documents from loading some content, but embedded Flash is a common tool for exploiting Reader. Go to Edit > Preferences > Multimedia Trust (legacy) and either uncheck “Allow multimedia operations” or change the permissions on each listed player to “Prompt.” Be sure to check the settings for both trusted documents and other documents by changing the “Display Permissions for” option.
5. Disable attachments. Earlier this year, security researcher Didier Stevens uncovered a PDF behavior that could be used to launch commands outside of Reader. To avoid this problem, open Edit > Preferences > Trust Manager and uncheck the box marked “Allow opening of non-PDF file attachments with external applications.”
6. Configure your browser to show a download prompt for PDF files. The exact settings for this step will depend on your browser. Remove any plug-ins or add-ons for Adobe Reader, and check the settings for how your browser handles various file formats to check the behavior for PDF files. If you allow PDF files to open in the browser or open in Reader automatically, you may accidentally open a malicious file without realizing it.

These precautions are only a small part of keeping your computer protected against attack, but they will go a long way to help you avoid many threats involving PDF files.

Browser security is a topic that spans a wide range of subjects. This isn’t surprising given the number of exploit techniques that rely on webpages as a primary delivery channel in their attacks. Successful XSS, CSRF, SQL injection (via web app), and plug-in-based attacks all take advantage of the environment provided by the web browser.

Despite the importance of the browser in the chain of security, information on exactly how it goes about managing javascript across domains and determining when to show the “save as” download dialog can be overlooked. However, this is an area where attackers may concentrate their efforts to hedge out new exploits based on a weakness in browser security.

The Browser Security Handbook, released in 2008, is a frequently-updated information repository for all things dealing with modern browser security. It includes the methods presently employed by various browser vendors to improve the security on the application end, as well as some experimental techniques.

It’s certainly worth adding to your collection of security-related links.

http://code.google.com/p/browsersec/wiki/Main

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!

Last week, Google labs released a new free web analyzer tool called Skipfish (project details here). I haven’t had a chance to play with it yet, although I hope to soon, since I have a new web application almost ready to go live.

Skipfish appears to support a ton of features, such as “Multiplexing single-thread, fully asynchronous network I/O and data processing model that eliminates memory management, scheduling, and IPC inefficiencies present in some multi-threaded clients.” Which, although I only barely can understand it, sounds very impressive. The vulnerabilities scanned for include:

High risk flaws (potentially leading to system compromise):
Server-side SQL injection (including blind vectors, numerical parameters).
Explicit SQL-like syntax in GET or POST parameters.
Server-side shell command injection (including blind vectors).
Server-side XML / XPath injection (including blind vectors).
Format string vulnerabilities.
Integer overflow vulnerabilities.
Locations accepting HTTP PUT.

Medium risk flaws (potentially leading to data compromise):
Stored and reflected XSS vectors in document body (minimal JS XSS support present).
Stored and reflected XSS vectors via HTTP redirects.
Stored and reflected XSS vectors via HTTP header splitting.
Directory traversal (including constrained vectors).
Assorted file POIs (server-side sources, configs, etc).
Attacker-supplied script and CSS inclusion vectors (stored and reflected).
External untrusted script and CSS inclusion vectors.
Mixed content problems on script and CSS resources (optional).
Incorrect or missing MIME types on renderables.
Generic MIME types on renderables.
Incorrect or missing charsets on renderables.
Conflicting MIME / charset info on renderables.
Bad caching directives on cookie setting responses.

Low risk issues (limited impact or low specificity):
Directory listing bypass vectors.
Redirection to attacker-supplied URLs (stored and reflected).
Attacker-supplied embedded content (stored and reflected).
External untrusted embedded content.
Mixed content on non-scriptable subresources (optional).
HTTP credentials in URLs.
Expired or not-yet-valid SSL certificates.
HTML forms with no XSRF protection.
Self-signed SSL certificates.
SSL certificate host name mismatches.
Bad caching directives on less sensitive content.

Scanning my new application with this tool will, I’m sure, turn up about a hundred bugs I haven’t even thought about yet. But, that’s better than sticking my head in the sand and pretending nothing’s wrong, or worse, having to deal with any vulnerabilities after they’ve been exploited.

Earlier this week, news reports surfaced of a security hole in a popular mobile application for sharing photos. The program, called Quip, enabled iPhone users to send picture messages to any phone without using carriers’ MMS technology, which often requires an extra monthly fee. Quip sent text messages or push notifications with a link to a web page where the recipient could view the intended picture. According to the developers of Quip, users have sent over 3 million photos using the service.

But those 3 million photos did not only reach their intended viewers. The application uploaded pictures to a public web server with no encryption or authentication, and even worse, the addresses of the files followed a simple, predictable pattern. Once someone posted the information to a popular link-sharing site, Internet users began posting links to images that ranged from racy to disturbing. Intrepid voyeurs even identified people in the photos and found their accounts on various social networking sites.

Addy Mobile, the company behind Quip, reportedly shut down their servers and turned off access to the servers hosting images, but not before many of the pictures were downloaded and re-posted on other web sites. The founder of Addy Mobile issued an apology and promised to keep the service offline until they built better protection for uploaded files. He noted that the company had only three employees but said they would work quickly.

The unfortunate Quip incident provides a real-life illustration of many security lessons, but one in particular stands out: Developers need to think about security aspects of their projects from the beginning. Online resources make it very easy for anyone to learn programming, but that same ease of access can lead to a three-person product handling three million files. While mistakes happen and foolproof security can be difficult, if not impossible, to achieve, building basic precautions into Quip’s system could have avoided embarrassment and difficulty for many end users. Security is not simply a feature or add-on – in today’s connected world especially, it is an essential part of product development.

In general, Windows does a decent enough job with securing software keys in CAPI. Sure, you can open up Windows Explorer, browse to C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, and take a look at your private key files. These bare files, of course, are not exactly plain text. The RSA Machine Keys (which include private keys corresponding to software certificates), are encrypted using the Data Protection API (DPAPI).

The DPAPI encryption method is based on the use of a Master Key – a 512 bit random blob that is created using PKCS #5 Password-Based Key Derivation. This process takes the user’s account password, applies the SHA-1 hash algorithm, sends the hash plus a salt to the key derivation algorithm, and then iteratively calls another PKCS #5 function at least 4000 times to make brute-forcing the secret key even harder. Et Voila! Master Key.

The Master Key is then used to create session keys by generating 16 bits of random data, hashing that with the Master Key, optionally appending the result with entropy data and the user’s password, and passing that blob into a few CryptoAPI calls to derive a session key. This session key is used to encrypt the actual data.

Whew!

This process actually does a very good job of securing key files such that, if you got a copy of the key files as they exist on disk, you’d have a difficult time brute-forcing your way into the software key data. They’re basically useless unless you have an utterly stupefying amount of disposable processing power. However, for as strong as the key protection is, it’s just software.

A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: “What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise.” The scientist gave a superior smile before replying, “What is the tortoise standing on?” “You’re very clever, young man, very clever”, said the old lady. “But it’s turtles all the way down!”
-Stephen Hawking, A Brief History of Time

That’s essentially what software keys are protected by – software, all the way down. Well, that’s not completely accurate. It’s software all the way down except for the mythical final turtle, which is our old friend, the password!

Now, I’m not suggesting that I know how to crack DPAPI, even if I do know a user’s password…that is, unless I have physical access to the device. Then all I’d need to do is log in, and Windows conveniently will take care of the rest, and allow me to use the keys however I see fit. (Un)fortunately, I don’t actually even need that to unlock a software key. All I need is a way of impersonating the user’s logon session, whether through remote desktop, exploiting Windows vulnerabilities, installing a rogue ActiveX control, or any number of countless ways to get a user to run some code.

So, how are we supposed to protect our private keys, then? Well, the simple and pretty inexpensive answer to that question, is Hardware Tokens. You can get a good FIPS-140 validated cryptography token for about $50-100, which will generate keys on the device, and the keys will never, ever be available to software (all cryptography operations are executed on the token). The tokens are tamper resistent (all memory is destroyed if the token is tampered with), and brute forcing won’t work, either (after a set number of failed logins, the token is locked and, optionally, all data is wiped). Now, this isn’t necessary for some applications, but if your encrypted data is worth more than $50 to you, why would you want to protect it with something as flimsy as a password?

We have recently taken a look at Internet Explorer 6 (IE6) to try and help convince a customer of ours to stop deploying it on workstations.IE6 still holds about 33% of the browser market share, but Microsoft stopped mainstream support for it in April of 2009.  IE6 runs ActiveX controls at the same privilege as the browser, which is the same privilege as the user – typically administrator level.  And according to Secunia there are 23 known unpatched vulnerabilities in IE6 – including one which has been around since 2003.

And in a timely post from Brian Krebs on his new site krebsonsecurity.com, there’s a very simple way to crash IE6.

If you’re curious and have IE6 lying around, type or cut and paste the following into the address bar (that last character is a zero):  ms-its:%F0:

So, what are we missing? Are there any other reasons I can throw at this customer to put IE6 out to pasture? Let me know in the comments.