A Maze of Twisty Fuzzers All Alike

Funny how a single innocent tweet can stir the pot. Not that I'm disappointed or that I mind, because the pot definitely needed to be stirred, but that certainly wasn't my intent on Monday. Really. But let's back up.

So I gave a short, not terribly technical presentation on Open Source fuzzing tools right before lunch at a conference on vulnerability discovery hosted by CERT at their office in Arlington. It was go to back there as I'd been to the SEI offices back in 2006 when I was working with them on the disclosure of some SCADA vulns.

Unfortunately, I didn't get to stick around the whole day (I missed Jared DeMott's presentation) and I was in and out during a conference call but there interesting talk by CERT, CERT-FI, Secunia, and Codenomicon.

But most interesting, and what led to my innocent tweet was a talk by Microsoft on how they use fuzzing and what were the results of different tools and approaches.

The conclusion I found to be surprising that they found that the use of "smart fuzzers" to have a lower ROI than the use of "dumb fuzzers" and their whitebox fuzzing platform called SAGE. Their point was the time it takes to define, model, and implement the protocol in a smart fuzzer is in most cases better spent having less skilled engineers run dumb fuzzers or white box tools.

They mentioned a talk at Blue Hat Security Briefings (I don't think this is the actual talk, but I don't have time to look for it) where they presented the bug results on a previously untested application were tested by a internally written (smart fuzzer), Peach (the dumb fuzzer?) and their whitebox fuzzing platform called SAGE. They mentioned an interesting technique of taking "major hashes" and "minor hashes" on the stack traces to isolate unique bugs. This is interesting because the primary focus has been on reducing the number of unique test cases but another approach is to look at the results. It may end up being more efficient. Of course this assumes the ability to have instrumented targets which may not always be the case, for example with embedded systems.

So Dale picked up on this and tried to apply this to the world of SCADA

We have two security vendors that are trying to sell products to the control system market: Wurldtech with their Achilles platform and Mu Dynamics with their Mu Test Suite. [FD: Wurldtech is a past Digital Bond client and advertiser] One of the features of these products is they both send a large number of malformed packets at an interface – - typically crashing protocol stacks that have ignored negative testing.

Mu responded within the comments in the blog and Wurldtech (far more defensively) on their own blog

In fact, our CTO Dr. Kube even gave a presentation at Cansecwest almost 2 years ago called “Fuzzing WTF” which was our first attempt to re-educate the community. To bolster the impact, we invited our friends at Codenomicon to help as they also were frustrated with the community discourse. The presentation can be found here.

Well I guess thie "re-education" (which sounds vaguely Maoist, I guess some of us need to be sent to a Wurldtech Fuzzing Re-education program) hasn't exactly worked although a satisfied Wurldtech customer did chime in on the Digital Bond blog. I actually agree that the need for better descriptions of fuzzing tools capabilities is needed and that was the entire point of my talk. I did a survey of the features available several dozen fuzzing tools and fuzzing frameworks that could be used to test.

I didn't spend as much time on the actual message generation as I should have and I was only focusing on Free and Open Source tools, but I identified a number of attributes for comparison such as target, execution mode, language, transport, template (generation, data model, built-in functions), fault payloads, debugging & instrumentation, and session handling. I'm not sure I completely hit my target but one of my goals was to develop some criteria to help folks make better choices on which Open Source tools could be used to most efficiently conduct robustness testing of your target. One of my conclusions (which I was pleased to hear echoed in the Microsoft talk) is that no single tool is best, no single approach is adequate--and that there are different types of fuzzing users that will require different feature sets. A QA engineer (that may have little to no security expertise) requires different features from those required for a pen-tester (or perhaps security analyst as part of a compliance-based engagement) which are still different from a hard core security researcher.

And the same applies to commercial tools you are paying tens of thousands of dollars for. One size does not fit all, regardless of the marketing (or mathematical) claims of the vendor. It would definitely be good to see a bakeoff of the leading commercial and Open Source fuzzing/protocol robustness tools similar to what Jeff Mercer has been doing for webapp scanners but I'm not optimistic that we will see that on the commercial tools because they are too expensive and the primarily customers for these tools (large vendors) are not going to disclose enough details about the vulnerabilities discovered to provide a rich enough data set for comparison.

It won't be me but perhaps some aspiring young hacker will take the time to do a thorough comparing the coverage of the tools that are out there against a reference implementation -- instead of writing yet another incomplete, poorly documented Open Soure fuzzer or fuzzing framework.

