CryptoCurrency, Blockchain, & SCADA

[This was originally published on in the 2018 Q1 Vulnerability QuickView Report.]

CryptoCurrency and Blockchain: The Latest Rage

Blockchain technology, the foundation of CryptoCurrency such as Bitcoin, Ethereum, and countless others is starting to dominate the news. With the wild ride of Bitcoin prices, where one coin was worth around $19,000 in December, 2017 and a drastic fall in February, 2018 to around $6,900, the financial industry is abuzz with the possibilities. Many would-be entrepreneurs are looking to get involved, while few organizations are monitoring the vulnerabilities in this technology. Risk Based Security has been studying the security aspects for many years and has been collecting the vulnerabilities that range from annoying remote denial of service conditions, to vulnerabilities that allow a single person to mint as many coins as they like, that could lead to serious destabilization of the currency. In the coming months, we will be publishing an extensive blog on the topic of vulnerabilities in the CryptoCurrency market as we continue to aggregate blockchain-based vulnerabilities.

Case Study: SCADA Vulnerabilities

Supervisory Control And Data Acquisition (SCADA) systems are generally considered the systems that run public infrastructure, ranging from power plants and electric grids to damns and spillways. Vulnerabilities in such systems can have catastrophic consequences as we saw in 2015 when Ukraine’s power grid was attacked and portions of the country lost power due to computer intrusion. It is believed to be the first attack against SCADA systems that resulted in wide-scale power outages. Ukraine was attacked in again in 2017 using modified ransomware, that affected a wide variety of systems including radiation monitors at Ukraine’s Chernobyl Nuclear Power Plant. These devastating attacks, according to some experts, are a hint of what may come if SCADA systems are not secured in short order.

2017 saw a significant drop in SCADA disclosures, which led us to speculate in our 2017 End of Year report:

Vulnerabilities in SCADA products only accounted for 1.7% of all reported vulnerabilities in 2017, down from 2.8% in 2016. It is hard to determine if this decline in the number of vulnerabilities found in SCADA products is the result of researchers no longer focusing on SCADA products (e.g. transitioning to IoT or other software) or something else. Based on our knowledge of SCADA, it is hard to imagine it is due to SCADA security improving or vulnerabilities being more difficult to find. Despite this decrease, the potential impact for exploitation of such issues can be far greater than most organizations face.

This year, the first quarter shows an increase in SCADA disclosures, enough to suggest that this may be a new record year.

2013 Superdome Outage a Hack? The Value of Post-Incident Investigations.

[This was originally published on the OSVDB blog.]

As we approach the pinnacle of U.S. sportsball, I am reminded of the complete scandal from a past Superbowl. No, not the obviously-setup wardrobe malfunction scandal. No, not the one where we might have been subjected to a pre-recorded half-time show. The one in 2013 where hackers terrorism who-knows-why caused the stadium lights to go out for 34 minutes. That day, and the days after, everyone sure seemed to ‘know’ what happened. Since many were throwing around claims of ‘hacking’ or ‘cyber terrorism’ at the time, this incident caught my attention.

