I didn't know that gold can tarnish

It's been accepted for years that cryptography is hard to implement and is full of snake-oil products. The only way to be reasonably sure that encryption is effective is to:

• Stay current
• Use robust key lengths
• Manage keys/passwords carefully 
• And most importantly, only use FIPS 140-2 validated encryption.  

In general, FIPS 140-2 has always been the gold standard of encryption, and trust in FIPS 140-2 has been a cornerstone of being able to trust most security products available today.

However, that trust is now under attack.

The Arstechnica article below provides an alarming report, describing how between 2006 and 2007 the Taiwan government issued at least 10,000 flawed smart cards.  These smart cards were designed to be used by Taiwanese citizens for many sensitive transactions, including activities such as submitting tax returns.  The cards with the flaw had virtually useless encryption, putting at risk any data "protected" by the cards.   The gist of the Arstechnica article is that these failures occurred in spite of the cards being FIPS 140-2 validated, and that the FIPS 140-2 validation process is broken.

But reading the research paper which the Arstechnica article is based on suggests that it's not as simple as that...

Despite being FIPS 140-2 validated, it turns out that the random number generator used by the card (technically, the "Renesas AE45C1 smart card microcontroller" used by the card) "sometimes fails", producing (non)random numbers that can lead to certificates which are easily compromised.  This is exactly the type of failure mode that FIPS 140-2 is designed to catch.  However, the generator on this card had an optional "health check" which was intended to detect when the random number generator was failing.  Not surprisingly, the FIPS 140-2 validation for the card only applies if this health check is enabled.  In other words, if the health check is turned off, as it was on the 10,000 or so broken cards, FIPS 140-2 does not apply and you're on your own using these cards.

Here's the way the research report describes the problem (MOICA is the agency which issued the cards):

"Unfortunately, the hardware random-number generator on the AE45C1 smart card microcontroller sometimes fails, as demonstrated by our results. These failures are so extreme that they should have been caught by standard health tests, and in fact the AE45C1 does offer such tests. However, as our results show, those tests were not enabled on some cards. This has now also been confirmed by MOICA. MOICA’s estimate is that about 10000 cards were issued without these tests, and that subsequent cards used a “FIPS mode” (see below) that enabled these tests"

This is pretty standard, if you look at FIPS 140-2 validation reports, or Common Criteria evaluations, you'll always see a very precise description of exactly how the product must be configured in order for the validation to apply.   It's common to see that FIPS 140-2 validated software or hardware has a "FIPS mode", which must be enabled for the validation to apply.

Looking at the FIPS 140-2 certificate for at least one version of this chip (https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Reporte02/0212a_pdf.pdf), the report specifically says "postprocessing should be included in the users embedded software", which I believe is a requirement to include the health check.

Clearly,  this was a horrific failure.  The Taiwanese government issued a bunch of smart cards which were used to authenticate citizens and protect sensitive data, that were completely broken.  Yes, the folks producing the card made a critical mistake. But placing this at the feet of FIPS 140-2 is, IMHO, missing the point.

It would be nice if FIPS 140-2 meant a product was idiot proof, but that's not the way the world works.  Encryption is complicated and has to be done correctly or it doesn't work.  The whole purpose of the FIPS 140-2 testing regime is to ensure that encryption has been rigorously tested under controlled conditions ... and most importantly, to document those conditions so that we know how to use it in a way that can be trusted.  Just because something is FIPS 140-2 validated doesn't mean it's idiot proof or that it can't be configured insecurely.

In any event, in my opinion, despite being very clear about what they did and didn't do when testing this chip - NIST's reputation has been badly tarnished and it will take significant time and effort on their part to undo the damage.  I guess even a gold standard can tarnish sometimes ...

Here's the Arstechnica article describing the failure:
http://arstechnica.com/security/2013/09/fatal-crypto-flaw-in-some-government-certified-smartcards-makes-forgery-a-snap/2/

Here's the actual research paper describing the findings:
http://smartfacts.cr.yp.to/smartfacts-20130916.pdf