Where's the Controversy about Shodan?

So like a lot of folks I spent no more than 15 minutes this morning googling Shodan for anything interesting. I looked for SCADA protocols (there were none that I could easily find) or obvious field automation devices, so I went back to work. At best I found a bunch of VxWorks systems (and whole lot of ESX servers, shiver) and others like @chrisjager have also commented about the large number of embedded devices directly connected to the Internet, which is, indeed, frightening.

But @taosecurity just made some interesting comments, questioning how long the site will be up and hit upon in the ethical issues of a site which so obviously allows easy amplification of vulnerable systems. This was the first I've seen that even considers this angle. I'm not sure if everybody is getting ready for the holidays, trying to get the last bit of work done, or already gone but at least on the 300+ plus folks I follow on Twitter there were absolutely no questions about the site, and whether or not such as site was appropriate, ethical, etc. Just to be clear, I'm not claiming it is or is not, I'm just surprised it hasn't come up yet either way. Now if and when this happens (perhaps everyone else is so jaded and just does not want to go there) I'm sure the arguments will quickly fall into the typical cliched responses around disclosure:

• The site is raising awareness so is a good thing. Administrators can actually find and fix their systems.
• Anyone who has systems directly connected to the Internet with systems that vulnerable deserves to be compromised.
• The site is irresponsible and we should immediately DDoS it
  

And so on...

I don't actually believe any of those arguments. I'm not sure what to think. And I find that troubling. After nearly a decade in information security, I've become weary of all the arguments on either side of these sorts disclosure issue so I resort to know opinion because my opinion doesn't really matter and folks will release 0-days (or not) or more interesting sites like this (or not) and what will happen will happen regardless of any international standards or documented best practice working groups.

So back to trying to find a way to graphviz to generate SVG images within a Django app. That is at least a problem I can solve.

Another word for stakeholders

This is probably more worthy of a tweet (funny how tweeting has cut down on my blogging) but Alex Payne writes about the challenges of securing twitter (a relevant topic given my Twitter usage lately)

The thing about security is that it requires stakeholders. I have a security background, but Twitter’s security isn’t my job. In fact, my job is pretty much the opposite: I open up as much of Twitter’s functionality as I can without (hopefully) making the system insecure. So while I’ve usually been a “first responder” to security incidents because of my background, it requires a major mental context switch from the work I normally do.

Several months after I joined Twitter in early 2007, I suggested to the team that we do a full internal security audit. Stop all work, context switch to Bad Guy Mode, find issues, fix them. I wish I could say that we’ve done that audit in its entirety, but the demands of a growing product supported by a tiny team overshadowed its priority. Now we‘re in an unwelcome position that many technical organizations get into: so far into a big code-base that’s never seen any substantial periodic audits that the only way to really find all the issues is to bring in some outside help – something I sincerely hope we end up doing, but is not my call.

This post is depressing on a number of levels, mainly because it reminds me of the attitudes (and my own personal frustrations) from back in the early years of doing product security at Cisco.

I hear thing have actually have improved (however slowly) there, but obviously in the supercool world of 2.0 and social networking, they are still pre-2001.

Stakeholders, yeah I'll tell you another word for stakeholders: people that give a shit.

I remember a certain Director of Marketing in the Security & VPN BU. These guys have long since cashed out their options (and the product is killed off), so I don't feel any reservations about blogging about it. Yeah, he was a stakeholder all right, he told us (a small, understaffed, security testing team with no power or authority) that his remote access VPN product was a communication product so security didn't really apply. (Leaving out the far more interesting & cynical quote from a GSR Director of Marketing)

So I understand the frustration, but the idea (that even even if you are a developer, product manager, system administrator) that suddenly you put on your security security hat, stop the presses, fix everything is a quaint notion alongside that 20th century concept that your application, device, or TCP/IP enabled Kleenex box (a big shout out to the Hewitt appsec crew!) is behind a firewall (or not on the Internet) so therefore security isn't a big deal.

You are the stakeholder. And to paraphrase The Wire, "Is you up or is you not?"

Security is not about losing the big battles. It is about winning the small ones. The one's you can win. You do what you can and don't whine about it. If it is not your call, then it is not your problem. Worry about what is your call. That is all you can do.

Been there and done that, you are wasting a lot of time and energy. Trust me.
If you don't believe me, read Unfettered. Bless his heart, Joe is still preaching (nobody gets it, nothing is being done, etc.) the same way he did the first conference of his I attended on SCADA security back in 2003.