Here’s what we know, with selected highlights:

  • February 3, 2013: Superbowl happened.
  • February 3, 2013: Anonymous takes credit for the blackout.
  • February 3, 2013: Because theories of hacking or terrorism aren’t enough, Mashable comes up with 13 more things that may have caused it.
  • February 4, 2013: A day later, we’re once again reminded that “inside sources” are often full of it. Baltimore Sun initial report claimed a “power-intensive” halftime show might have been a factor.
  • February 4, 2013: The FBI makes a statement saying that terrorism was not a factor.
  • February 4, 2013: We learn that such a failure may have been predicted in 2012.
  • February 4, 2013: Of course the outage doesn’t really matter. A little game delay, and it is a “boon for super bowl ratings“, the most critical thing to the corrupt NFL.
  • February 4, 2013: By this point, people are pretty sure hackers didn’t do it. They probably didn’t, but they could have!
  • February 4, 2013: Oh sorry, it could still be hackers. The Christian Science monitor actually covers the likely reason, yet that isn’t sexy. Chinese hacker ploy seems more reasonable to cover…
  • February 4, 2013: Not only Anonymous, but ‘Rustle League’ claimed to hack the super bowl. A day later we learn that notorious Rustle League trolls were … wait for it … trolling.
  • February 5, 2013: Officials at Entergy, who provide power for that property clearly state “There was no Internet or remote computer access to the piece of equipment inside the stadium that sensed an abnormality in the electrical system and partially cut power to the Superdome…”
  • February 6, 2013: While the Superdome was not hacked on Sunday, the U.S. Federal Reserve was.
  • February 8, 2013: Multiple sources begin covering the real reason for the Superdome outage.
  • February 8, 2013: We now have a good idea what caused it, but let the blame game begin. Manufacturer error, or user error?
  • March 21, 2013: The official Entergy report is released (PDF), giving a very technical analysis and summary of what happened. Everyone but conspiracy theorists can sleep well.

The reason for this blog is that Chris Sistrunk, a noted SCADA security researcher, pinged me the other day about the report. We were curious if the failure described could be considered a vulnerability by OSVDB standards. After reading the report and several questions for him, this seems like a simple case of device malfunction / failure. Quoting relevant bits from the report:

During the testing, behavior of the relay was not entirely consistent with the function described in the instruction manual. Under some circumstances, when the current exceeded the trip
setting and then decreased below the trip setting even after the timer had expired, the relay did not operate.

This instability was observed on all of the relays tested (during testing by this engineer, ENOI, and others in coordination with S&C at Vault 24 on March 1, 2013), including the subject
(Bay 8) relay and two identical (exemplar) relays. Behavior of the device in a manner contrary to the published functionality of the device constitutes a design defect.

Interesting read and glimpse into the world of SCADA / ICS. While the notion that the outage was due to hackers, the reality is far more mundane. We could certainly learn from this case, along with thousands of others… but who am I kidding. News covering the mundane and real doesn’t sell.

The problem with SCADA goes deeper…

[This was originally published on the OSVDB blog.]

We know SCADA is virtual swiss cheese, ready to be owned if someone can reach a device. We have preached airgaps for decades, even before we knew how bad the software was. Back then it was just, “this is so critical, it has to be separate!”

The last five years have proven how bad it is, with the rise of SCADA vulnerabilities. Sure, we can overlook the bad coding, proprietary protocols, no evidence of a SDLC, and the incredible amount of time it can take to patch. For some silly reason we put up with “forever-day bugs” because something is so critical it can’t be rebooted (forgetting how absurd that design choice is). But, what if we go a step beyond that?

An ICS-CERT 14-084-01 advisory released yesterday on vulnerabilities in Festo products is a good reminder of just how bad the problem is, and how much deeper it goes. First, the product has a backdoor in the FTP service allowing unauthenticated access (CVSSv2 9.3). This can allow a remote attacker to crash the device or execute arbitrary code. Second, the device is vulnerable due to bundling the 3S CoDeSys Runtime Toolkit which does not require authentication for admin functions (CVSSv2 10.0), and a traversal flaw that allows file manipulation leading to code execution (CVSSv2 10.0). Those two issues were reported in January of 2013, making this report as relates to Festo products over a year late.

So we have a vendor backdoor, unauthenticated administrator access, and a way to bypass authentication if it was there to gain privileges. So realistically, what type of organizations does this potentially impact? From the ICS-CERT advisory:

This product is used industrywide as a programmable logic controller with inclusion of a multiaxis controller for automated assembly and automated manufacturing. Identified customers are in solar cell manufacturing, automobile assembly, general assembly and parts control, and airframe manufacturing where tolerances are particularly critical to end product operations.

Now to dig the hole deeper. Under the “Mitigation” section, we see how serious Festo considers these vulnerabilities. Paraphrased from two lines in the advisory:

Festo has decided not to resolve these vulnerabilities, placing critical infrastructure asset owners using this product at risk … because of compatibility reasons with existing engineering tools.

The two 3S CoDeSys vulnerabilities have a fix available and just need to be integrated into the Festo products. What does “compatibility with existing engineering tools” really mean in the context of software? The ICS-CERT advisory also says:

According to the Festo product web page, other products are using newer versions of CoDeSys software and may not be vulnerable to the CoDeSys vulnerability, but this has not been evaluated by the researcher.

The researcher already spent time finding the issues, reporting them to a coordinating body, and following coordinated disclosure practices. Expecting them to also evaluate which products are not vulnerable is ridiculous. This is a case of the vendor just being lazy and irresponsible.

A company that makes vulnerable critical components that affect our infrastructure and directly impact our safety, but refuses to fix them. Why is this allowed to exist in our society?


Security News Jumped the Shark, Then Beat It With a Rubber Hose


Anything strike you, the seasoned InfoSec professional, as odd about this batch of headlines? For over a decade, I have been speaking out against bullshit news articles when it comes to security and hackers. It got so bad in the past, I had to stop updating the ‘Media’ section of Errata, because so many articles were full of crap. Usually, it is one or two articles a day, some with minor issues that aren’t worth the time trying to explain. After all these years of ignoring, and seeing the same trend, tonight appears to be different. Based on the headlines alone, I know there are serious issues and at least 4 out of 5 are crap. For fun, let me dissect them and see if I am right.


IT powerhouse nurtures elite white hackers

All ‘dong’ jokes aside, you have a five paragraph puff-piece that has absolutely no real information. Skipping past the translation errors, and assuming they mean “elite white hat hackers”, this is a joke. There are two kinds of white hat hackers for the most part; ex-black/gray hat hackers who converted because they like the paycheck and virtually no risk of prison, and the white hat ‘hackers’ who go through training from ISC2 or EC-Council to obtain some laughable certification that says they know security. The latter, are not hackers. I can assure you, “nurturing” exam-crammers will not prepare you for any security incident, let alone the implication of Cyberwar. You want to recruit “students” to do all this? You are doomed already.


New Algorithm Lets SCADA Devices Detect, Deflect Attacks

I read about this earlier yesterday. When I skimmed the article I first read (which I can’t find now), I honestly dismissed it as an Onion parody site. The entire article read as pure science fiction with a healthy dose of humor, because reality was not to be found. Surprise, later tonight it pops back up on ISN, and a search shows several other articles about it.

First, anyone in security for more than a few years have seen this academic shit before. These super-smart fucktards holed up in a lab have magically found a solution for real-world problems! The same problems they have never been subjected to, or been a part of fixing. They get news, and likely grants to do more bullshit research, while the real world suffers. There was an article, pretty sure in Time magazine that illustrates this problem. I can’t find the article because like most companies, Time can’t implement technology correctly and their search engine is absolutely worthless. Anyway, the gist of the article is that doctors fight to get grants, to do pedestrian research that is designed to help them get the next grant. Nothing they do is really designed to cure anything. History shows us that only radical research, a break from the norm, will lead to breakthrough research that may help us dramatically. The same problem exists in academia when it comes to InfoSec. I can’t remember a single time when the ivory tower dipshits actually solved anything.

So looking at this new miracle system, what is really there? They have developed a “watchdog” service that is not new. In fact, it is an old reliable mediocre offering in service. Instead of watching for “attacks” and “deflecting” them, it watches for anomalies. Welcome to 1992 bitches. Your first clue that this entire research is bullshit? Why is this specific to “networked control systems – which are used to coordinate transportation, power and other infrastructure across the United States”? Hint: IT ISN’T. Those systems suffer from the exact same classes of attack as any other system on the Internet. Overflows, DoS via saturation, SQL injection, XSS, etc. Don’t believe me? Go look at a comprehensive list of SCADA vulnerabilities and tell me which one is unique to SCADA.