A very good overview of the problem provided by the researchers:
http://smartfacts.cr.yp.to/index.html

Tin-Foil Hat Addendum

Given the <euphemism>crisis of trust</euphemism> that the NSA, and the US Government, is currently going through - including accusations that the NSA has been surreptitiously weakening encryption products, it's very hard to avoid the theory that the NSA might have had a hand in this failure.  That's certainly possible in this case, but there's nothing to suggest that the lab issuing the FIPS 140-2 validation was complicit in this failure.

BTW, given the relationship between Taiwan and Mainland China, I've always assumed that Taiwan is constantly under cyber attack by China.  Putting on my second layer of tin-foil headgear, could this be the result of a Chinese effort, not an American one?  I'm sure the NSA is very good, but China is certainly no cyber-slouch either, and they might have a better pool of human resources on the ground in Taiwan - which would have simplified introducing this vulnerability into the card.

Finally, removing my tin-foil hats for a second, this could simply be a screw up.  Broken products get shipped every day, and encryption errors like this are subtle and hard to notice when present in only a very small percentage of the cards.

The Law of Unintended Consequences and Biometrics

So here's an interesting twist ...

Generally, the government can't force you to provide information you know, and then use it against you.  Apparently, forcing folks to incriminate themselves is a slippery slope to state sponsored torture - go figure.

As a result, the state can't compel you to give up passwords or encryption keys.  Although it's recently been challenged, and seems to be subject to subtle interpretations of the law, this protection appears to be holding up in court (http://en.wikipedia.org/wiki/Key_disclosure_law#United_States.)

But, if your authentication or encryption key is a biometric (e.g. a fingerprint), all bets are off and the state has every right to force you to give them access.  This is despite the fact that the biometric might be more secure from a pure security perspective.

This article talks about that little irony, in the context of Apples new iPhone - which can use one's fingerprints to protect the information on the phone.

http://www.wired.com/opinion/2013/09/the-unexpected-result-of-fingerprint-authentication-that-you-cant-take-the-fifth/

So, being "more secure" from a technical perspective (assuming you buy into single-factor biometric authentication) does not necessarily translate into better protection from legal intrusion. :-)

More Cool Classes

Last weekend I had the opportunity to take another really fun course.  This one was Ruby Programming for Information Security Professionals, offered by Marcus Carey at ThreatAgent.com. (https://www.threatagent.com/training)

It dovetailed very nicely with the Penetration Testing courses I took from Georgia Weidman earlier this summer.  Georgia's courses provided an accelerated introduction to using Metasploit (and some other pentesting tools).

With Georgia's classes under your belt, Marcus' Ruby class gives you one of the tools you need to take using Metasploit to the next level.  Since Metasploit modules (and Metasploit itself) are written in Ruby, Marcus' class gives you the introduction to Ruby that you need to start writing Metasploit modules.  And even if you're not itching to write an exploit module just yet, he teaches more than enough to let you read and understand Metasploit modules - which is itself a very powerful capability.

About 2/3 of the class is spent in an introduction to Ruby, starting with using the irb interactive Ruby environment, and moving on to the basics of the language.  Ruby turns out to be a delightful language and a pleasure to learn.  Marcus takes the class through the basics of the language using lots of hands-on examples, so it never gets boring.   After we've learned enough Ruby to be "dangerous", we finish off this part of the course writing some quick examples doing things like parsing json, accessing a web site, and making DNS queries.  What fun!

However, the last 1/3 of the class is the real pay-off.   That's when we start writing a Metasploit module.  The module utilizes some of the code we'd already written, and does a simple DNS reconnaissance of a selected domain.   Utilizing a template provided by Marcus, we go through the basics of producing a module which can be integrated into Metasploit.

As with the classes I took from Georgia Weidman, the class it taught via a live webinar.  It's easy to ask questions, and Marcus is very responsive and attentive to his students.  He teaches the class assuming that you're either running Ruby and Metasploit directly, or that you're running Kali.  The only "attacks" are really just accessing public DNS and web sites, so there's no need to provide sacrificial VMs for us to attack.  He provides a written outline for the class, which is very helpful as you work along with him through the examples.  After the class, he provides a video of the webinar, so you can review the class in detail.  Overall, the class is presented in an organized, interesting and professional manner.

As with Georgia's classes, this class is an incredible deal at $125 for the day long class.  If you'd like to read my rant about the cost of training, go back to my review of Georgia's class - which along with Marcus' class, is an example of what our community needs more of.

Since I've taken the class, I've been on an orgy of coding up a module for Metasploit.  It's been a long time since I've been so enthused about a project that I've gone into sleep-deprivation mode to work on it. :-)  I have Marcus to thank for that!

Anyway, here's the bottom line.  Ruby Programming for Information Security Professionals, taught by Marcus Carey is an awesome course.

This class is for you if you have some programming knowledge, but don't know Ruby and want to jump into writing Metasploit modules.  Yes, you can RTFM.  But for a relatively little bit of money, and 8 hours of your time, you can really jump-start the process and go from zero to writing a Metasploit module by the end of the day.  Of course, there's a ton about both Ruby and Metasploit that he doesn't have time to cover, but you will have enough that you can move forward by writing code ... not by just reading about writing code.

Combine this with Georgia's classes (take them first), and you'll be well on your way to being a very competent Metasploiter  (is that a word :-)

BTW, a little while ago I finally looked at Python ... and fell in love.  I've been studying it since then, with the intention of abandoning Perl for Python.  But I have to admit, Ruby really appeals to me and I'm wondering if I may just abandon Python and do all my programming in Ruby. Does that make me a fickle person? :-)