Either they get it or they don't and maybe if they don't appear to get it, it is because it really isn't that important in the grand scheme of things. Or maybe you aren't explaining it well enough. If it is really important it work itself out in the long run.

Verisign's Big Takeaway (And Pigs Need Wings, Too)

How unsuprising is Tim Callan's "big takeway" for anyone that has had experience on the disclosure front either inside a vendor or as a finder:

The big takeaway for me from this incident is that we need an environment where researchers and security vendors can trust each other. Alexander has explained why his team did not feel they could place that trust in VeriSign. I have explained why I feel they could have. We at VeriSign would like to see an environment where researchers need not mistrust security vendors and vice versa. We're committed to doing our part to bring back that environment, and we encourage security researchers in the future to reach out directly to us. We promise to treat you fairly and respectfully.

Yup, we'll see when that happens.

Verisign: Hardly (or, do we have a new disclosure model here?)

Now I only caught that last 5-10 minutes of the Q&A from the big talk this morning and what I heard (especially about the differences among browser implementations) was pretty interesting. Wish I would have heard the whole thing.

The whining form vendors (or so it is said in the blogs) about "wish they had been told earlier" has been amusing. Waaah.

And I like this new disclosure model (which turns the existing model upside down, vendors have to sign NDAs instead of the the researchers, brilliant!) end the fact that there is a real exploitation (however limited) prior to a fix which brings the end-user community into the disclosure dance.

However, I can't help but think this was sort of a letdown (and I don't think it is just because crypto puts me to sleep) and I liked this summary from This morning's MD5 attack - resolved

Q: Is Internet security broken?
A: Hardly. The presenters of this morning's paper stressed that it took them a long time and a great deal of computational power to succeed in their collision attack. VeriSign has already eliminated the attack as a possibility.

It bothered me that this was positioned as "critical internet infrastructure" attack/vulnerability/compromise to me which pretty much means routing or nameservice or some other collosal failure in the transport layer or below. Which this was not. Web security completely broken I could buy but Internet security, let alone Critical Internet Infrastructure security.

Hardly is a pretty good summary.

Some Non-Speculation on the CCC Breaking the CII Talk Tomorrow

I'll fess up right away. I have no interest in playing hermenuetical games with redacted texts or trying to divine the flaws that will be released tomorrow.

And the first time I read the talk writeup I thought, "Oh, God, here we go again... more preconference disclosure bullshit."

And of course they were allready at it over on Dailydave. BGP. Crypto. Everybody loves BGP and Crypto. Some new DoS?

Get ready for the FUD machines to start. Time to get ill. Get the bucket ready. But after reading HD's blog (which was based on knowledge of the vulnerability) a second time (once wasn't enough) I'm thinking perhaps this one is different:

Their research combined a known weakness in one area with a massive resource investment in another to show that a third party was vulnerable to a practical attack that affects the security of all Internet users. Security researchers often release code and technical documentation to demonstrate a flaw, but in this case, they went a step further and used the attack in the real world to obtain proof that it works.

Not in terms of the vulnerability (or vulnerabilities) to be disclosed (although that very well be) but as way of disclosing critical vulnerabilities that does neither trivializes nor desensitizes flaws that need to be addressed by vendors and the end-user community. The current model isn't working so well.

As you can already see, if folks within the hacker/researcher community (who should know better) conflate all the scary Internet infrastructure vulnerabilities of course folks technology journalists will.

In the broader IT press, Kaminsky's DNS will be treated the same as Watson's TCP as Gont's ICMP as Oulu's ASN.1/SNMP as Guardent's TCP as Lee' TCP, etc. ad naeseum.

(If I weren't typing on this damn Netbook I'd add links but google them yourself if you are interested. But you get the point)

Within the mainstream media, each of these will be covered with approximately the same number of words, the same oversimplification and carefully selected, out of context quotes, regardless of the technical merit of the research, regardless of the scope of the flaws, and the professionalism (or lack thereof) of the finders.

And each time there where will be the Oh-My-God-the-Internet-is-Doomed-thank-God-for-the-Hackers-that-Saved-It narrative.

(Compare the recent wired article on Summer DNS flaws with the coverage of the 2003 TCP vulnerability discovered by Paul (Tony) Watson (aka the man that saved the Internet) and you will see an eerie similarity.)

