Everyone has their browser of choice; mine is FireFox, because of its level of extensibility and huge collection of user-created add-ons. There are many useful add-ons that deal with security. Here are 4 that deal specifically with SSL and certificates, and two that are just useful in general.

Export All Certificates
This add-on allows you to export all of the trust roots from Firefox in one operation. I can’t really think of a situation where this would be extremely useful, but it may be convenient for testing purposes.
https://addons.mozilla.org/en-US/firefox/addon/141504

Conspiracy
This plug-in adds some UI next to the SSL icon that shows the country of origin for the root certificate that issued an SSL cert.
https://addons.mozilla.org/en-US/firefox/addon/107867

CipherFox
Displays the current cipher and key size in use for an SSL session, and allows you to disable RC4.
https://addons.mozilla.org/en-US/firefox/addon/8919

Expiry Canary
Adds a UI element to FireFox during SSL sessions that warns you if the site’s certificate is near expiration. I can see this being useful if you manage multiple web servers, and need to debug SSL certificate problems often.
https://addons.mozilla.org/en-US/firefox/addon/8717

Flashblock
Flash is somewhat notorious for being insecure, so it’s probably not a bad idea to kill it altogether, and whitelist the flash content you want to allow. Flashblock lets you do that.
https://addons.mozilla.org/en-US/firefox/addon/433

NoScript
JavaScript isn’t always bad – a lot of web sites require it in order to function correctly, including just about any site that uses AJAX or other dynamically presented content. However, it can be exploited in attacks such as cross-site scripts and clickjacking. Disabling scripts is one of the best ways to secure your browsing experience, and NoScript allows you to do so while whitelisting sites that you trust.
https://addons.mozilla.org/en-US/firefox/addon/722

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

I recently found out about Netsparker through Darknet. They released an update to their community edition (free). The main thing about Netsparker that caught my eye is its fundamental approach at eliminating false positives in its web application scanning. I completely agree with the developers’ approach.

The developers thought that if you need to investigate every single identified issue manually what’s the point of having an automated scanner?

So I decided to check out Netsparker a little further and put it to the test. I first started by running its array of scans against a few local web applications I had on my system. Most are either internal development projects or just sandbox sites I use for testing random stuff, most comprised of ASP.net apps.

The majority of the scans came out rather quickly and watching the process was somewhat entertaining. When the scan is complete, it will give you a readout of not only the vulnerabilities, but also lets you see the actual results of each attempted attack, as well as the http request/response for each transaction. It correctly identified a few of the areas that I knew about already. These being internal (some local only) sites, I hadn’t bothered to enable all the security features.

I decided my local sites were a good start so then decided to see if it could pick up some other well-known vulnerabilities. So I pointed it at my DVWA VM (Damn Vulnerable Web Application). With it filled with quite a few vulnerabilities, I’d have a decent record of known flaws for it to test against. Netsparker did quite well, even picking out a few areas that weren’t intended in the tutorial routes for DVWA.

Overall, I was quite impressed. The fact that it actually goes and tries the attacks with some dummy data, or even data that was pulled from context on the site is quite impressive. It even gives you tips or direct commands to run in order to fix some of the known issues. And where it doesn’t give specifics, it points you to the OWASP site for guidelines. I might have to look towards this again and will definitely keep a reference to it in my toolbox for future endeavors.

A while ago, I covered clickjacking, and now, we have “Strokejacking”. So what is strokejacking (other than a badly named attack that makes my inner middle schooler giggle)?

Strokejacking was first discussed on Full Disclosure, but it’s not called that there. It is extremely similar to clickjacking, in that a malicious site has a user doing things they don’t want to do. Except, this time, it’s with the keyboard instead of the mouse – hence the “stroke”. The attacking site gets the user to type (or cut and paste), the information they’re looking for. This could lead to another attack (if the user types javascript), or just gathering a username and password. The user thinks they are logging into a site, but they’re really sending characters over to the attacker’s site.

What can prevent this?

Basically the same things that prevent clickjacking. At the same time, be cautious about cutting and pasting random text (like to get rid of feeds on facebook), and check the SSL certificate being used is issued to your bank before typing in your username and password. These tips aren’t perfect, but they’ll help you avoid a good majority of strokejacking attempts.

Each Tuesday, Security Musings features a topic to help educate our readers about security. For more information about Gemini Security Solutions’ security education capabilities, contact us!

