National Computer Security Day

[This was originally posted to the OSVDB blog.]

November 30th was National Computer Security Day. It came and went .. did you notice? I previously blogged about National Cyber Security Awareness Month, calling into question the value of awareness months of any kind. Awareness days are no different. As William Knowles said, “might have been national kick a penguin day, I wouldn’t have known any difference..

Perl Format Strings

[This was originally published on the OSVDB blog.]

Dyad Security announced a new vulnerability in the Webmin web server component. The perl is vulnerable to a format string bug, which is mostly unseen in perl and quite common in C programs. The post calls this a “a new class of exploitable (remote code) perl format string“. Shortly after, Steven Christey of CVE posted that he had done research into this type of vulnerability as far back as 2002. His post gives a nice timeline of the discovery and research of these bugs, three programs that show the flaws, and references.

So while not quite a new class of vulnerability, it is one that is mostly overlooked by auditors no doubt. It will be interesting to see how many perl based format string vulnerabilities are discovered in coming months.

SANS Top 20 Report Value

[This was originally published on the OSVDB blog.]

SANS has released their Top 20 Internet Security Vulnerabilities for 2005. Started in June 2000, “the SANS Institute and the National Infrastructure Protection Center (NIPC) at the FBI released a document summarizing the Ten Most Critical Internet Security Vulnerabilities”. The list was designed to help administrators tackle the most critical issues on their network, targeting the most often exploited vulnerabilities.

Looking back at the first report, the list covers fairly specific programs or services with known vulnerabilities. BIND (named), RPC services (rpc.ttdbserverd, rpc.cmsd, rpc.statd), IIS RDS, Sendmail, sadmind and mountd, unpassworded default accounts, IMAP/POP and SNMP are eight of the ten on the original list. Two of the items are more abstract, covering “CGI programs and application extensions (e.g., ColdFusion) installed on web servers” as well as “Global file sharing and inappropriate information sharing via NetBIOS [..] or UNIX NFS exports”. Overall, this list provides a good basis for mitigating vulnerabilities, which is arguable based on your definition of the word.

Wikipedia defines a vulnerability as “a weakness or other opening in a system”. Fortunately for me/us, CVE has already covered this issue with their Terminology page and I don’t have to expand on this in more depth. This definition is a fundamental distinction in the world of VDBs and important when evaluating anything (especially papers) on vulnerabilities. While SANS does not explicitly define ‘vulnerability’, the wording of the introduction leans toward a definition of a specific software flaw that can be used to gain access or elevated privileges, rather than the more broad definition of a weakness/opening (or ‘exposure‘ as CVE calls it).

Based on that observation, the original Top20 list kept to the point and formed a list of specific flaws in computer systems (8 of 10) as well as two exposures. Looking at the current list, one has to wonder if the current level of abstraction has made the list more like a beginner’s guide to securing your computer rather than a list of often exploited vulnerabilities. The 2005 list does not make a distinction between the use of the word vulnerability over the last five years, nor does it define the word. In future lists, I believe it is essential that SANS begin to do so and disclaim their work accordingly.

The first entry on the 2005 list is “Windows Services” (W1) which covers just about every major Microsoft Windows service imaginable, including MSDTC and COM+ Service, Print Spooler Service, Plug and Play Service, Server Message Block Service, Exchange SMTP Service, Message Queuing Service, License Logging Service, WINS Service, NNTP Service, NetDDE Service and Task Scheduler. This type of entry more qualifies as an exposure backed by dozens of vulnerabilities. The second and third entries are “Microsoft Internet Explorer” (W2), an entire Web Browser, and “Windows Libraries” (W3) which are most certainly general exposures, not specific vulnerabilities. Fourth, “Microsoft Office and Outlook Express” (W4) cover half a dozen programs including Word, Excel, PowerPoint and Access. Many of the vulnerabilities associated with these products may overlap with “Windows Libraries” as well. The fifth entry “Windows Configuration Weaknesses” (W5) is an abstract entry that can cover an enormous range of exposures that can leave a system open to attack. So far, 5 out of 5 Windows related entries are exposures, not vulnerabilities.