Another wasted news cycle, and despite the claims of the finders, the security of th e Infrastructure is not improved. End users are either confused or cynical. It is conference season again. It is just too easy to dimiss the research as an individual trying to make a name for themselves and climb the corporate security ladder, a consulting company marketing its services or a vendor hawking their wares in the guise of a BlackHat talk.

Unless there is proof.

And that is where it looks like this will be different. There is a huge difference between what you can prove with a few boxes in your basement, a one-rack testbed with 50-100k of gear, an ISP with live users, or the larger Internet.

Each environment to demonstrate attack vectors and vulnerabilities is increasingly less contrived and more and more like reality. Each is an environment less out of the control of the attacker/adversary/researcher which is where it starts to get interesting. Meaning attacks on an Internet scale.

That is why real incidents (i.e. the smurf attacks of 98, the DDoS of 2000, the worms) teach far better lessons. They provide real data. They impact the bottom lines of vendors and users and impact operational best practicies.

Compare that with flash in the pan vulnerability presentations and you'll see why in the long run I wish more researchers would go beyond proof of concept and operationalize their exploits and discovered vulnerabilities.

Regardless of the technical details of the disclosure, it will be interesting to watch what happens. Will this be more of the same or the start of something new?

Are you down with OSCP?

I'm generally weary (not wary!) about anything related to SSL or MITM  (and particularly SSL MITM's) but Traffic for Revoked TLSv1 Certificate is actually pretty interesting drink coffee while only the 1 year old is up and toddling around, catch up on blogs on your new Netbook activity.

And Richard's traffic dissection, reminded its been weeks (months?) since I've fired up Wireshark. Tcpdump, every other day, but Wireshark, not so much lately.

Merry Christmas!

Is Whitelisting really this lame?

From White Listing - The End of Antivirus?

Some people are talking about a technique called “white listing” as if it were the silver bullet that is going to save the world. It is… in the fantasy worlds. I think I can lay claim to a certain amount of expertise when it comes to white listing. White listing was fundamentally my job at Microsoft for over seven years. My job was to make sure that MS didn’t release or digitally sign any infected code. How did I do that? I used a heck of a lot of………. ok… you guessed it…. antivirus software. Recognizing the shortcomings of signature based detection, I relied upon products, such as NOD32, Norman Virus control, and others to provide heuristics to detect threats that signatures alone cannot protect against. Virtually every Microsoft product went through my labs, and I had to “white list” them before they could be digitally signed or released.

The marketing arm of current white listing companies tout anti-virus as dead and white list as the solution. What they try to hide is that white listing companies would be out of business without antivirus. White listing companies are mega-power users of antivirus software, they can’t get enough of the stuff.

SELinux and a Xen Vuln (CVE-2008-1943) Adventure

Given products like VM Fortess and the SVirt project I ran across today, I've been curious about the impact of application sandboxing/mandatory access control regimes against attacks against/using VMs.

Luckily, I happened to run across Adventures with a certain Xen vulnerability (in the PVFB backend). Now I don't claim to be able to understand even 20% of this paper, but I was pleased to see the impact of SELinux on the attack against dom0. Very cool. Plus, unlike so much vuln work it talks about the limitations of exploits and avoids all the media whoring that tends to characterize so much vuln work these days and turns me off.

Using the above guidelines, the exploit has been built. When SELinux was in permissive mode, it worked properly, handing out a connect-back root shell. However, an unsettling message was logged:

SELinux is preventing /usr/lib/xen/bin/qemu-dm (xend_t) "execmem"

And indeed, the exploit failed when SELinux was in enforcing mode. It turns out that by default the ability to map anonymous memory with rwx protection is denied by SELinux.

Thus, the call to mmap in the return-into-libc from the previous subsection failed.

There are workarounds for "execmem" protection, dutifully explained in, but I did not nd any le that can be opened with write permission and executed in xend t domain6. So, a less ecient return-into-libc payload has been created that does not use mmap. It returns into PLT entry for execv. The arguments for execv must be rebuilt at a xed address. Using repetitive returns into "assign %eax from the stack; ret" and "stosl; ret" (these sequences must be present in the qemu-dm binary) it is possible to create a payload of size const+4*length of execv arguments.

SEL and the Sweet Smell of the 21st Century

Checking watch, George H.W. Bush style, what year is it? Hey, but watch out for SNOSOFT!

Hat Tip: who the hell do you think?

An Interesting Blog on Software Security (for a Change)