Phew! Finally Recovering from DEFCON

This was the second year that I've attended DECON "on my own dime", after a gap of about 9 years when I wasn't able to attend.

Last year, my first time back in 8 years or so, I think I was in a state of shock throughout most of the weekend.  Everything had grown so big - with 15,000 folks attending there was a line for almost everything even remotely popular.  But, if you scratched beneath the surface it was still the same DEFCON as before ... with the same passion for playing with anything that couldn't run away, just 15 times bigger and with a slightly more corporate veneer.

This year, I was a bit more prepared.  There were still long lines everywhere - and for some talks the room filled up before everyone who wanted to attend got in.  But with some planning and flexibility, it was a hugely rewarding DEFCON.

What were the high points for me this year?

This year they released the official DEFCON documentary, which was mostly filmed at last year's event.  The documentary explains what DEFCON is about and shows the history of DEFCON.  It's not bad; I learned a good bit about the early history of DEFCON.  It does a really good job of capturing some of the "hacker ethic" which is what makes DEFCON so great.  It also gives a good view into the core group which runs DEFCON every year.  On the con (sorry!) side, it is a bit of a self absorbed love-fest.  Apparently the documentary was funded by Dark Tangent (Jeff Moss, the person who runs DEFCON every year.), so it shouldn't be a big surprise that only the good side made it out of the cutting room.  But again, I recommend it.  They're giving it away for free, it's up on You Tube and lots of other places: http://youtu.be/3ctQOmjQyYg

I got a huge kick out of the car hacking talks.  Tuners have been hacking auto ECUs for years, figuring out how to rewrite the tuning tables to make car perform better.  My last track car, a Mazda Miata had a third party ECU which completely replaced the Mazda unit, allowing a huge range of custom engine tuning options.  But now cars are so much more like regular computing platforms, and are so much more computerized, they're become really interesting to the hacking community in general.  Insead of just controlling the engine, now virtually every aspect of a car is controlled by a network of computers.  Think about it, if you drive a car with an auto parallel-parking feature, there's a computer driving your car when it parks for you.  Same thing with the crash avoidance, or cruise control that maintains a safe distance from the car in front if you.  So, hacking cars has become a lot more interesting than just tweaking ECUs to run less engine timing.  They didn't talk about it here, but others have been looking at compromising a car's internal network remotely (such as via Bluetooth).  I can't wait to see these threads of work combined.  Here's one video showing some of what they've done: http://youtu.be/oqe6S6m73Zw. Here's the paper describing their work and open source tools: http://youtu.be/3ctQOmjQyYg.  Yes, I said tools - you too can jack into your car's OBD-II port and start injecting traffic onto your car's shared network. :-)

