Tim Medin, over at the excellent Packetstan blog, just wrote up an excellent post detailing the implementation of a NBNS spoofing module which has been added to the the latest Metasploit trunk:

This module is based off an old tool, nbnspoof.py, that I wrote to perform this attack, originally described (as nearly as I can tell) by Sumit Siddharth. It’s a very simple attack, taking advantage of the way Windows proceeds to NetBIOS Name Service lookups once local and DNS lookups fail. If you’ve ever turned a careful eye to broadcast traffic on any network with Windows systems, you’ve probably noticed that a surprising number of lookups fail through to NBNS for various reasons.

Tim does a great job of describing how the spoofing works, how to use it in the context of a penetration test, and how the module was developed. Due to its integration into the current version of the Metasploit framework, I’d have to say that I recommend it over the original python version. Maybe one day soon I’ll one-up him and try to turn it into a meterpreter post-exploitation script, in order to hijack remote hosts into being spoofers ;-) .

Until then, and in related news, I’ve submitted a talk on some other forms of Metasploit sorcery that I have developed recently to Defcon (and tomorrow to Blackhat once the CFP opens). With any luck I’ll be speaking at one or the other later this year. Either way, I’ll see some of my readers there, hopefully!

 

Shawn Moyer and Nathan Hamiel’s talk at Defcon 17, Weaponizing the Web: More Attacks on User-Generated Content, is now available on Vimeo:

Shawn Moyer and Nathan Hamiel: Weaponizing the Web (DefCon 17) from Vim EeeeOOO on Vimeo.

I just finished watching it (unfortunately missed it while I was in Vegas), and it’s very good.  I’m looking forward to playing with MonkeyFist.

 

My phone has been blowing up most of the day about this. To sum it up: On the evening of the 18th, a script kiddie that was involved in a previous post on this site (“Perl Hacking is Dead”), XXxxImmortalxxXX, contacted me and began to brag about hacking a hospital’s HVAC system. Upon further googling, it became apparent that XXxxImmortalxxXX was lying to me, and that it was the leader of the group Immortal had joined that allegedly carried out the attack. This attacker went by the name of “GhostExodus”.

As most of my readers here know, my research area is control systems/SCADA, specifically human-machine interface (HMI) software. Being involved in a field that involves elements of our critical infrastructure, I know how serious an incident involving a hospital’s HVAC system can be. Screenshots taken by the attacker showed an HMI that gave the user control over many elements of the hospital, including pumps and chillers in the operating room. Messing around with a system like this can seriously impact the health and safety of the patients.

I spent a large amount of time that weekend gathering up information on GhostExodus, and his hacker group, the “Electronik Tribulation Army”. Monday, I met with my major professor at Mississippi State University’s Critical Infrastructure Protection Center, where I work as a Ph.D. research assistant. I presented the information I had found, and we contacted the Texas attorney general’s office and the Jackson, MS FBI office, where we already had contacts. For the rest of the week, I cooperated with the FBI by sharing the information that I had found. GhostExodus was picked up by the FBI on Friday night.

I plan on sharing more, because there’s a huge amount of interesting data, images, and video involved with this case. The alleged attacker uploaded many videos of his actions to Youtube and other sites, and when I put it all together into a coherent lecture, it should be pretty informative and entertaining. Until then, there’s plenty of media coverage of the arrest:

Google News shows over 170 related stories.

The best and most accurate thing to read, however, is the criminal complaint against “Jesse William McGraw”. I have been informed that this is part of public record, however I have taken the liberty of editing out SSNs, DLs, VINs and such on this copy:

(Edit: moved it offsite, because it was chewing bandwidth a lot more bandwidth than you’d expect.  You can read it online or download it from the above link)

If you’re reading the above, I’m “CW-1″.

I plan on keeping you updated on further developments and more information as this progresses. There will also likely be some very interesting multi-media talks and lectures I can give on this, so if you want me to take the show on the road, get in touch.