Either because I was never really all that good at it or because the only reason I liked trying to break things was to learn about what I was trying to break, it is safe to say I don't spend as much time thinking about software security but I did actually find the bugs vs. flaws entry on toasa sort of interesting and not just because it got me curious was mjr's "bad science" was (a question that might liven up a team meeting next week) because for many years in various presentations I've been giving for years (including in the intro my current Nessus course I teach) the existence of three distinct types of vulnerabilities: design, implementation, and misconfiguration.

Of course I caveat this proclamation that there are probably a hundred different vulnerability taxonomies out there and this is an obvious oversimplification. And I think this oversimplification originated in the introductory prezos I used to give to Cisco product teams, many which weren't so security clueful around 2000. It was a simple, high-level conception that also corresponded to a phase of the software development cycle. Sort of, because there was the weird case where testing actually discovered design flaws in applications, which should not really be the case, but actually was.

But something about this admittedly oversimplified scheme was bugged me for a while (e.g. if someone has uncovered a fundamental design flaw in DNS or TCP, then why does everybody have to fix their implementations?) and I think John McDonald articulates some of the difficulties in maintaining (and even the value of) such as scheme.

Most compelling, to me, is the argument that the [thought] process for discovery of many classes of vulnerabilities is essentially the same.

I’ve audited for both classes of issues and everything in between. One thing I’ve observed is that the thought process is very similar. You have a system, which has data-flow and control-flow, which turns into an algorithmic system of logic. You have to brainstorm pathological ideas and trace them through the system. Or, you observe potentially problematic elements or nuances in the system and try to trace in both directions to see if you can leverage them to do something "unusual."

When it’s most fun is when you observe multiple atomic actions you can perform in the system, both legitimate and some born of mistake (like a subtle logic oversight). You then use those actions to form a system of logic of your own and in essence create your own "evil" language. You try to find some way of achieving an end by stringing all these atomic actions together programmatically. If you’ve spent a lot of time breaking systems, you probably know what I mean. If not, I assure you that I’m not just making up words to sound cool. (Yeah, this is what I think cool sounds like. The ladies love it.)

Comparing auditing assembly to auditing C is another good example. These are essentially similar tasks but performed at a different layer of abstraction. There’s myriad technical differences in what you do and how you do it, but the actual thought processes are pretty much the same.

So our presentation on BGP Vulnerabilities back in 2003 reflects this simplified view of the problem space, as well as the challenges of maintaining such a framework.