I attended the "Policy Wonk Lounge" which turned out to be a very a un-DEFCON like event.  It was an  informal opportunity for attendees to meet with some relatively high level DC .gov and .mil insiders.  It was also the only event where there was an obvious core of press attending, and it was the first time I've ever been to a meeting which was formally "off the record".   Not surprisingly (to me at least), the DC folks were reasonable, thoughtful folks who really try to do the right thing.  Nothing earth shattering was decided or revealed, but it was really useful to have an open discussion.  Here's the basic description: https://www.defcon.org/html/defcon-21/dc-21-speakers.html#Wonk

Speaking of the Policy Wonk Lounge, this was the year that "Feds" were uninvited to DEFCON in response to the NSA domestic spying issue.  I was wondering just how that would all go down ... and as near as I can tell the big impact was that the NSA didn't have a recruiting table in the vendor room (they had one there last year) or explicitly public talks.  I was pleased that the spirit of tolerance which I always considered a DEFCON hallmark still lived.  There are clearly some sharp political differences between DEFCON attendees, but I personally never saw (or heard) of it becoming an issue.

Remember Pentoo?  It's a Linux distribution focused on penetration testing.  I personally hadn't played with it in awhile, and haven't really thought about it recently.  The hot pentesting distribution for the past couple of year has been Kali (nee BackTrack.) But several talks made a point of mentioning that Pentoo still exists, and *some* people like it better than Kali.  The cool thing about Pentoo is that it's being maintained, provides a high quality alternative to Kali (i.e. a different set of tools to consider) and is based on the Gentoo Linux distribution.  That's what's really great about a conference like DEFCON, you can often read the paper a presenter had written on some topic, but when you attend the talk and the Q&A afterwards, you often pick up all sorts of gems.

Another thing that made me smile: In the hardware hacking area there were a few 3-D printers set up.  One guy had a hacked Kinnect, and was using it make and give out 3-D scans of folks (essentially a scan of your head.) You could use the scan to print a sculpture of your head on a 3-D printer. Imagine what DEFCON attendees will be showing us with those in a few years!  In fact, a photo-copy shop a block from my house just installed a 3-D printer, we live in interesting times!

I'm already excited about next year at DEFCON ...

Sometimes, life just hands you an ice cream cone

Recently, I was just sitting at my computer, when I got a call on my phone.  Unfortunately, I don't have a recording app on my phone (I did on my old one), so this is just the highlights from a few handwritten notes and my memory ...

(call from 212-777-3001)
Me: Hello?
Caller: Hello, this is <mumble>Global Soft<mumble>, we're recording errors on your computer
Me: huh?
(Really? I'm finally getting one of "those" calls)
Caller: we're getting lots of errors from your computer.  viruses, malware, ....
Me: huh?  How do you know about this stuff?
Caller: we receive error messages from your computer.  your computer is infected ... i just need to walk you through a few steps to fix it ...
Me: huh?
...
Me: huh?  I'm sorry, I'm pretty dumb about computers.  How do you know what's wrong with my computer?
Me: huh?  Oh! I know! Do you mean I bought your service when I bought the computer
Caller:  yeah, yeah, that's right.  that's what you did!
...
Caller: ok, I just need you do to a few things ...
Caller: turn on your computer ...
Caller: Let me know when you see your desktop ...
Me: huh? it's on, I'm looking right at it.
Caller: do you see your desktop
Me: huh?  I don't know ... it says dollar sign
Caller: (confused) huh? :-)
Me: huh? I see a dollar sign prompt  (I'm looking at a Linux shell prompt, but was trying to remember what a Wylbur prompt looked like ... If you're wondering: http://en.wikipedia.org/wiki/ORVYL_and_WYLBUR)
Caller: where's your desktop?
TMe: huh? what's a desktop? oh! That! there is no desktop.  This is a brand new computer they just gave me
Me: before this we did everything with punched cards ...
Caller:  how do you get to the internet?
Me: huh?  Do you mean how do we do things?  I can submit any card deck you need, the submission desk is just down the hall ...
Caller: Are you at work?  Is this your personal computer?

(... much hilarity ensues while I offer to submit cards and he tries to get me to the desktop and/or internet)

Me: huh?  Of course I'm at work.  I don't have a personal computer
Caller:  Can you get to the Internet from work
Me: I'm not authorized to use the Internet

CLICK! (he finally hung up)

:-)

