Adobe has created a survey on their Security Matters blog with a survey for digital signature users to complete.

If you have (and use) an electronic signature credential, and are interested in helping Adobe craft the next generation of Adobe Acrobat, Reader, and LiveCycle products and signature features, we are offering you the ability to participate in an Electronic Signature Survey.

Might be worth filling out, if you want to have a chance to influence the next round of Adobe products, such as Acrobat.

Mainstream media is beginning to sound the alarms about the Conficker-C worm which is believed to be affecting more than 2 million Windows PCs. Conficker spreads by an RPC-DCOM flaw in Windows, as well as by network shares–logging into machines that use weak passwords–and by removable media. There is a trigger in the code to download new instructions on April 1st, 2009. Much like the Mydoom or the Sobig worms of years past, researchers know a date when an update is expected to occur, but don’t know exactly what will happen. And, much like those years past, it is likely that not much will occur.

Microsoft along with other security researchers created the Conficker Cabal which has put a $250,000.00 bounty out for information leading to the arrest and convication of those responsible for this particular bit of malware.  F-Secure has a good Frequently Asked Questions list about Conficker and the April 1st trigger.

Bottom line: make sure your system is clean, preferably before April 1st.  Lots of companies have free testing and cleaning tools. Clean your system, and you’ll have almost nothing to worry about on April 1st.

Cross Site Scripting (XSS) vulnerabilities can be pretty dangerous. On web applications, they can lead to everything from breaches in privacy to complete account compromisation. One of the many ways that attackers can take advantage of XSS holes is by reading the information stored in the browser cookies and using it to impersonate a legitimate user. To the vulnerable site, there is usually no difference between the credentials provided by the real user and those provided by an attacker– so everything looks peachy on the surface.

If only there was a way to better protect cookies from such an attack…

Ah, but there is: the ’secure cookie’ flag.

A secure cookie is just like a regular cookie… except for one small difference; secure cookies contain a special ‘HttpOnly’ flag included in the HTTP cookie header that instructs the browser to restrict access to cookie data from scripts within the web browser. Ideally, this will have the net affect of limiting the potential damage many XSS attacks can cause– specifically, the attacks that target cookie data.

The ‘HttpOnly’ flag was first used in Internet Explorer back in 2002, but is now at least partially supported by most major web browsers (with varying degrees of protection). In fact, at the time of this writing, Firefox is the only mainstream browser that effectively prevents both read AND write cookie operations. Although other browsers prevent access via the document object model (DOM), they may unintentionally reveal cookie data when viewing the headers of an XMLHttp response.

In addition, some web server scripting languages mishandle cookie data and can unintentionally undermine the purpose of the ‘HttpOnly’ flag. Certain versions of PHP, for example, strip off special bytes that are included at the end of cookie names, allowing browser-set cookies to overwrite secure cookies when read by the server-side script. (Hint: ‘document.cookie = ‘MyCookie%00=oh snaps;’).

However, one the biggest reasons that the ‘HttpOnly’ flag isn’t as effective as it could be is the lack of knowledge that it even exists. Many developers are completely unaware that they can cripple potential XSS attacks by simply adding a flag in a header.

Clearly, secure cookies aren’t a perfect solution– but they do offer an extra layer of protection and are very easy to implement. In the future, maybe all browsers, web scripting interfaces, and application developers will fully support this effort (or a better one) to proactively limit the wide breadth of the cross-site scripting family of attacks.

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!

“w3af” (Web Application Attack and Audit Framework) is a complete environment for auditing and attacking web applications. This environment provides a solid platform for auditing and penetration testing. The framework will work on all platforms that support Python (Linux, WinXP, Vista, OpenBSD, etc) For my testing, I opted to use the pre-configured Samurai LiveCD (which I will cover at a later time; also available in the BT4-beta) as I attempted to install w3af on my Vista machine, but simply ran into too many hiccups trying to get the GUI to run. Also for this reason, I decided to stick with the command line approach as it is also a very usable command system.