For example, the bugs discovered [through fuzzing] in IOS and gated BGP implementations (failure to properly validate bgp lengths or handle truncated BGP Opens and whatever else I can't remember) are clearly implementation vulns (or bugs). No arguing that, but the differing responses of BGP implementations to SYNs or BGP Opens sort of explodes the division.

If we look at the behavior of the IOS BGP implementation which refused to acknowledge (yes at the TCP layer) if the source IP was not a valid peer, is that a design strength (or some other term, meaning the opposite of a vulnerability) where the fact that Juniper and some of the others allowed you to send SYN's to identify Juniper BGP-listening routers. These are definitely out of scope of RFC 1771, but does that make them implementation issues. Quite, literally yes. But on the other

Which leads to the division of intentionality and culpability, which makes this design v. implementation issue useful. Design flaws/errors (or whatever) are intentional whereas implementation errors/flaws/bugs are accidental. This distinction also helps clarify by the blame game, especially if you toss in [mis]configuration flaws, which are obviously the fault of the end user -- whereas design and implementation flaws are the fault of the vendor.

Or so the mythology goes. If you get owned by something you screw up it is your fault if it is due to something you couldn't control it is obviously somebody else's problem. Well of course, even this is a little more complicated than it would seem, because if you don't patch your systems to a disclosed implementation flaw it magically now becomes also a misconfiguration flaw and it is on you.

Are these "new" TCP DoS attacks the dreaded "naptha" attacks of 2000?

Just saw the SecurityFocus article and it is hard to tell from Fyodor's article or Robert Lee's post but these smell a lot like a variation of CA-2000-21 also known as as Naptha attacks where a relatively low number/rate of sessions could kill apps and devices or at least spike their CPU pretty nicely.

I was always surprised these didn't get more play, because they were pretty nasty. I even built a Trinux package for the tools that were released. I also thought there was more potential in terms of spoofing application layer messages and the link layer (meaning not relying on connect()) to send an HTTP GET Request or some other first message, especially if it was a crypto protocol.

I remember a certain crappy implementation of SSH where you could peg the CPU with stale sessions because it did whatever RSA foo way too early.

But anyway, it is almost 2009 and who still gives a shit about TCP DoS vulns? I know I don't, but I'm probably just burned out on the whole vuln scene. After all it is all about getting your name in lights, right? Be a king for a day?

Oh that's right Fernando Gont and CPNI still do.

UPDATE:

Damn! Jose Nazario beat me by a day. What else is new.

And from Robert Graham

The problem, in a nutshell, is that they can open a TCP connection that will never be closed. The only way to get rid of them is to reboot the server. This means that I can connect to the Internet with a dialup connection, then quickly take down www.google.com (or any other server) by maxing out the number of connections.

If this statement is true, "that the connection will never be closed" (which to me, means the same thing as never timing out this was not the case with many of the implementations that I did testing of with the Naptha toolset (the srvr responder in particular) released in 2000. Some stacks did time out with a reboot. And depending on the state you were trying to exhaust different states had different thresholds, as well. Exhausting the ESTABLISHED state would respond differently to the LAST_ACK state.

Of course some stacks (and applications) just died, as well.

Patent for Aurora Vuln Fix: A Good One

I nearly spit up my Mountain Dew (an early morning had to brave 270/495 down to Alexandria) when I read Dales blog on patenting the Aurora fix.

I only have two words for this: Country First!

PDP gets a Pwnie!

I quit reading GNUCITIZEN because it made me too angry and I would write snarky comments on my blog and the Adrian and PDP would leave comments and I would be forced to argue with those young whippersnappers that are smarter than I am -- but I'll break my vow of silence to congratulate them on their pwnie in the overhyped bug category, of course! I knew you could do it.

Forget about Iron Chef, Go For Hells Kitchen

Instead of Iron Chef I think an angry arrogant British guy hurling insults at 20-something security researchers would be even more amusing: "You little fuzzer! Who do you think you are?!"

Simon vs. Hoff: Who is Baiting? Who is Switching? And why does this smell like SCADA?

Mainly because I need to get a non-political blog in the top position again (because I'm certainly no expert on virtualization security, but I am a virtualization end user who wants to know! ) but Simon Crosby's reaction to Hoff gives me a feeling of deja view in terms of the bait-and-switch approach to vulns I've heard from some SCADA vendors (or control systems standards efforts) over the years.

Although slightly more sophisticated than spouting off how many bits of encryption a protocol uses, saying that a given protocol is not Internet-facing, or claiming that to fix an implementation flaw in a weak protocol you should upgrade to protocol that uses SSL, some of the security cliches (or at worst, half truths) that undermine his credibility, and even I can recognize include:

• Open source is more secure...
• He mentions viruses and virus vendors in his first breath.
• Equating security fixes with security/insecurity (and slamming VMWare!)
• Bringing up EAL something or other
  
• Mentioning TPM in any context

Knowing a thing or two about mania, I'm also curious about this sort of manic efforts (apart from making it so small you can't even see it) to secure the hypervisor, and whether he is willing to admit that there are some classes of attacks against guests (or, obviously, against the hypervisor) that are unique (or perhaps only possible) in a virtualized environment and that they care about? Or will the AV vendors solve these, too?

Done. There no more faux Hillary (or Hilter) on top. Can sleep now.

A Quarter from Report to Disclosure: Respectable

From the CORE Advisory on Wonderware

WTF is Python?

* 2008-03-03: Core sends proof-of-concept code written in Python.
* 2008-03-05: Vendor asks for compiler tools required to use the PoC code.
* 2008-03-05: Core sends a link to http://www.python.org where a Python interpreter can be downloaded.

and

of the advisory is re-scheduled to March 31st 2008. With regards to the questions and requests about the contents of the security advisory, Core indicates that Core's technical publications are aimed at providing legitimate security practitioners worldwide with the technical details necessary to understand the nature of the security issues reported; so they are able to devise, by their own judgment, the risk mitigation approach that fits them the best. For that purpose, Core believes that it is fundamental that they have precise and accurate technical details about security issues -- as Wonderware itself has demonstrated with the request for further technical details and proof-of-concept code -- and that the whole reporting and disclosure process is transparent for scrutiny of all interested parties.

And back at ya..

The vendor says that is having trouble understanding what the value is in providing specific detail as to what technical issue is happening and asks for clarification to understand how this information would benefit organizations. The vendor acknowledges that the proof of concept code did help to replicate the issue and that without it, it would have needed more time to identify it from the report alone. The concern is that the details provided in the report may give a hacker a specific direction to look for the vulnerability. Finally, the vendor indicates that will have a better estimation for the rlease date of a fix by Friday March 28th, 2008.

A level playing field?

Thus, Core believes that it is necessary not only to indicate the mere existence of the bug, but also to explain how to uniquely identify it in the vulnerable software (to avoid confusion with all other known bugs or to differentiate it from others that may be discovered in the future). It is also important to determine how the vulnerability could be used by potential attackers so that proper detection mechanisms can be built, for example firewall rules, or IDS and antivirus signatures. While Core recognizes that this may provide some additional data to would-be attackers, clearly it also provides preciously needed information to the defenders thus, leveling a field on which Core believes the attackers are initially at advantage.

And all for just a DOS?

Welcome to the party!

I don't give a shit, I'm a researcher (and the E-Word in SCADA)

I wasn't at RSA but based on this An Open Letter to Joanna Rutkowska this session would have been either really cool (or really frustrating to see)

I think it's only fair to point out that given your performance, you're not only an "independent researcher" but more so an "independent contractor." Using the "I'm a researcher" excuse doesn't cut it.

I know it's subtle and lots of folks are funded by third parties, but they also do a much better job of drawing the line than you do.

Despite your position on the matter and unlike you, I do give a shit, Joanna. I care very much that your research as presented to the press and at conferences like RSA isn't only built to be understood by highly skilled technicians or researchers because the continued thrashing that they generate without recourse is doing more harm than good, quite frankly.

Now, I know you can't control the press or what they print, but you certainly don't seem to invest much in terms of ensuring accuracy or clarifying the corner cases you're talking about. Here's an example from a Forbes article based upon your RSA presentation:

This is actually not entirely irrelevant to another classic discussion on Ethics on the SCADA mailing list but I have to get back to getting my house ready for the photo shoot tomorrow!

For some reason this comment me of a line from the Hunt for Red October, when a much thinner Alec Baldwin, says at a critical moment in the movie, "I'm just an analyst." And the San Angelo movie theatre (full of 98C's and 98G's from Goodfellow AFB) breaks out laughing. Much simpler times.

Ah to be 19 again. Just kidding!

MoinMoin Vulns

Courtesy of a Secunia Feed I ran across the vulns in MoinMoin -- which I my wiki of choice for work or play. I don't allow any authenticated users to edit pages or upload files (apart from me) but I was paranoid enough to take my wiki down for a bit until I've had a chance to understand the issues more or until Ubuntu releases a package.

Update
franz-g4:~ mdfranz$ python hackmoin.py
MoinMoin host: i.e: http://127.0.0.1:8000/
MoinMoin host ( include http and /): http://www.threatmind.net/secwiki/
Ok, the file: README was created, and you can logging setting the cookie MOIN_ID='README' in your browser.


Yeah the exploit does indeed create (overwrite?) a README file in your data/user directory that looks like this:

aliasname=ilikecolombianpeople
css_url=
date_fmt=
datetime_fmt=
disabled=0
edit_on_doubleclick=0
edit_rows=20
editor_default=text
editor_ui=freechoice
email=just@nonrootuser.co
enc_password={SHA}hzAn1bupZwrTEQuFWlZA3TsEcVc=
language=
last_saved=1203553839.72
mailto_author=0
name=nonroot
quicklinks=podriamos-insertar-codigo-php-aqui-verdad-que-si
remember_last_visit=0
remember_me=1
show_fancy_diff=1
show_nonexist_qm=0
show_page_trail=1
show_toolbar=1
show_topbottom=0
subscribed_pages=
theme_name=modern
tz_offset=0
want_trivial=0
wikiname_add_spaces=0

So the question is, so what? Can this be used to erase/reset the password of the Admin user? Not sure. But I did discover a shitload of user preference files in my wiki, yikes! I'm sure they are harmless... I guess the key issue is whether this exploit would allow you to overwrite an existing admin users (through the web UI you can't create a new user for one that already exists, IIRC).

It would definitely appear that if you can guess the time based filename etime.time.anothertime you could.

And here is what the exploit looks like in your logs:

stinkmonkey.cable.rcn.com - - [21/Feb/2008:00:29:47 +0000] "POST /secwikiUserPreferences/ HTTP/1.1" 404 229 "-" "Python-urllib/2.4" "-"
stinkmonkey.cable.rcn.com - - [21/Feb/2008:00:30:10 +0000] "POST /secwikiUserPreferences/ HTTP/1.1" 404 229 "-" "Python-urllib/2.4" "-"
stinkmonkey.cable.rcn.com - - [21/Feb/2008:00:30:39 +0000] "POST /secwiki/UserPreferences/ HTTP/1.1" 200 23341 "-" "Python-urllib/2.4" "-

And yeah it took me 3 times because I kept forgetting the slash (as you can see) and because I'm a "jackass" (to use tqbf's favorite expletive

Some previously disclosed Cisco CLI Vulns, the joys of youth hockey practice, and fuzzing like a ninja

The highlight of my Sunday is my son's hockey practice at the Skatium here in Skokie. Among the more amusing things that almost always happen:

• One of the parents (who acts & looks like a coach, but I don't think he is) arguing with the real coach about religion (the parent is a Christian, probably fundamentalist, and the coach is Jewish, I assume)
• Eight and nine year olds tripping and falling on the ice and occasionally doing some nasty checks on each other (usually unintentionally)
  
• The previously mentioned parent (who is out on the ice for some reason, has a flattop and is a damn good skater) doing "hockey stops" (resulting in a shower of ice fragments) in the faces of kids. Today he also banged on his son's knee with his stick shouting "knee's can't get hurt" while his son was flat on his back, not wanting to get up.
  

All Good stuff. But other than that (and the upcoming election of the 12th Bishop of the Episcopal Diocese of Chicago , today I've been sort of been fixated on CLI vulnerabilities after my last blog entry on the futility of router vuln work in 2008 and Thomas's Quarterly Affirmation (reversing IOS images is not an option for a whole lot of reasons) so I was curious what was out there:

In cisco-sa-20060712-cucm we see this

The CallManager CLI provides a backup management interface to the system in order to diagnose and troubleshoot the primary HTTPS-based management interfaces. The CLI, which runs as the root user, contains two vulnerabilities in the parsing of commands. The first vulnerability may allow an authenticated CUCM administrator to execute arbitrary operating system programs as the root user. The second vulnerability may allow output redirection of a command to a file or a folder specified on the command line.

And in cisco-sa-20010131-arrowpoint-cli-fs

The Cisco CSS11000 must be configured to permit command line access to users by providing a management address and defining user accounts. Once command line access is gained by non privileged users (defined user accounts without administrative privileges), running a command requiring a filename, and providing a filename that is the maximum length of the input buffer can cause the switch to reboot, and a system check to be started which will prevent normal function of the switch for up to 5 minutes. The show script, clear script, show archive, clear archive, show log, and clear log commands are capable of causing the CSS to restart if the specified file name is the maximum length of the input buffer. Cisco Bug ID CSCdt08730.

And from cisco-sa-20060719-mars

The CS-MARS CLI is a restricted shell environment which allows authenticated administrators to perform system maintenance tasks. The CLI contains several privilege escalation vulnerabilities which may allow shell commands to be executed on the underlying appliance operating system with root privileges. These vulnerabilities are documented by Cisco bug IDs CSCsd29111 ( registered customers only) , CSCsd31371 ( registered customers only) , CSCsd31377 ( registered customers only) , CSCsd31392 ( registered customers only) and CSCsd31972 ( registered customers only) .

And Cisco Security Response: Cisco IOS Reload on Regular Expression Processing

Some regular expressions that make use of combined repetition operators ('*' or '+') and pattern recalls ("\1", "\2", etc.) into the same expression may result in a stack overflow on the Cisco IOS regular expression engine. A stack overflow will result in a reload of the device.

Given the ubiquity of dumb (IOS-like) shells on network devices (and not just on Cisco boxes), it would appear that this might be fertile ground for a tool that:

• Allowed you to connect to various transports (SSH, Telnet, serial)
• Obviously support authenticated/unauthenticated sessions and configuration modes
  
• Using built in command expansion and help documentation, map out the various commands (and their syntax) depending on the helpfulness of the shell you could probably prepopulate various payloads for common configuration parameters that have to be parse (IP addresses, netmasks, hashes, etc.)
  
• Could leverage some existing fuzzing/fault injection framework so you would have to generate control characters, malformed arguments, and other sequences
  

Although this is sort of intriguing, I doubt I have the time to pull this off. And if I've managed sketch up this idea, somebody has probably already written a tool like this somewhere. And if not, it would certainly be a more useful project than what they are teaching the kidz these days at Berkeley. Of course I'm probably just bitter that I couldn't get into any dept. there, let alone that one. Yeah some parent's hard-earned cash is going towards having their little one learn how "fuzz like a Ninja."