The second section covers Cross-Platform Applications which sets itself up to be a fairly high level entry. Backup software (C1), Anti-virus Software (C2), PHP-based Applications (C3), Database Software (C4), File Sharing Applications (C5), DNS Software (C6), Media Players (C7), Instant Messaging Applications (C8), Mozilla and Firefox Browsers (C9), and Other Cross-platform Applications (C10) make up this wide ranged list that covers an incredible amount of software, operating systems and protocols. It is easy to argue that this list covers well over 50% of the vulnerabilities reported in 2004 (over 4,500 disclosed, and over 6,200 in 2005), making one question the value of a “Top 20” list that covers thousands of vulnerabilities. Consider that “backup software” or “media players” is fairly high level and reaches a level of abstraction that matches beginner security literature. Then consider “other cross-platform applications” is a catch-all for almost everything else out there since most products can be installed on any operating system these days.

The third section starts out with a high level of abstraction and gets worse. First is UNIX Configuration Weaknesses (U1) which would cover a wide range of operating systems such as Linux (all flavors), FreeBSD, NetBSD, OpenBSD, Solaris, AIX, HP-UX, IRIX and dozens of other UNIX variants. This would also cover Mac OS X which is a UNIX based operating system, which is very curious given the second entry under this section. “Mac OS X” (U2) is an entire operating system, and this entry even covers some software that comes with it such as the Safari web browser. Considering Microsoft IE and Mozilla browsers got their own entries above, we begin to see that the list doesn’t even maintain a consistant level of abstraction.

The last sections covers “Top Vulnerabilities in Networking Products”. We start with “Cisco IOS and non-IOS Products” (N1) which covers any product made by Cisco. Given their high installation base, they are an obvious target for vulnerabilities but once again, listing an entire vendor which includes their thousands of products? Next it lists “Juniper, CheckPoint and Symantec Products” (N2) which cover all products by these three vendors. Reading the definition of this entry makes me wonder if they ran out of time when trying to finish the document. Vulnerabilities were announced in these products.. exploit code available for some.. duh? This applies to any software out there, even other vendors with a high installation base. Last on the list is “Cisco Devices Configuration Weaknesses” (N3) which seems to be redundant to N1. One entry for “all Cisco products” and a second entry for “misconfiguring all Cisco products”?!

In summary, the “The Twenty Most Critical Internet Security Vulnerabilities (Updated) ~ The Experts Consensus” covers what? Certainly not the Top 20 vulnerabilities as defined by many security practitioners and vulnerability databases. You can’t even argue the list contains 20 exposures when it lists entire operating systems (Mac OS X/U2), configuration weaknesses (Windows/W5, Unix/U1, Cisco/N3) as well as redundant entries (Cisco N1 and N3). So, what does this list really cover? Who is this list supposed to help exactly? Telling administrators to upgrade all software and verify all configurations seems like a shorter and sweeter way of saying the same thing.

Google Device Vulnerabilities, EULA and More…

[This was originally published on the OSVDB blog.]

H D Moore recently wrote that he discovered several vulnerabilities in Google Search Appliances. You can find details of these on the Metasploit Vulnerability Page, as well as search OSVDB for the corresponding entries. Normally this wouldn’t be worth posting about, however Moore’s comments on the Google EULA and how it impacts vulnerability research is worth noting. From his mail:

I found some fun bugs in the Google Search Appliance and uploaded the results in preparation for a Monday morning release. To get an idea of how many affected systems there are, just Google for inurl:proxystylesheet. Google released a patch on August 16th and I agreed to wait at least 60 days past that before disclosing the bugs.

A warning to anyone who owns one of these appliances – the EULA and confidentiality agreement prohibit any form of security research or publication of results. After I reported the issue, their security team offered to send me a Mini for patch verification, but agreeing to the license terms would prevent me from publishing any information about the product in the future. I got a beach towel and shirt instead 🙂

This also brings up why Google won’t publicly release their security advisories. Searching Google for “GA-2005-08-m” finds one reference to someone having problems with the latest patches, but no copies of the advisory. Seems Google is all about organizing and sharing world information.. unless it’s information on their own vulnerabilities? Oh wait, “the Google Search Appliance does not create security issues”!

Disclosure: Barracuda Spam Firewall XSS & Hashed Password Disclosure

[This was originally published on OSVDB, now gone, and touched up slightly for style. Mirrored on VulnDB 20878 & 20879]

From: Jericho
To: support(at)
Date: Fri, 01 Jul 2005 03:37:18 -0600
Subject: Barracuda Spam Firewall Cross Site Scripting (XSS) Vulnerabilities