The core of w3af is about utilizing plug-ins. Plug-ins are categorized into three primary sections: discovery, audit, and attack.

Discovery plug-ins are just like they sound. They are used to find new URLs, forms, and any other potential injection point. A common example would be a web spider. Multiple plug-ins can be used in tandem to find each and every injection point that’s possible (within the plug-in’s limits).

Audit plug-ins continue the process and take all the data found from the discovery plug-ins and send specially crafted data in order to find vulnerabilities. One common example would be SQL injections.

The attack plug-ins’ primary goal is to actually exploit the vulnerabilities, the common output from here is either a shell or table dumps in the case of a SQL injection.

As mentioned earlier, w3af supports command line and GUI. For most of my testing, I stuck with the command line as this allowed me to easily see what exactly was going on underneath versus simply filling in blank parameters and clicking a button. Some could argue the GUI might be faster, but the commands required for w3af were very simple, and navigation and setting parameters was a breeze. w3af also supports batching commands together in scripts to help reduce redundant procedures.

w3af is a growing project. It just recently made it to the big 1.0 RC1 milestone. It has great support for addition, and the community is working hard to help expand the possibilities. Its integration into already proven tools is also a big step. I’m going to continue to follow its progress and look forward to bringing you a full on tutorial series very soon.

Direct Links: w3af Samurai BackTrack

Each Thursday (sometimes Friday when Tim is late posting), 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!

Recently I’ve been receiving a lot of email in Russian. I don’t know why, does anyone? If it is spam, it’s not very effective, because I can’t read it. Would be nice if my email provider gave me a way to auto-spam all email that was in a language I didn’t have a hope of reading.

I’ve received another interesting pair of emails on the same tactic. These are standard trojan/phishing attacks, but the tactic of the email is new:

Bank of America Warning:

Automatic Installation failed for Bank of America certificate component. The only thing you can do at the moment is to install the 4.12.2009 version from our website. That is the same application with the new publisher certificate.

Proceed for further information:
[evil URL removed]
Sincerely, Tracey Devine. Customer Service Department.
2009 Bank of America Corporation. All rights reserved.

Has security come so far, that the average user would realize that having up-to-date digital certificates could affect their security? Or, is it just another random tactic to see what might work?

This continues part 1 and 2 of our Sniffing Networks series. This part is a little bit more technical, and a solid understanding of the concepts in Part 1 and Part 2 of this series is recommended.

Now that you have the concept of ARP spoofing down and how MAC addresses translate to IP addresses, you can actually start sniffing. There are many tools that will do all of this for you, but we’ll get to those in a later part. I feel that it’s essential that you understand what those tools are doing before you use them. Instead we’ll use Wireshark (Ethereal) to look at raw packets to understand what we’re actually seeing on the wire. First things first, if you don’t already have Wireshark installed, go get it. It’s available for Windows, OS X and most flavors of Unix (the GUI runs under X11, so you might need to set that up). Also, you’re going to see more interesting things if you have a *wired* Ethernet connection rather than a wireless one.

Start up Wireshark. Make sure you’re not running VMware/Parallels/etc. If you’re running under OS X look here for how you can see any interfaces). First, make sure you have some interfaces to sniff on. Go to Capture->Interfaces.

You’ll see a list of all interfaces on your system. In my case, en0 is my wired Ethernet (and the primary network connection for this machine). Go ahead and click on “Start” to start sniffing on this interface. Suddenly the main window will fill with all kinds of stuff, so what the heck is it? (Feel free to click Stop at any time)

This screenshot is from our office network, so you’re not likely to find any clear text passwords in it (unless the protocol doesn’t support non-clear text passwords). You’ll see quite a few ARP requests at the beginning, as several machines are looking for the .30 computer (which is our domain controller). The main window shows all of the packets that were captured in a terse format. The bottom sections show the raw packet (in hex), and for each type of packet Wireshark knows about, it’ll break down the packet for you in easy to read chunks. The following screenshot is with the ARP packet detailed information expanded. Since we talked about it last time, it might make the most sense to you if you haven’t seen other types of packets.