I am kicking myself a bit.  Not only did I have no way to record the call, but I realized afterwards that I have a throw-away, very vulnerable, Windows-XP virtual machine (from a course I took recently) that would have been a perfect victim.   Unfortunately, I have a feeling that my dyslexia would have kicked in ... and my credit card would have ended up being denied in that case.  :-)

But, pretending I was using punched cards did give me a bit of a giggle.

Update:

Here's an article which give another example of how somebody else had fun with these guys: http://arstechnica.com/tech-policy/2012/10/i-am-calling-you-from-windows-a-tech-support-scammer-dials-ars-technica/


Update 2: Another article, also from ARS, provides more detail on how one of these operations is run (and how the FTC is taking them down.) http://arstechnica.com/tech-policy/2014/05/stains-of-deceitfulness-inside-the-us-governments-war-on-tech-support-scammers/

Update 3 (9/12/2014): There's now a metasploit module which allows you to turn the tables on these scammers. http://www.scriptjunkie.us/2014/09/exploiting-ammyy-admin-developing-an-0day/

A Couple of Cool Classes

I've devoted the last couple of Saturdays to taking the first two classes on penetration testing offered by Georgia Weidman. (http://www.bulbsecurity.com/)

The short version of this posting is that I completely recommend them, they're awesome!

The first class, Penetration Testing with Metasploit is exactly what the title promises.  It's the perfect class for someone who, like me, is fairly familiar with the tools of our trade, but has never taken the time to learn how to use Metasploit.  Yes, you can just read a book or the user docs, but learning how to use it by attacking realistic targets is a much better way to learn. (And much more fun!)

Even if you're relatively new to security, I think you can still get a lot from the class.  Here's a test: If I say "Port 80 on localhost", or "cracking hashes from /etc/shadow", does that mean anything to you?  Do you think you can stand up a pre-configured virtual machine using VMware player or VirtualBox?  If your answer to these is "yes", I think you'll be able to participate in this class.  The focus is on using Metasploit, and a few other tools ...  so if you can follow directions, you should be able to keep up.  Keep in mind, the point of Metasploit is to package exploits so that you can use them without knowing the details of how they work.  Even if you don't completely understand the exploits being demonstrated, seeing them in action is extremely valuable.

The class is entirely hands on.  Prior to the class, Georgia sends you two virtual machines, one running Windows XP and one running Ubuntu Linux.  She also instructs you to grab a copy of the Kali virtual machine (Kali, nee BackTrack, is a collection of pentesting tools.)   You'll be shocked to hear that both of the virtual machines she provides have some vulnerabilities.  :-)

Georgia runs the class using an on-line webinar system that lets her talk to everyone while she shares her screen.  She also gives out a set of slides, which provide a written backup to what she's showing.  The basic flow of the class is that you use the Kali VM  to attack the XP and Ubuntu "victim" virtual machines.  On the screen she's sharing, Georgia is running the same exploit you are, discussing it while she demonstrates it.  This is not some instructor reading from a power-point deck, it's more like watching reality TV for hackers ... except you get to play along!  Finally,  the webinar system allows students to submit questions, which Georgia is good about answering quickly and clearly.