How sure am I? I just sent off the following email to this “doctor”. Further, I bet that in 1, 3, 5 .. whatever years, we will have the same problems as we do now. Full paper is titled “Convergence and Recovery Analysis of the Secure Distributed Control Methodology for D-NCS“.


And really, many of us in the industry know what all that fancy math crap means. You are either doing pure crypto and it is badass, or it is absolutely theatrics to hide the fact you know shit.

(Credit: unknown. Linked to me by addelindh.)


[UPDATE: I mixed up my ‘million heist’ articles. I thought this was the “How I ‘stole’ $14 million from a bank: A security tester’s tale“. While that article did not go out on ISN, making it 3 out of 5 that were crap, my response is to that article. Oops! Thanks to Oliver Lavery for pointing this out.]

Detangling the $45 Million Cyberheist

Honestly, I wouldn’t have even noticed this one 12 hours ago. That monkey Ira Winkler has been claiming he could steal billions from any company for over a decade, so any fluff in media about dramatic thefts don’t even register. However, shortly after this piece was published, someone messaged on Twitter saying it was bullshit.


Who is right? No clue. I haven’t been able to vet either of them. But I know that when a news article comes out with some ‘super hacker’, and someone unknown to me that has no apparent reason to lie speaks up, I am likely to believe them, not the media whore. I can’t expect evidence to be produced on that short order, but I told Oliver Lavery that it would require such to document the alleged fraud of Nish Bhalla. I know who I believe, and it isn’t Bhalla.


Critical Linux vulnerability imperils users, even after “silent” fix

Oh jeez, where to begin. First, let’s put this in the terms more people can understand. This is what has been titled “Linux Kernel kernel/events/core.c perf_swevent_init Function perf_event_open System Call Local Privilege Escalation” by OSVDB, who issued ID 93361 for the vulnerability. Second, notice the date of the article is 2013-05-13, when the actual fix for this vulnerability was released 2013-04-15. Yes, the fix has been out for almost a month. Uh, wait, why is this news? Linux vulnerabilities are a dime a dozen. Thirteen days after this vulnerability was another local privilege escalation.

Uh, squirrels! I lost focus here. Why is this an issue again? Is it because of a “silent” fix? Or is it because developers fix a metric fuckton of bugs, most of them not security related, every single week… and this time they forgot to mention security implications? Why is THIS bug more severe than any other Linux Kernel privilege escalation vulnerability again? If you look the last five similar bugs before this one [1] [2] [3] [4] [5], you see they were fixed same day as far as any mainstream announcement or publication of the vulnerability.

Oh, do you want outrage? Jump back to the vulnerability disclosed on 2013-02-25, that was discovered on 2012-07-14, and fixed a day after disclosure. That breaks the trend of the Linux Kernel group to be sure.

Look, anyone who knows me will verify I am the last to apologize for software vendors. I have been riding their collective asses for over a decade. If I stand up for a vendor, any vendor at all, you should at least examine the evidence. When it comes to transparency, the Linux Kernel team has blazed the trail for many years. They have mail lists and kernel commits and contribute to the oss-sec list. They aren’t interested in politics, or hiding vulnerabilities. If you take the time to read through commits and bug reports for the Linux vendors (p.s. I HAVE), you will see these developers quickly, and publicly take responsibility for their fuckups. They are quick to fix the issue and get things squared away as fast as possible. These are not the developers you should be worried about, when other companies will go over 1,000 DAYS before fixing a vulnerability sometimes.

So really, is this news? Is anyone at risk, more than usual? Any Linux admin who waits on mainstream releases, will be vulnerable for days / weeks anyway. Admins who keep up with the new patches, will be safe. This is BUSINESS AS USUAL IN THE LINUX WORLD.


Every single night, I think the InfoSec industry has hit a new low. On a good night, I think the industry kept even. They didn’t improve, they didn’t get worse.

Tonight is evidence that we can collectively sink much lower, in leaps and bounds.

Don’t believe me? Just witness this ivory tower math bullshit that completely backs my wild theory that I have spoken the truth. Call the press!