The ARP packet is from a printer to the broadcast Ethernet address (ff:ff:ff:ff:ff:ff) asking about 192.168.1.143. You can view the Ethernet packet “wrapper”, and then the actual ARP request which is using IP. Later on in the stream, you should see a response to this packet. Unless you’re debugging the network or verifying that any packets you sent out did in fact make it on the network, most people ignore ARP requests and the TCP/IP headers for packets. What you’re interested in is the content of those TCP packets. Wireshark shows these too!

This screenshot shows some HTTP traffic. IP address 72.233.107.118 sent to 192.168.1.145 an HTTP response of 200 and then sent some JavaScript code. Now, once you’re at this level, you will need to be familiar with all of the protocols you want to understand. HTTP is an important one. You might want to also consider learning about AOL’s AIM protocol (they don’t encrypt passwords), POP, and IMAP. Those are the ones likely to net you some passwords in the clear.

The last feature of Wireshark that merits a discussion is “Follow the HTTP stream.” TCP/IP packets are limited in size, so you might not get all of the request or response in one packet. Wireshark will “glue” them together for you. Select the request or response you want to follow, and then right click and “Follow TCP stream”. A new window will pop up that shows you what the full “conversation” was.

This is where you’re going to find passwords or other useful information (such as what a popular web application is on that network).

Stay tuned for part 4 where I’ll go over “easy” tools that just show you passwords, and you don’t have to think too much about what you’re sniffing.

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!

There isn’t really a standard definition of what constitutes a “Critical” vulnerability in an application, but I think it can generally be agreed that when something is given that label, there’s a pretty serious problem that needs to be fixed ASAP.  So, when Adobe announced not only the existence of a <a href=’http://www.adobe.com/support/security/advisories/apsa09-01.html’>Critical Vulnerability</a> in its flagship Reader and Acrobat products but also that the flaw was already being exploited in the wild, a quick patch job would be expected.

The vulnerability in the Adobe software deals with a buffer overflow (seriously – how can we STILL be dealing with these???) flaw that seems to deal with how Acrobat deals with JavaScript (or at least, the exploits found in the wild use JavaScript), although the security bulletin is light on details.  The bug was disclosed on February 19th, and a patch was released on March 10th.  That’s not really an impressive turnaround time, especially for a remote code execution vulnerability.

Adobe’s patch release is interesting, though, in the fact that the update is, as of today, still only available for version 9 of both Reader and Acrobat, and then only on Windows.  A patch is forthcoming for versions 7 and 8, which are also affected by the same vulnerability, with Adobe claiming March 18th as a release date, as well as a stunningly far off release date of March 25th for Acrobat 9 on Unix.

I can imagine some reasons why patching an older version of the application may take a little longer…older versions of a product typically have a wider install base and are more sensitive to changes that may affect things like existing business processes and behavior of deployed plug-ins.  But, the sluggishness in response time seems to be directly correlated to how much money Adobe stands to make or lose by patching each respective version.  Why is this fix taking so much longer to apply to older and lesser-used versions of Acrobat?

I doubt that Adobe overhauled the relevant code that much during the development of Acrobat/Reader 9, as the flaw is exploited the same way on all versions.  Are there really extra weeks worth of validation tests that have to be executed?  Did all the people that worked on Acrobat 7 + 8 leave the company?  Or, could this just be a combination of cost saving by Adobe and subtle nudging of users towards purchasing upgrades to Acrobat 9, and just a cold shoulder to the smaller Unix market*?  The message being sent here appears, to me, to be that you can only expect updates to be prioritized on the latest and biggest version of Adobe’s products, and support for other releases isn’t nearly as much of a priority.  Whether this is an accurate description of the situation isn’t really important – it is, after all, based on a few substantial assumptions.  In this case, though, perception rules in the absence of an official explanation from Adobe why some of Acrobat takes weeks longer to patch the same problem.