My ISP uses the Barracuda Networks Spam Firewall, Firmware v3.1.17 (2005-08-06 11:48:38). When editing my e-mail account preferences, I noticed that a few fields were prone to cross site scripting (XSS) attacks.

The URL:

http://%5Bmy isp]:8000/cgi-bin/index.cgi

Pages – Fields:

Whitelist/Blacklist – Email Address field add_user_scana_sender_allow and add_user_scana_sender_block form fields

Quarantine Settings – Notification Address
UPDATE_user_quarantine_email_address field

Put the following text into the field, and it will render the script:

A second issue I noticed, my e-mail account password is stored as an encoded value in a hidden field. The password (encoded) is also used in various HREFs, causing it to be visible in the browser. This means it is transmitted without the protection of SSL encryption, a known secure standard.


Barracuda Networks
Barracuda Spam Firewall
Firmware v3.1.17 (2005-08-06 11:48:38)

Subject: xxxxx Ticket-No.378972
Date: Fri, 01 Jul 2005 09:14:03 -0600

[===> Please enter your reply below this line <===]

[===> Please enter your reply above this line <===]

Your Ticket: 378972
Description: Barracuda Email Concerns/Questions

This action has been taken:
Note added: xxxxx

These notes are included:

Hi Brian –

I’ve reviewed the email you sent to Barracuda, and would like to point out a few things. First, the barracuda interface does not use cookies to store any data, so the effects of the XSS vulnerability you described are minimized. Second, the password field is hashed against another token that seems to be very specific to your current session. The URL can not be reused from another location, so even if you were using the interface off our network and someone was able to sniff the URL, they would not be able to use those tokens to gain access to your quarantine interface. The only “portable” URL tokens are in the quarantine reports that are sent to you. If using these links causes you concern, you can generate a password to log into the interface which will not involve any such “portable” login tokens.

Finally, if you do set up a password, you can login at which uses a self-signed certificate. This
still uses the authentication tokens in the!
URL, but as noted, they are not reusable from another location. Please
let me know if you have any other questions or concerns, and I will be
happy to pass them on to our vendor.

Security Advisories, Mail Lists, and You

[This was originally published on the OSVDB blog.]

When a security researcher finds a vulnerability, they may choose to release the details in a formal advisory. The different between a random post to a mail list and an advisory typically involves the level of detail and the amount of peripheral information to the vulnerability. This includes discovery date, vendor communication timeline, patch information, formal writeup and technical details of the vulnerability. Because advisories are used as marketing material as much (or more) as vulnerability research/disclosure, some security companies would rather use them to attract attention to their web site.

To do this, they may post a brief message to a mail list announcing the discovery of a new vulnerability and a link to the advisory on their web page. This may seem logical and understandable, but in the long run this does a huge disservice to the security community. What happens when the security company goes out of business or gets purchased by another company? Overnight, all of their advisories and research may disappear. Mail list archives will then contain no useful information and a dead link to a site/advisory no longer there.

This problem (and debate) goes back a ways, most notably in 2000 when Elias Levy (then moderator of Bugtraq) rejected a post from @stake because the vulnerability report did not contain enough information. Thomas Greene covered this incident and dug into the issue. Levy later cited his reason for rejecting the post, which touches on my previous post:

“For very long we have tolerated the marketing copy on vendor advisories because while annoying they were accompanied by useful information. But in this change there is no value added to list subscribers. It’s for this reason that we are not accepting such advisories,”

For those of you who side with companies that post glorified advertisements without technical details, consider the following quote from Levy:

“I’ve asked the list subscribers for their opinions. I’ve received over five-hundred messages to far. While a handful of people liked the notices, the large majority of them, probably around 95 per cent, found the change to be a negative one and want me to hold firm to the policy of not approving them.”

The ultimate irony here is the Levy work[s|ed] for SecurityFocus, who was purchased by Symantec, who also recently purchased @stake and subsequently removed the @stake advisories from the web site a few weeks ago.

Disclosure or Blatant Advertising?

[This was originally published on the OSVDB blog and re-published on the Sydney Morning Herald.]