For now, though, I’ve had a long day, and I shall rest :)

 

Yesterday, I posted a link to the advisory in GE Fanuc’s knowledge base.  For today, here’s some more links of interest regarding these vulnerabilities:

The latter two links actually credit us with discovering and reporting the vulnerability.

 

If you’ve been looking for my slides from the SCADA Summit that included information on the GE Fanuc iFIX vulnerabilities that I discovered and reported, then you’re still out of luck, but this is just as good, really.  If you’re an end-user of iFIX, or a penetration tester/red-team member testing installations of iFIX products, this is really all the info you need:

It’s a pretty good prose description of the vulnerabilities, in more detail than I was expecting from them.  Boiling it down to a couple of bullet points, these vulnerabilities encompass the following issues (trying not to put it in more detail than their write-up):

  • Password storage is done in an easily reversible manner
  • “Network” authentication involves passing the file over Windows shares without additional encryption/protection
  • Authentication of users can be bypassed, as iFIX’s security measures for managing users’ access run in the context of the currently-logged-in Windows user that is running the iFIX system.
  • Features that prevent operators from exiting the HMI screen can be bypassed with an auto-run capable USB drive (such as U3).

There are some excellent suggestions for end-users that would allow them to mitigate the impact of these vulnerabilities until they are fixed in a future release of iFIX.  There’s good advice in there, even if you’re running something other than iFIX for your HMI.

Enjoy!

Edit: Quick edit for clarity.

 

Over at the excellent ethicalhacker.net site, the results of the Santa Claus is Hacking to Town Skillz Challenge have been posted:

These challenges are a lot of fun, and educational as well.  Ed Skoudis puts a lot of effort into writing and judging them.  There’s a whole archive of previous challenges available here, and I highly recommend at least reading through, if not working through, some of the previous challenges.  

This time around, I managed to get an honorable mention for my entry!  I’m very happy with this.  I was unable to test the Windows-centric parts of my solution before I had to submit it and move on to real work, so that part wasn’t %100, but I did have a really solid way of getting netcat onto the web server via the command-injection-vulnerable script, and some nice netcat pivoting.  

Oh, and apparently I’m a security stud! :

We had entries from notable security studs like Wesley McGrew, Raul Siles, Ryan Linn, Mark Baggett, Zoher Anis, Paul Tartar, and others.

I might put “notable security stud” on some business cards, or maybe a button, now.

 

The kind folks who run Black Hat have gone ahead and released the audio and video of Dan Kaminsky’s talk at Black Hat USA 2008, entitled “Black Ops 2008: It’s The End Of The Cache As We Know It”, or “64K Should Be Good Enough For Anyone”.  This is the talk where he discusses the DNS flaw that has been big news lately, and even if you’re already familiar with the details, Kaminsky is a very entertaining speaker.

Thanks to blackhat.com.

 

On the 6th, I posted hashes of a file, “the_dirt.txt”, to titillate my readership while I was busy shopping the information contained within it to TippingPoint and iDefense (in case I had a shot at monetizing it :) ).  Here are the contents of “the_dirt.txt”:

The idea here is that Ruby implements its own threading model that’s independent of the operating system’s implementation of threads.  While you can have several Ruby threads rolling at once, it’ll all show up as one process to the OS.  A nice effect of this is that Ruby threads can work the same way on multiple operating systems that may not have the same native threading model.

One problem with this, is that if Ruby has to ask the operating system to do something, and that function is blocking (the thread cannot continue until the function returns), all of the Ruby threads run by that process have to wait.  Making an operating system call to do a DNS query will block all of the Ruby threads of a multithreaded application until the result is returned.  This is sub-optimal.  Ruby’s solution in this case is to carry around it’s own DNS resolver (called “Resolv”) that plays nicely with Ruby threads, since it’s written in Ruby itself.  It can even be used as a drop-in replacement for normal DNS resolution simply by doing a “require ‘resolv-replace’”.