*I don’t have any sales figures for platform-specific versions of Acrobat.  The Unix market being smaller is just my assumption.

FireGPG is an OpenPGP MIME-compliant add-on to Firefox that allows you to select some text on a web page (or entered in a form) and perform some cryptographic operations on it.

This add-on provides immediate security benefits. It can allow you to easily and quickly encrypt a message and send it over a public channel without even having to leave your browser. For example, you can send a (short) secret message to someone by encrypting it and posting the block in a public forum or on a public blog– as long as the recipients have the correct key, they can decrypt it. This add-on can also be used to generate digital signatures, providing both integrity and non-repudiation.

Below is an example of some encrypted text sent via Gmail and the results of FireGPG’s decryption:

Although it doesn’t offer anything groundbreaking in terms of functionality, having access to these features with just a right-click within a browser window can certainly come in handy. And for people who want the benefits of public-key cryptography but their web-based email clients don’t support it, this might just scratch that security itch.

You can get FireGPG here.

NOTE: FireGPG is just the add-on that provides an interface to the PGP functionality. You will also need the software to manage keys and perform the cryptographic operations. For this purpose, FireGPG requires GnuPG– a free open-source implementation of OpenPGP. Get it here.

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!

The Health Insurance Portability and Accountability Act (HIPAA) requires a number of protections for the electronic storage and transportation of personal health care and private information in a vastly unregulated environment. Title II, in particular, forces health care providers, drug companies, and other entities who handle patient data to provide a number of administrative, technical, and physical protections. Social networking sites like the health oriented Inspire.com allow drug companies to get around the requirements of HIPAA and other protections, all with your help.

Inspire, which has around 100,000 members, is used by its members to discuss and share medical conditions they have or are concerned about. The site is also used by at least 4 major pharma companies to target potential recruits in clinical trials.

Pharmaceutical companies get easy online access to highly engaged populations with specific medical conditions. “One day we come to you and say, ‘There’s a clinical trial going on, here’s some information, now it’s your decision.’ It lets the patients raise their hand and say, ‘I want to participate’,” says Inspire’s founder, Brian Loew.

Patients releasing their own medical histories and personal information are not covered under HIPAA, so people posting their medical information on blogs, chat rooms, or social networking sites may do so – but the site owners are not required to follow the provisions of HIPAA. To complicate matters, Inspire’s privacy policy (which you ‘agree’ to when you sign up) allows the company to share your medical information (albeit without disclosing any information directly tying you to the data – that’s your job).

Fourth, we may share personal information with entities that are not part of the ClinicaHealth family on an aggregate or other basis that does not disclose your identity or contain individually identifiable personal information.

They don’t have to. You can do it yourself. Inspire doesn’t require you to have an account with them to search and view other people’s profiles. A quick look on their homepage turned up user martzj, who lives in Newport News, Virginia and had a massive heart attack when she was 41 in 1996. Join as a member, and you can see most everyone else’s full profiles and medical histories.

By posting your medical history on any website, as a patient, you are voluntarily opting out of HIPAA and most every other privacy protection and allowing companies to harvest potentially damning information. If you want advice about your diabetes, heart disease, or toe fungus, talk to your doctor, not the entire world.

A couple years ago, Facebook.com revealed just how much information is shared on social networking sites when they introduced news feeds to the home page and user profile pages. These feeds made users nervous perhaps because they had thought that their personal information was safe as long as it was not broadcast to everyone on their friend lists. In reality, it was a new way of distributing information that had always been available to them. Since then, Facebook has added a wide array of privacy options, yet we still find stories of people being fired because of something they said online.

How do you prevent this from happening to you? I guess one option could be to start removing Facebook friends until you are only connected to people that you completely trust, but then why use the site at all? You could instead make all of your not-so-close friends into “limited profile” friends who can only see certain parts of your information, but you will find that it is very difficult to separate your many friends into just two groups. There is another way, and that is what today’s tutorial is about.
Read the rest of this entry »