First off, I would like to commend Apache for their detailed, well written disclosures of security breaches. Some organizations take the esoteric route even within the organization, sometimes going so far as immediately reimaging machines that have potentially been compromised without performing any forensic analysis to see what attacks were successful and if any sensitive information was compromised. In the spirit of full disclosure, Apache not only goes through the steps of analyzing exactly what happened, but also shares this information with the public.

Many companies, as well as vulnerability researchers, believe that Cross Site Scripting (XSS) vulnerabilities are all benign; the worst that will possibly happen to your site is an alert window announcing “Georgia is l33t!” However part of the recent attack on Apache that resulted in root compromises of machines within Apache was a result of exploited XSS vulnerabilities. The incident report reads like something out of The Web Application Hacker’s Handbook. The attack used a bug reporting web forum that was vulnerable to XSS. When a user clicked on the link included in the bug report an XSS attack grabbed the user’s session cookie. Given that post was related to a potential bug in Apache software, it isn’t hard to imagine why an unsuspecting administrator might click the link.

This incident just goes to show that even an organization with a strong security posture can fall victim to the dangers of XSS attacks. Code review and penetration testing of web applications should be in place to assess the risk of malicious XSS attacks compromising your company’s assets. XSS vulnerabilities should be taken just as seriously as more hyped web application vulnerabilities.

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!

Raise your hand if you use Microsoft’s Remote Desktop client.   Keep your hand raised if you have ever wondered how a Remote Desktop session is secured.  Finally, only keep your hand up if you have acted on your curiosity and now know the method of encryption used to secure RDP communications and how vulnerable it is to attack.

If your hand is still raised, congratulate yourself for being so security-conscious, but be aware that you are sitting at your computer with your hand in the air because a blog post told you to.  As for everyone else, you should read on.

The good news is that the Remote Desktop Protocol (RDP) is indeed encrypted using RC4.  The bad news is that RC4 is not the best form of encryption out there and can be susceptible to attack by a determined foe.  There may be easier ways to grab protected information than trying to snoop on Remote Desktop sessions, but you should definitely be wary of what information is passing from your fingertips to the remote machine and back.

Older versions of Remote Desktop are vulnerable to man-in-the-middle attacks.  This is even more worrisome because the man in the middle doesn’t even need to attack RC4.  Your RDP data arrives completely decrypted and open for his perusal.

Do you or your employees regularly use Remote Desktop over the Internet with no further security measures in place?  If so, I would recommend that you add them.  Don’t know how?  Contact us!

This has been a debate among policy writers since personal e-mail started to become popular: Can your company monitor/sniff/access your personal e-mail?

Up until this week, it was commonly accepted that you didn’t use company resources to access/read/write your personal e-mail if you didn’t want it to be monitored. However, that seems to have changed – in one specific case. In New Jersey, a woman used her company laptop to exchange information with her lawyer over a web-based e-mail over an issue at work that later went to court. The company used her e-mail communications (presumably) cached on the laptop as evidence against her in court.

While this is (so far) the first case I’ve heard of like this, it doesn’t mean that all employees have personal e-mail privacy all the time. The first thing is that this was in NJ state supreme court, which only applies in that state – however, the case is likely to influence other courts. The second is that the e-mail was considered client-attorney communications – which are “sacred” in most cases. A defendant could tell his lawyer that he did murder someone and the lawyer can not disclose it except under very specific circumstances. Finally, the e-mail was “reasonably” protected – she used a web based service and did not store the password on the laptop.

While it seems to be a blow to companies’ abilities to monitor employee communications, it only applies in specific cases. Either way, as an employee, it’s a better idea to keep your personal e-mail/life separate from your work life.

The Polytechnic Institute of New York University has some excellent videos of presentations from their Penetration Testing and Vulnerability Analysis course. These videos are great for getting a quick introduction to the topics they cover:

Source Code Auditing
Identify vulnerabilities and programmer errors by auditing source code

Reverse Engineering
Understand, modify, and analyze compiled applications and systems to identify vulnerabilities

Exploitation
Take advantage of vulnerabilities to gain access to restricted data and break security policies

Fuzz Testing
Uncover high volumes of software security errors with a special type of negative testing

Client-side Exploits
Indirectly attack the users in your network and automate the collection of data from them

Web Hacking
Identify and exploit vulnerabilities in web applications to gain access to sensitive data and escalate privileges to the host operating system

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.