The problem with this DNS resolver is that it’s probably the worst you’ve seen since Windows 95 when it comes to random transaction IDs and source ports.  I noticed this when I was working out a bug in my MITM DNS Metasploit module.  Take a look at the TIDs and source ports for the first 8 requests to come out of a test script:

  1. TID = 0 , SOURCE = 53571
  2. TID = 1 , SOURCE = 53571
  3. TID = 2 , SOURCE = 53571
  4. TID = 3 , SOURCE = 53571
  5. TID = 4 , SOURCE = 53571
  6. TID = 5 , SOURCE = 53571
  7. TID = 6 , SOURCE = 53571
  8. TID = 7 , SOURCE = 53571

Anyone posting a comment pointing out the subtle pattern in these requests gets to become a charter member of the Little Kaminsky Urban Achievers.

Congrats to Keita Yamaguchi, Christian Neukirchen, sheepman, and Tanaka Akira (according to the ruby-lang.org announcement) for beating me to the punch on it :) :

There’s a patch now, but I’ll bet pentesters will be seeing applications vulnerable to this for quite some time.

 

Everything we knew, plus some really neat tricks.

 

I wasn’t going to talk about this on here for a while, since the public disclosure and paper won’t be out for another six months, probably, but my major professor is so excited about it that he just had to put out a press release:

I’m going to clear up a few things on this, but I’m also going to have a bit of fun…

A Mississippi State graduate student working with the university’s Critical Infrastructure Protection Center could be nicknamed “Johnny-on-the spot.” (sic)

I feel like I’m in the Rat-Pack now.  “Hey Frank, I need a big-leaguer who can trace through this stuff in immdbg!”, “Call that kid up at MSU, he’s a real Johnny-on-the-spot.”

Robert W. “Wes” McGrew

This is the part where we abbreviate my middle name, Wesley (which I go by among people I know), put it in quotes as a nickname, and then place it after my middle initial, which is what it stands for anyw… damnit now even I’m confused.

OK, now for some clarifications:

…discovered what is being called “a significant software vulnerability” that could allow hackers the ability to gain entry to computer control systems of numerous industries and potentially threaten national security.

“We know that this software exists in very critical infrastructures in the U.S.,” said Vaughn. “Through his research, Wes demonstrated how it was possible to obtain unauthorized access to the control system in just a few seconds.

The vulnerabilties that I have found (I’m not even disclosing the software’s name yet) are very serious, however they’re not remote-access-granting by themselves.  Once you have any sort of access, remote or local, you can pretty much run all over the access controls and other security/auditing mechanisms.  It’s still troubling, as many installations of these systems have hacked-together remote access over rdp or software packages like PCAnywhere.  We’ve heard several first-hand accounts of the poor physical security of these systems as well.

There’s been a lot of instances in the past of computers on SCADA networks being compromised by worms, botnet herders, and other attackers that didn’t even realize they were on a SCADA system.  These are the sort of vulnerabilities that can turn a normal attack that happens to be on a SCADA system into an actual control systems attack.

I promise you’ll get all the juicy details you can eat in the paper.

The National Security Agency was notified immediately of McGrew’s discovery. Shortly thereafter, the Department of Homeland Security broadcast an alert that included information on how to rectify the problem.

Too bad you didn’t have your shortwave radio tuned to the right frequency or you would have caught some zero day.  Seriously though, I do think some important installations have been given some heads-up and mitigation strategies.

That’s really about all (or more than) I want say about it at this point :)

Edit: Never going to live this down on IRC:

14:05 < jgk> Robert W. "Wes" McGrew of Collinsville recently discovered
             what is being called "a tiramisu" that could allow hackers
             the ability to gain satiety of numerous industries and
             potentially threaten a toilet.
© 2012 McGrew Security Suffusion theme by Sayontan Sinha