“Threat Intelligence”, not always that intelligent.

I’ve been in the security arena for some time now, like many of my friends and colleagues. For over a decade, we have been presented with several vendors that deliver yearly reports summarizing various attributes of the industry: vulnerabilities, hack attacks, spam, malware, breaches, and more. They are typically delivered in summaries that can be read by any level of an organization. More recently, they center around ‘infographics‘ that attempt to convey the major points in an aesthetic fashion.

Most reports are released with a lot of fanfare; news articles that praise the report, hem and haw over the findings, and tell users things are bad. What we rarely see is any establishment, news or otherwise, challenge the data. The few that do are typically lost in the mass of blogs and are given as much scrutiny as the articles they debunk. Even when data is out there to quickly refute such a report, the people seeking to do so are few and far between; even when it is their job to do so.

The reason? Security companies, professionals, and journalists are complacent. They are happy to get the numbers that help them. For some, it sells copy. For others, it gets security budget. Since it helps them, their motivation to question or challenge the data goes away. They never realize that their “threat intelligence” source is stale and serving up bad data.

All of this came up again with today’s release of the Symantec Internet Security Threat Report (ISTR) [Full report – PDF]. Note that I am an officer of the Open Security Foundation (OSF), and we track two of the many general data points that Symantec does. We run a vulnerability database, and we run a database that tracks breaches. Symantec has previously used OSF breach data, but recently stopped after being informed that it was not acceptable to do so commercially without a license. I believe this is the first report that uses their own. And it shows. That said, I am only going to focus on vulnerability data, as that is my real area of interest and where I spend a majority of waking hours.

In addition, Symantec maintains one of the world’s most comprehensive vulnerability databases, currently consisting of more than 51,644 recorded vulnerabilities (spanning more than two decades) from over 16,687 vendors representing over 43,391 products.

Given the number of vulnerability databases (VDBs) out there, at least ones that could be considered sizable by any measure, this is technically true. However, the rest of the quoted material reminds us that they are not even close to comprehensive, and their numbers are in line with specialty databases that focus on a specific purpose or type of information. According to the report, they cataloged 6253 vulnerabilities in 2010, 4989 in 2011, and 5291 in 2012. To put that into perspective, that is 2877 less than IBM/ISS X-Force, 4485 less than Secunia (note: their abstraction will result in duplicates and a higher count to some degree), and 1289 less than CVE/NVD, which is the “no child left behind” of VDBs. Seriously, Symantec isn’t even keeping a 100% mapping to CVE, and they call their database “comprehensive”. Symantec’s 5291 vulnerabilities in 2012 is approximately 58% of the vulnerabilities cataloged by OSVDB. As one project moderator said, a generous professor might even round that to a D-.

Looking further, Symantec’s report says they cataloged 14 ‘zero day’ vulnerabilities in 2010, 8 in 2011, and 14 in 2012. In this context, ‘zero day’ means “A zero-day vulnerability is one that is reported to have been exploited in the wild before the vulnerability is public knowledge and prior to a patch being publicly available.” This is basically the same definition OSVDB uses for our “Discovered in the Wild” flag. However, our numbers differ from theirs: 39 in 2010, 31 in 2011, and 25 in 2012. Note that tracking this specific statistic is very difficult for any VDB. I can say with certainty that we have not flagged all of the vulnerabilities that fit this bill, but we have made a considerable effort to do so based on the information available.

Several reports including Symantec, IBM / ISS X-Force, and others have recently started highlighting statistics surrounding the vulnerabilities in web browsers. This probably seems simple to most people, even many security professionals. I can assure you, that is not the case. As a recent example, Carsten Eiram of Risk Based Security (a sponsor of OSF / OSVDB) has spent the last three months doing extensive analysis and reworking of WebKit vulnerabilities. WebKit serves as the central rendering engine for several browsers including Google Chrome, Apple Safari, RIM / BlackBerry, and soon Opera. This generally means that any vulnerability in WebKit will likely affect the four browsers mentioned, and more. In the real world, due to vendors not playing well with others, we see Apple release vague vulnerabilities attributed to WebKit months after Google Chrome does the same. Carsten’s digging and analysis has found a considerable amount of duplicate CVE assignments as a result. In addition, he has found many additional vulnerabilities that were either silently patched by vendors, or remain unpatched currently, simply by using the same resources as the developers. With this in mind, the Symantec statistics are more revealing:


In 2012, they show 38 Apple Safari, 30 Google Chrome, 21 Mozilla Firefox, 7 Microsoft IE, and 4 Opera vulnerabilities. Given that OSVDB has cataloged 219 vulnerabilities in WebKit in 2012 alone, that means the Symantec statistics are worthless. Those 219 vulnerabilities largely affect both Chrome and Safari, as well as other browsers. Even if we switch to look at vulnerabilities specific to Google Chrome we see 221, and for Apple Safari we see 66 distinct vulnerabilities. This kind of oversight in browser statistics is, for lack of better words, amateur hour.

[Update 6/7/2013 – As pointed out in a comment below, I misread this as # of vulns rather than percentage. I am leaving the paragraph above in full for posterity. However, please note that all of my comments would also affect their percentages as well. I certainly screwed this part up, but their stats are still wrong. =)]

Another hot topic the last two years are vulnerabilities in SCADA (Supervisory Control and Data Acquisition) systems. These are the systems that run vital parts of the world’s infrastructure, including electric, gas, sewage, and more. According to the Symantec report:

In 2012, there were 85 public SCADA (Supervisory Control and Data Acquisition) vulnerabilities, a massive decrease over the 129 vulnerabilities in 2011.

These statistics, if used for any guidance in SCADA facilities, should be criminal. OSVDB cataloged 167 SCADA vulnerabilities in 2011, and saw it jump to 211 in 2012. We’ve already cataloged 66 SCADA vulnerabilities in 2013, due to increased diligence in monitoring SCADA vendors for reports that may not make their way to ICS-CERT.

Toward the end of the report, in their “Looking Ahead” section, they give some general predictions of what is to come. “More State-sponsored Cyber Attacks”, “Social Media Will Be a Major Security Battleground”, “Sophisticated Attack Techniques Trickle Down”, “Attacks Against Cloud Providers Will Increase”, “Websites Will Become More Dangerous”, and “Increasingly Vicious Malware”. These are hardly ground-breaking or interesting, as they have all been the status quo for many years. What I find interesting is that the statistics they offer show a drop in vulnerabilities, both overall and in specific sectors such as SCADA. Symantec’s numbers don’t support their predictions very well.

I think it is fair to say that Symantec has lost sight of the real value of such reports. Instead, I envision Symantec planning meetings about the graphics, presentation style, and narrative they’re presenting. Vulnerability statistics are not easy; in fact, they are exceedingly difficult to get right. You would think that a company with the resources and longevity of Symantec could figure that out. Unfortunately, the report has become the focus, not the reliable data that should drive it.

Ferreting Out Unique Vulnerability Data in OSVDB

[This was originally published on the OSVDB blog.]

In previous blog posts and on Twitter, I have shown and mentioned various methods for searching OSVDB to find interesting data. However, there is no written guide to the ins-and-outs of the data. The search interface is simple enough, but it can be used in a manner that allows for some complicated and useful searches that are not immediately obvious. This blog post will show several examples and highlight some of the interesting data we have available, along with an explanation to the method of our madness.

The OSVDB classification system allows for a variety of one-click searches. Using the search interface and selecting any of the classifications (single, or multiple) will let you quickly search for denial of service, exploit public, security software, and a lot more. Note that our data set is not complete, and not all of our entries have classification data. Do not rely on this type of search for complete results. Over time as the data set is completed, it will provide powerful one-click searches that will make for interesting metrics.

While our classification system is robust, it has been a struggle for us to determine if we want to add classes of issues as a new classification option, or use specific keywords that can be searched for. While a classification box is convenient, it can quickly become bloated if there are hundreds to choose from. We have “security software” as a classification because of the irony in software designed to protect you from threats adding to your vulnerability footprint. In the coming year, we may expand the ‘OSVDB’ classification box to allow for additional searches, where that box can be hidden entirely if desired. Until then, there are several fun keyword-based searches you can do:

  1. SCADA, the hot topic lately. Using the “vulnerability text” field, input “SCADA” and select “All Text” (defaults to “Titles only”). This will bring back all vulnerabilities related to SCADA products.
  2. Another field that has been interesting to us for several years, that will likely gain more attention this year in the wake of recent election problems, is Electronic Voting Machines. We’ve all read articles about the insecurity of Diebold for example. But have you looked at just how bad it is, and how bad the other vendors are? Do a “vulnerability text”, “all text” search for “electronic voting machine”. Prepare to be scared for the coming elections.
  3. There has been an increasing interest in vulnerabilities in embedded computers found in cars. While “car hacking” has been going on for many years, a big part of that field is based on modding and enhancing a car, not so much exploiting vulnerabilities in it. OSVDB has only delved into this topic a little bit so far, but it has been on our radar for some time. Doing the same “all text” search for the word “automobile” will bring up what we have. There are dozens of research papers and sites on our list to check out as time permits.
  4. We have spent a lot of time digging into the history of encryption algorithms, noting when they were effectively compromised or proven vulnerable to varying degrees of practical attacks. Having these in the database makes for an interesting history, great reference, and potentially helpful to pen-testers that find applications using insecure algorithms. Even if you don’t have time to leverage the weakness during the test, you can provide a standardized reference in the report. To find these, do a “vulnerability text”, “title only” search for the word “algorithm”.
  5. Using specific keywords in our standardized titles, quick searches can be performed for other interesting sets of vulnerabilities. For example, the word “hardcoded” is used to denote when a vendor uses an account name, password, community string, or other piece of identifying / security information in a manner that does not allow the user to change it. It is scary to see that hardcoded accounts and credentials are still being used in 2012, by security vendors no less. In a similar vein, the word “persistent” is used to denote other conditions where some form of weakness will continue to be present, regardless of administrative action.

Other interesting search tips:

  • “all text” word searches; botnet shows the increasing vulnerabilities found in botnet software
  • Want to find vulnerabilities in Drupal, but not all those third-party modules? Title search “drupal -module -theme” to see the ‘core’ software issues.
  • Similarly, title search for “wordpress” and “wordpress -plugin” to get a feel for the disparity in vulnerabilities between the core software and third-party plugins.

These represent just a few examples of the types of searches you can perform using OSVDB to ferret out interesting data and vulnerabilities that tend not to make it in the other VDBs.

Coffee makers are SCADA, right?!

[This was originally published on the OSVDB blog.]

Steven Christey of CVE posted asking a question about VDBs and the inclusion of coffee makers. Yes, you read that correctly, vulnerabilities are being found in coffee makers that are network accessible. Don’t be surprised, we all knew the day was coming when every household appliance would become IP aware.

Before you laugh and spew your own coffee all over the keyboard, consider that the vulnerabilities are legitimate in the sense that a remote attacker can manipulate how the device performs and possibly do physical damage to the unit. This is really no different than SCADA devices such as air conditioners that are IP aware.

Some replies (like mine) were a bit more serious suggesting this type of vulnerability is definitely worth inclusion in OSVDB. If we can’t draw the line between coffee makers, air conditioners and other SCADA devices today, we will be able to in a year or years from now? At some point, the blur between computing device and household appliance will be too hard to distinguish. Rather than waste too much time arguing that line, why not track these few vulnerabilities now that might be a bit primitive, but will surely show historic value if nothing else.

Other replies were a bit less serious but fun, suggesting that making weak (or no) coffee would lead to disgruntled code writers that produce poor code filled with more vulnerabilities. Either way, count on us to include vulnerabilities in your favorite IP aware devices, kitchen, computing or otherwise, to this database.