After John Cartwright abruptly announced the closure of the Full Disclosure mail list, there was a lot of speculation as to why. I mailed John Cartwright the day after and asked some general questions. In so many words he indicated it was essentially the emotional wear and tear of running the list. While he did not name anyone specifically, the two biggest names being speculated were ‘NetDev’ due to years of being a headache, and the more recent thread started by Nicholas Lemonias. Through other channels, not via Cartwright, I obtained a copy of a legal threat made against at least one hosting provider for having copies of the mails he sent. This mail was no doubt sent to Cartwright among others. As such, I believe this is the “straw that broke the camels back” so to speak. A copy of that mail can be found at the bottom of this post and it should be a stark lesson that disclosure mail list admins are not only facing threats from vendors trying to stifle research, but now security researchers. This includes researchers who openly post to a list, have a full discussion about the issue, desperately attempt to defend their research, and then change their mind and want to erase it all from public record.
As I previously noted, relying on Twitter and Pastebin dumps are not a reliable alternative to a mail list. Others agree with me including Gordon Lyon, the maintainer of seclists.org and author of Nmap. He has launched a replacement Full Disclosure list to pick up the torch. Note that if you were previously subscribed, the list users were not transferred. You will need to subscribe to the new list if you want to continue participating. The new list will be lightly moderated by a small team of volunteers. The community owes great thanks to both John and now Gordon for their service in helping to ensure that researchers have an outlet to disclose. Remember, it is a mail list on the surface; behind the scenes, they deal with an incredible number of trolls, headache, and legal threats. Until you run a list or service like this, you won’t know how emotionally draining it is.
Note: The following mail was voluntarily shared with me and I was granted permission to publish it by a receiving party. It is entirely within my legal right to post this mail.
From: Nicholas Lemonias. (firstname.lastname@example.org)
Date: Tue, Mar 18, 2014 at 9:11 PM
Subject: Abuse from $ISP hosts
I am writing you to launch an official complaint relating to Data
Protection Directives / and Data Protection Act (UK).
Therefore my request relates to the retention of personal and confidential
information by websites hosted by Secunia.
These same information are also shared by UK local and governmental
authorities and financial institutions, and thus there are growing
concerns of misuse of such information.
Consequently we would like to request that you please delete ALL records
containing our personal information (names, emails, etc..) in whole, from
your hosted websites (seclists.org) and that distribution of our
information is ceased . We have mistakenly posted to the site, and however
reserve the creation rights to that thread, and also reserve the right to
have all personal information deleted, and ceased from any electronic
dissemination, use either partially or in full.
I hope that the issue is resolved urgently without the involvement of local
I look forward to hearing from you soon.
Thanks in advance,
Update 7:30P EST: Andrew Wallace (aka NetDev) has released a brief statement regarding Full Disclosure. Further, Nicholas Lemonias has threatened me in various ways in a set of emails, all public now.
A week ago, I read an interesting blog post by Jeremiah Grossman of WhiteHat Security titled: “201x: The Year of the Security Industry Breach”, which discussed that security software may be the next big target for attackers to focus on
Some great points are presented and I especially appreciate how the fact is hammered in that attackers shift focus whenever required, but as Jericho pointed out when we discussed it, “The security industry does not.” I find, however, that the blog post lacking a couple of key points, which caused me to write this follow-up (not a rebuttal – Jericho handles those).
I agree that we have for decades been offered the same solution to all our security problems: Buy more/newer/subscription security software to deal with the threats. It is also certainly installed in abundance.
Security software does present problems however, and these concerns are not new. Researchers have voiced concerns for years over security software like firewalls and especially anti-virus (AV), pointing out that businesses are adding more (potentially flawed) code to protect themselves. It’s a common rule of thumb that the more lines of code, the more vulnerabilities. Reducing attack surface by adding an even greater attack surface is a paradox.
While security software in general presents an interesting target, it does, however, not necessarily mean that we will see it receiving the same heavy abuse as Java, Internet Explorer, and Flash, which are currently getting hammered by the bad guys.
When the bad guys were exploiting vulnerabilities in Adobe Reader, they were not targeting PDF viewers overall; they did not really care about e.g. Foxit Reader, PDF-XChange, nor Sumatra PDF. When Microsoft Office was hot, other office suites like OpenOffice and Corel Office did not feel the burn. And when 0-days are being dropped in Internet Explorer, browsers like Firefox, Opera, and Chrome can relax (relatively speaking) on the side.
These other products are not necessarily going free or only receiving limited attention because they are safer – they may just not have a user base that results in a profitable ROI.
If history is permitted to serve as a pointer, the bad guys do not target a whole class of products, but generally specific products with an extremely high user base allowing widespread attacks. It would, therefore, be more likely to see attacks focusing on products from a specific security vendor. That would, however, require a strong position with the vendor’s products being installed on a very large scale and while security software is prevalent, no single vendor dominates the market – especially not with a single product.
Another option would be if the security products start using the same codebase e.g. for file parsing or other common routines. Should security software e.g. use the same third-party parsing functionality, these parsers would certainly become of greater interest.
It should also be noted that while security software has not been targeted by the bad guys in the same manner as the previously mentioned products (and currently for good reason), it has still received a fair amount of attention over the years from researchers (myself included).
Looking at the OSVDB vulnerability database, it has at the time of writing 1,919 entries covering vulnerabilities in security software – in fact almost 2% of all our entries (yes, we have a specific classification flag, making it very easy to get a historical overview). These span from 2013 all the way back to 1995, when security software started gaining a foothold. I specifically remember when Alex Wheeler in 2005 was doing some serious work on the archive parsing functionality of many security software vendors’ AV solutions.
For the past 5-6 years, Symantec has also had their worries because they decided to implement very flawed parsers from HP/Autonomy/Verity Keyview in some of their security solutions, including their Mail Security and Data Loss Prevention products. Or Microsoft who on a related note made the questionable decision of implementing Oracle Outside In parsers in Microsoft Exchange Server 2007 and 2010. A vendor with a history of vulnerabilities, that they have worked very hard to overcome, deciding to implement a more notoriously insecure vendor’s software is certainly interesting.
Does this mean we won’t see any focus on security software in the future? Certainly not. Security software exposes a broad and tantalizing attack surface and is not necessarily built to impress (as Tavis Ormandy recently demonstrated for Sophos’ security solutions). It is an interesting target class of products that will continue to receive attention – and perhaps even an increasing focus once Oracle eventually sorts out Java, though that may take a while.
When the going gets tough, attackers just change to a different target with a better ROI, and it cannot be ruled out that the target ends up being the code actually intended to protect you.
So remember that 201x is already here and that while the bad guys may not go all-in against security solutions, vulnerabilities in these have been found consistently for many years. Consider what security software you really need – and certainly which features you need enabled.
Today, we pushed OSVDB 82447 which covers a backdoor in the Multics Operating System. For those not familiar with this old OS, there is an entire domain covering the fascinating history behind the development of Multics. OSVDB 82447 is titled “Multics Unspecified Third-party Backdoor” and gives an interesting insight into backdoors distributed by vendors. In this case, a third-party planted it, told the vendor, and Honeywell still distributed the operating system anyway. I encourage you to read the full paper by Lieutenant Colonel Roger R. Schell, a member of the tiger team that carried out the attack.
During a US Air Force sanctioned penetration test of mainframe computers, sometime before 1979, the tiger team ended up penetrating a Multics installation at Honeywell. In an account of what happened later, a paper said that the tiger team “modified the manufacturer’s master copy of the Multics operating system itself” and injected a backdoor. The backdoor code was described as being small, “fewer than 10 instructions out of 100,000″ and required a password for use. The report continues, saying that even though Honeywell was told it was there and how it worked, their technicians could not find it. Subsequently, the backdoor was distributed in future installations of Multics.
It would be interesting to know why Honeywell didn’t ask for, or didn’t receive, the specific modified code from the Air Force tiger team, and why they opted to distribute it to customers. Perhaps they thought if their own technicians couldn’t find the backdoor, no one else could. Even more interesting is why a tiger team was sanctioned to carry out a penetration test that not only gave them access to the “master copy” of Multics, but why they were allowed to actually place the backdoor there. When they heard Honeywell couldn’t find it, why didn’t they insist on ensuring it was removed before installation at customer locations? This brings a new twist to the ethics of penetration testing, at least in a historical context.
The Open Security Foundation, providing independent, accurate, detailed, current, and unbiased security information to professionals around the world, announced today that it has launched Cloutage (cloutage.org) that will bring enhanced visibility and transparency to Cloud security. The name Cloutage comes from a play on two words, Cloud and Outage, that combine to describe what the new website offers: a destination for organizations to learn about cloud security issues as well as a complete list of any problems around the globe among cloud service providers.
The new website is aimed at empowering organizations by providing cloud security knowledge and resources so that they may properly assess information security risks related to the cloud. Cloutage documents known and reported incidents with cloud services while also providing a one-stop shop for cloud security news and resources.
“When speaking with individuals about the cloud, to this point it has been a very emotional conversation. People either love or hate the cloud,” says Jake Kouns, Chairman, Open Security Foundation. “Our goal with Cloutage is to bring grounded data and facts to the conversation so we can have more meaningful discussions about the risks and how to improve cloud security controls.”
Cloutage captures data about incidents affecting cloud services in several forms including vulnerabilities that affect the confidentiality and integrity of customer data, automatic update failures, data loss, hacks and outages that impact service availability. Data is acquired from verifiable media resources and is also open for community participation based on anonymous user submissions. Cloud solution providers are listed on the website and the community can provide comments and ratings based on their experiences. Cloutage also features an extensive news service, mailing lists and links to organizations focused on the secure advancement of cloud computing.
“The nebulous world of cloud computing and the security concerns associated with it confuses many people, even IT and security professionals,” says Patrick McDonald, a volunteer on the Cloutage project. “We want a clearinghouse of information that provides a clear picture of the cloud security issues.”
Sometimes when I read our past blog posts it seems like OSVDB moderators are a broken record. We seem to always say that we had these ideas a long time ago…. We seem to frequently say that VDBs need to evolve……. We say that we would love to do something about it but need resources…….. Times are changing for OSVDB. As you have seen over the past couple weeks, we are extremely thankful for our lead developer Dave as he is making a lot of these ideas happen!
OSVDB has publicly stated several times (e.g., SyScan04 , CanSecWest 2005 and OSBR) that we felt it was important to achieve active integration with security tools to streamline the process of identifying and setting priorities for the creation of vulnerability checks. Our goal is for OSVDB to assist tool developers to identify vulnerability checks or signatures that are not already represented in their products, and will provide a way to identify the high-priority vulnerabilities for immediate attention.
Today we took our first huge step forward to make this happen thanks to yet another improvement in our search engine. A couple days ago I was discussing this idea again with Jericho and the possibility of trying to finally bring it to life. To make it really happen we agreed we would need the search engine to function in a way it hasn’t yet done…. it would need to search for things that are NOT in OSVDB, and need to search based on CVSS scoring / criteria. After spending some time chatting with Jericho he said…… it may be complicated to implement. Well, he definitely underestimated Dave’s ninja development skills as this was knocked out in several hours over two days!
What is the big deal about this feature anyways?
What if for example….
- …you were wondering which vulnerability scanner / IDS / IPS has the best coverage?
- …you were trying to figure out which check you should write for your favorite scanner / IDS / IPS?
- …you were trying to figure out what are the most important vulnerabilities missing from a scanner?
OSVDB can now show you a listing of all vulnerabilities with certain characteritics that are missing a reference as well. Even more powerful, the ability to search by CVSSv2 score or specific attribute.
For example, we can have OSVDB show a listing of all vulnerabilties that have the following:
- CVSS score between 9 to 10
- are for Microsoft
- can be exploited from remote/network
- and do NOT have a Metasploit reference
Check out the results from OSVDB for the example above.
This search shows that there are 175 entries in OSVDB that Metasploit is missing a check for, that have a high impact. Perhaps this list would be useful to HD and the folks over at Metasploit to determine which exploits need to be included next. As you can see there is a lot more you can do with it. Check out the OSVDB Advanced Search and play with it a bit!
As mentioned this is just the first step and is what we believe will be the basis for much more to come. OSVDB is positioned to be the central source to help review and determine the completeness of commercial security solutions. We believe that OSVDB has an extremely high coverage of all disclosed vulnerabilities and will be able to provide insight into what vulnerabilities are covered (or missing) from a given scanner or tool. We will be able to show the gaps and even provide guidance to users as to which scanner or tool would be best for their organization. Instead of listening to a sales pitch that says “trust us we cover the most vulnerabilities!”, OSVDB will have real data to show that Product X has more coverage than Product Y. We will be in a position to allow a security practitioner to ensure that the products that are critical to their organization are covered in the scanner they are potentially purchasing. As shown above, we can show which vulnerabilities do not have checks (Metasploit, Nessus, Snort, etc) for critical vulnerabilities.
You know… when we find some time it would be a great idea for OSVDB to conduct a bake off on coverage between the top vulnerability scanners and IDS/IPS products. This of course relies on having vendors that are open and share their vulnerability mappings in a format that can be imported into OSVDB. So far, Nikto, Metasploit and Tenable’s Nessus have provided us with these mappings. Another upcoming feature will be a system that allows these vendors to automatically upload updated mappings to keep OSVDB current. Three vendors down, who will be the next to step up?
OSVDB is featured in the June issue of the Open Source Business Resource (OSBR) and is now available at the OSBR website. We were contacted and asked if we would like to include our original OSVDB Aims white paper in the issue. This was really the prompting that we needed to take the time to update the project’s successes since the launch and provide some additional information about the future of OSVDB.
We would like to thank Dru Lavigne and OSBR for their support and encourage you to take a look at the issue. The OSVDB article can be found at: http://www.osbr.ca/ojs/index.php/osbr/article/view/607/568
OSBR’s editorial theme for June is “Security” and here is a listing from the table of contents:
Jake Kouns, president of the Open Security Foundation, introduces the Open Source Vulnerability Database Project. David Maxwell, Open Source Strategist at Coverity, discusses the findings from Coverity’s analysis of over 55 million lines of open source code. Robert Charpentier from Defence Research Establishment Valcartier and Mourad Debbabi, Azzam Mourad and Marc-André Laverdière from Concordia University present a summary of their research into providing security hardening for the C programming language. Frederic Michaud and Frederic Painchaud from Defence Research and Development Canada describe their evaluation of automated tools that search for security bugs. Key messages from Carleton University’s Stoyan Tanev’s recent presentation on technology marketing trends and the Eclipse Foundation’s Ian Skerrett’s presentation on building successful communities. Michael Geist, Canada’s Research Chair of Internet and E-commerce Law, explains why the proposed Bill C-61 does not address the rights of Canadians. Alan Morewood from Bell Canada provides an example of open source meeting a business need.
Next months editorial theme is “Accessibility” – contact the OSBR Editor if you are interested in a submission.
There has been a pretty good buzz about MP3 spam in the past couple days……… Some folks at GFI sent us the following and thought it would be worth sharing…
Spammers are back with a new trick, this time round sending messages with MP3 attachments that contain the latest pump-and-dump stock scams. One sample identified this morning by GFI, was a heavily distorted 30-second MP3 file. A synthetic female voice was used to promote a particular stock. This voice is distorted to avoid filtering approaches based on the file signature. Once again, spammers are taking advantage of the fact that the MP3 format is one of the most common in use today, another attempt at social engineering GFI Software have uploaded a sample on their website, if you want to listen to it, click here. For further details read GFI’s mp3 spam roundup.
Check out this article/report by OmniNerd, which tested various operating systems for security. They performed a base line vulnerability scan during installation, after installation and after patches had been applied. Each installation was done to mimick as close to a ‘default install’ by clicking ‘next’ when possible. While one can argue various points of this test, they did a good job defining the operating system, configuration and resulting open ports, along with corresponding vulnerabilities. The only questions that immediately come to mind are if the Solaris install included Update 3 and why they didn’t have any charts or graphs summarizing the information.
This is hands down one of the most fair and unbiased tests I have seen in a while, based on the information in the article.
Last night I finally retired from the PHP Security Response Team, that was initially my idea a few years ago.
The reasons for this are many, but the most important one is that I have realised that any attempt to improve the security of PHP from the inside is futile. The PHP Group will jump into your boat as soon you try to blame PHP’s security problems on the user but the moment you criticize the security of PHP itself you become persona non grata. I stopped counting the
times I was called immoral traitor for disclosing security holes in PHP or for developing Suhosin (http://www.suhosin.org/).
For the ordinary PHP user this means that I will no longer hide the slow response time to security holes in my advisories. It will also mean that some of my advisories will come without patches available, because the PHP Security Response Team refused to fix them for months. It will also mean that there will be a lot more advisories about security holes in PHP.
Stefan has a history of providing well written and very technical attacks against the PHP language. If he was one of the few (only?) people that cared about security, this doesn’t bode well for PHP.
Social Implications of Keysigning
Raven & Jericho
Tue May 23 01:41:20 EDT 2006
The use of strong public encryption has always been popular among geeks. Perhaps the most commonly used and most beloved encryption for e-mail is Pretty Good Privacy (PGP); started as a free method for protecting emails or other sensitive information, later turned into a cornerstone for a large company. As PGP became more corporate, costly and used patented algorithms, another project, GnuPG, sprung up to continue to offer strong encryption to the masses.
One foundation of reliable encryption is trust. The use of encryption between two or more people relies on you being sure that the message you sent is properly encrypted to and able to be decrypted solely by the intended recipient. When using a friend’s GPG key, you must be sure that the key was created by and belongs solely to your friend. Otherwise, you may send mail that your friend cannot read (if they don’t have the key you encrypted to), or worse, mail that some other party can read (if that party does have the key you encrypted to).