Of course, the class is not without glitches.  As an instructor, you can't spin up a bunch of virtual machines on your laptop, interactively run malicious exploits against them and share the entire mess via a webinar/screen-sharing service from your home, without something breaking.  In both classes, some time was lost dealing with glitches, resulting in the class running 9 hours long instead of the scheduled 8.  Even with a few breaks thrown in, 9 hours is a long time.  By the end of each class I was a quivering bowl of Jello ... I have no idea how Georgia was able to keep going for 9 hours.  But each time, while I was pretty fried by the end I was also grinning like a mad man.

After the class is over, Georgia provides access to a video of the class.  She also will be granting students access to a lab network which contains additional machines to practice on.

So here's the best part ... the class costs only $100!

<Rant> I've gotten very frustrated at the cost of decent training these days.  For example, I'm a huge fan of some of the SANS courses, but there's no way I can afford them personally, and many employers simply can't afford to drop that kind of money on training.  I'm fully aware of, and OK with, the profit motive.  But it feels like the best and biggest training organizations are heavy on "what the market will bear", and light on "what's best for the industry".  Thank goodness for events like DEFCON, BSides or SNOWFROC ... without those there would be nothing for those of us who make up the "middle class" of security.</Rant>

In summary, this class is by far the best training deal I've ever encountered.  I learned some valuable skills taught by a real pro, I had a total blast and I didn't have to max out the credit card to do it.

I'm not sure when it'll be offered next, but check out: http://www.bulbsecurity.com/online-security-training/penetration-testing-with-metasploit/ for more information.

The second class, Penetration Testing Level 2, is very much a continuation of the first.   It's assumed you're familiar with the material from the first class, and goes into detail about more sophisticated attacks.  In addition to the VMs from the first class, an additional Windows-7 VM is provided.  Metasploit is still the primary tool, but other tools are also used for more sophisticated attacks.  For example msfvenom, the Social Engineering Toolkit and Hyperion are all used to package exploits. In another exercise,  one of the virtual machines is compromised and then used to pivot and attack a second machine.  These are still "elementary" pentesting techniques, but the hands-on nature of the class really takes it beyond the purely academic and makes it a valuable learning experience.

Penetration Testing Level 2 costs a whopping $200, and is worth every penny.  Again, I'm not sure when it's going to be offered again, check out: http://www.bulbsecurity.com/online-security-training/penetration-testing-level-2/

A couple of recommendations if you take one of these classes:

• Grab the virtual machines ahead of time and make sure you've got them running well.  If you're building your environment the morning of the class, you're already behind the curve.
• If possible, use a two monitor setup.  Having Georgia's shared screen on one monitor, and running Kali on the second monitor, is the trick setup for these classes.

It sounds like Georgia may create an entire series of classes along these lines ... at this sort of price point, given the high quality (and fun quotient) of the first two classes, I think that the entire series would be a pretty interesting training option.

Password Cracking is a Art

Just a quick posting to recommend the following article:

http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/

It's easy to think that cracking passwords is a point and click activity ... just grab a big password list, recruit a bunch of processing power and let'r run.  If you think that's how it works, you're wrong.

This article describes the process taken by three separate password cracking experts to attack the same list of password hashes.  They approached the challenge with different tools, different approaches and achieved different results.

The key point (other than some nice tricks) is that as with many security endeavors, password cracking is a both a craft and an art.  To be good at it, you need to know the underlying cryptography, you need to know your tools and you need to know how people behave.  And then most importantly, you need to develop creative solutions based on your knowledge and hard earned experience.

As I go about my daily work in this field, I'm often reminded of the passion and craftsmanship I experienced a very long time ago when taking a wood working class.  It was at a top design school, and I was a rank beginner surrounded by folks building beautiful pieces of furniture.  They understood how to make wood do things I could only dream about, things that seemed like magic until you understood how they did it.

Kinda like figuring out that '3e93fb79e0970b6b8229ff8bec22d069' is the hash for 'qeadzcwrsfxv1331'.

:-)