Security advisories are a form of advertising. First and foremost, they are used to promote the technical capability of a security company and showcase the talent. If a researcher or company was completely altruistic, they would not release an advisory and would not care about credit if the vendor released an advisory. Releasing vulnerability information has been used as a form of marketing for over a decade, and it works for everyone. The company releasing the information gets free press, the security community gets vulnerability information in return. In recent years, many companies have relied on it for getting started and attracting their initial customer base.

With the full vs responsible disclosure debate a constant shroud hanging over security companies, they must be careful not to scare away potential customers by giving the impression that they don’t care about security or the repercussions of their disclosure. As such, many companies have taken a very strong stance on responsible disclosure, some arguably taking it too far.

One example of this strong stance is NGSSoftware who began withholding details of vulnerabilities for 90 days, in order for administrators to have plenty of time to patch the vulnerability. This is a good thing overall, and NGSS has set a good example showing that security companies can help the community while protecting them just the same. Of course, NGSS should make sure to release those details after 90 days, something they don’t always do in a timely fashion. An example of NGSS’ policy can be seen in their recent post to Full-Disclosure as well as their immediate followup. While vague, it does tell us that multiple vulnerabilities were found, what software they were found in, and what types of vulnerabilities they are. These correspond to information provided in the Oracle security bulletin and serve as a warning to the severity/importance of the vendor patch.

A few weeks ago, Integrigy Corporation took it too far in my opinion. In a posting to Full-Disclosure titled Vulnerabilities in Oracle E-Business Suite 11i – Critical Patch Update October 2005, they provided a four page summary of .. no vulnerability disclosure. The bulk of the post was to point out they had released analysis of the Oracle patches and what it could mean for customers. While this information is helpful, it is NOT disclosing a vulnerability in any fashion. The only thing resembling disclosure was the ‘credit’ section which states:

Some of the vulnerabilities fixed in the Critical Patch Update October 2005 were discovered and reported to Oracle by Stephen Kost of Integrigy Corporation.

This isn’t disclosing a vulnerability, and should not be posted to a list centered around full disclosure. The company name “Integrigy” appears 14 times in the post, and their company URL 3 times. They mention their products AppSentry and AppDefend a total of four times.

Argue all you want, but this is blatant advertisement, not a security advisory.

Advisory Archives 102 (why Mandriva hates VDBs)

[This was originally posted on the OSVDB blog.]

I recently made a post titled Mail List Archives 101 (or why SF hates VDBs) commenting about the restructure of the SecurityFocus mail list archive. In short, it’s a bad thing. Unfortunately for many people, especially vulnerability databases, this is happening more and more, on various sites. Instead of an isolated event and one blog entry, now it seems I may want to start keeping a list. This time, welcome Mandriva Linux to the list.

Up until Apr 6, 2005, Mandrake Software used a standard URL for accessing advisories, which now gives a 404 of sorts:

Sometime on or around Apr 6, 2005, Mandrake Software became Mandriva, and offered the advisories on a new URL:

Checking that URL now will redirect you to the generic advisory page:

Now, new Mandriva advisories are distributed with a URL like this:

Databases that have been referencing MDKSA advisories the past five or more years are now left with several hundred links that 404 or redirect to the main security advisory page (more recently). Not a good move Mandriva/Mandrake. Since the advisory ID remains the same, the least you could have done is set up more friendly redirects for the old advisories/domains. Jerks.

Vulnerability One Trick Pony?

[This was originally published on the OSVDB blog.]

I know the title of this may seem to be a slight on the researches I will use as examples, but that is not the case at all. Some people in the security community have a perception that some vulnerability researchers are so-called “one trick ponies“, meaning they know one trick and are not able to offer diversity or research different types of issues.

In some cases this might be accurate, as the ability to test and “research” vulnerabilities such as cross-site scripting takes nothing more than a simple cut/paste and witnessing a resulting pop-up. Other researchers may know the basics of overflows or format strings, but not know how to exploit more tricky occurrences. Even so, these people show that countless programs, even recently developed ones, continue to suffer from the same old weaknesses we’ve seen over the last twenty years. They show that many programmers still don’t get it, don’t learn from history, and do not practice secure coding techniques.

In other cases, some researches stick to what they do best, and it isn’t a lack of proficiency affecting their results. Like them or not, their efforts do serve a good purpose and they have good intentions.

Secunia and “archive handling” issues.

Lostmon and XSS

Luigi Auriemma and games

Alexander Kornbrust and Oracle