GPG Replacement Just Needs to Be “Good Enough” For Now

A few days ago, Moxie Marlinspike wrote something that got the InfoSec community into a open debate.  His contention is that GPG has failed philosophically and technologically in building up 20 years of cruft.  He essentially calls for a restart, and calls GPG’s small installation base a blessing in disguise because it makes for an easier time starting from scratch.

This, not surprisingly, resulted in a lot of very strong responses, with some for, others against, and many looking for clarification.  I understand his point, and I agree with him in some parts (mostly the philosophical) but am hesitant on other parts (mostly the technical).  What follows is based on a couple of posts I made on Slashdot. Continue reading “GPG Replacement Just Needs to Be “Good Enough” For Now”

Lenovo completely undermines user-vendor trust

Looking for a computer? Thinking about a Lenovo?

I strongly advise that you reconsider your choice due to an issue that has just come to the general attention of the InfoSec community. A couple of months ago, Lenovo was caught allowing VisualSearch, one of the companies that provides adware for the consumer line of its computers, to install an update to a program called Superfish. This update installed an unrestricted root certificate authority (CA) into the certificate store.

Before I get to the explanation, if you have a Lenovo system, please check to see if you have Superfish installed. If so, remove it. It will reportedly take this bad root CA with it.  But it will not restore trust in Lenovo.  Update 1: The certificate stays behind, and it’s the same private key on every installation, meaning that someone who gets hold of it from one compromised system can use it on another.  No trust left in Lenovo whatsoever.  Update 2: To see if you have the cert installed, go to  If you don’t get a warning, then you are vulnerable.

Back to the issue. It is almost impossible to understate how bad this is. Lenovo essentially allowed flat-out attack software to be installed on a huge number of systems. With this root CA, the Superfish program replaced real certificates (like on banks, shopping sites, health sites, and anything else protected by HTTPS) with its own certificates so it could see every piece of data that you sent or received. If you went to a site in a browser, it showed a perfectly normal(-looking), perfectly secure(-looking) green lettering or bar, even though Superfish could see everything that transpired.  It is a fundamental violation of the trust between purchaser and vendor.

That’s not hyperbole. This is attack software, even if their stated purpose (to allow comparison shopping) is benign. But it does so using what’s called a man-in-the-middle attack, one of the holy grails of attack methods. Further, the certificate can be used to sign software, applets, or documents, allowing them to be recognized by Windows as safe. Anything can be run, and it will look perfectly legitimate.

That also means that anything that could subvert it could completely subvert the system, and do so with you trusting it.  It could point you to a site under an attacker’s control and convince you it was your bank.  It could ask you to install a software update and convince you that it was issued by the software vendor.  It could see everything you do, everything that left and entered your system, and report it back to somewhere else with no alerts because it would all appear completely legitimate.

I understand that sometimes companies make mistakes. They even sometimes make security mistakes. Security is hard. But this is an unfathomably bad decision by a company that should know better, especially given the attention and fear generated by their purchase of IBM’s computer lines. I was not fond of them before, and now what little doubt I had has been shattered.

Update 3: I should have included removal instructions. Here they are for Vista/7/8:

1. Open the Start Menu/Screen and type “certmgr.msc” to find the Certificate Manager. Click on it or press Enter to open it.
2. In the left pane, open the Trusted Root Certification Authorities folder.
3. In the right pane, open the Certificates folder.
4. Look for “Superfish, Inc.” in the list of certificates.
5. If it’s present, right-click on it and select Delete.
6. Click Yes to the prompt that appears.

At this point, the risk for this certificate has been removed.

Safer browsing without too much annoyance

One of the biggest challenges right now comes in keeping secure while we’re constantly connecting to systems of unknown trustworthiness.  Even when I connect to this site, on a server that I built and administer myself, which I pay for entirely from my own pocket, there’s still that little doubt in my mind.

Most other sites provide much stronger reasons to doubt them, least of all because I have zero clue how good or bad they may be.  There are companies that I trust more to maintain secure networks, and some I trust less.  My experience as a pen tester has informed this a bit further, such that about a year ago I changed how I handle my browsing.

Continue reading “Safer browsing without too much annoyance”

Getting Started in Security

I get a lot of people asking me how they can get involved in security.  Some of them are IT pros who have been in their careers for many years while others are new, like a help desk novice.  But they all want to get involved because security is the exciting place to be.  It’s the hot place that isn’t going away, unlike the rest of IT that, it seems, management seeks to automate out of existence.

Well, they’re right.  Or some of them are, at least.  It’s currently the sector least likely to be automated out of existence, but that’s largely because it’s currently too complex to do.  I remember when a lot of IT was like that.  We did much of our work by hand, as scripting was a luxury, especially on Windows.  Security will come to that point, too, but it will probably be a little while.  There are simply too many legacy systems around for it to be otherwise.

Anyway, here are some tips for getting involved in security.  These are based on my own experiences coming up from informal desktop support through servers and then into security.

  1. Start thinking like security people.  Security people by and large think…differently.  The hacker ethos is there, and it’s not just about breaking into systems.  It’s about changing things to get the desired outcome.  This applies to offense, defense, and things that have nothing to do with either.
    Here’s the hard part: If you don’t know how to do this, by all means, ask.  We’re usually happy to explain how we approach our work.  Have lunch with security people you know.  Read papers, books, and weblogs.  Watch videos from past conferences.  Even better, attend conferences like DerbyCon and your local BSides, places that are welcoming to people who are new to the field.
    Once there, ask to join a conversation.  There’s a good chance you’ll be able to join, even if just to listen.  Don’t pretend you’re better at something than you are, because you’ll be found out in about nine seconds and shunned.  And they will remember you if they see you again, like across the table in an interview.  Security is a much smaller field than people think.
  2. Integrate security into your daily work.  If you work on the help desk, start asking yourself how the callers’ actions could cause security problems, taking notes about your thoughts and running them by your security staff (another reason to have lunch with them).  If you’re further along, learn how to harden the systems you maintain.  Don’t change anything without permission, of course, but read about others’ experiences, and realize that one size does not fit all.  Just because a respected guide recommends wiping the page file on reboot doesn’t mean it’s a good idea for your environment.  The more you do this, the more you start thinking like security, the better you’ll get on with them, and the better chance you have at joining them one day.
  3. Integrate security into your daily life.  This isn’t just hardening your home systems.  Learn to spot security issues as you go through life.  I have some friends who think it’s sad and/or paranoid, but when I walk into a building, the first thing I do is start looking for ways to subvert the security in case of an emergency.  This develops mental reflexes that are necessary in any security role, as the ability to spot something amiss and react to it is critical regardless which side you’re on.
  4. Set up a lab and tinker.  Scrape together a system at home and install a free hypervisor like VMWare ESXi, KVM, or Xen.  Or get a copy of VMWare Workstation (or Player if you can’t afford it) or VirtualBox and install it on your workstation.  Download ISOs of older software like CentOS 5.0 and start looking up exploits against them.  Once you find them, look for ways to mitigate them without patching because patching is not always a solution for a number of reasons.
  5. Learn multiple operating systems.  You’re going to be interacting with a lot of different gear from different times.  If you’re most comfortable on Windows, start learning Linux.  When you do, it’s best to dive in, spending  at least a week using it as your sole operating system to force yourself to learn how it works.  Then find other environments that you don’t know and learn how they work.  You’re not necessarily going for mastery, but some familiarity with how they work goes a long way.
  6. Learn a scripting language.  Even if you’re not a developer, you need to learn something about automation.  You have two primary choices based on default installations: Python for Linux and PowerShell for Windows.  A third option, primarily for Linux, is Ruby, which is in some ways easier and more compact (and Metasploit is written in it).  Regardless, you need not be an expert (though it helps), but you should be able to read a script and describe its flow.  Find an idea and start writing it yourself.  You’ll likely do it badly, but if it’s yours, you’ll have more passion and drive to finish it, and that will help you learn.
  7. Keep your eyes open.  Security opportunities won’t always be as obvious as position postings.  Have lunch with security people.  Volunteer to work on security projects (even if security people aren’t involved).  Volunteer your time with non-profits: the smaller ones, especially, can use some help.  Go to conferences (the point bears repeating).  There’s value in who knows you as they might pass word of a new opportunity along.
  8. Don’t whine.  Very few people got into security purely by luck.  Many of those who did failed to get anywhere.  Getting into security usually takes work.  Getting ahead in security takes more work.  What will irritate security people is when someone whines incessantly that they can’t do something but clearly haven’t put forth any real effort.  Show you’ve put forth the effort and you stand a chance of getting in and/or getting ahead.

That’s what I usually tell people, though this is (amazingly) a much shorter version of the discussions I usually have.  I’m happy to talk with anyone who wants to get into security.  We still need all the help we can get.

BadBIOS: Worst fears realized or just fearing the worst?

Last week, word hit about a piece of malware referenced as BadBIOS.  Reported by Dragos Ruiu, founder of the Pwn2Own contest and a respected member of the security community, it’s said to be able to communicate with other infected systems by the sound hardware, similar in some ways to a modem.

There are still a TON of questions about this. As far as I’ve read, few if any other people have seen the hardware, but the researcher himself is considered trustworthy. I’ve seen a lot of reports that get the information wrong, like a report that BIOS was infecting BIOS via the sound capabilities, which is not (so far as I can tell) what is being claimed. It seems that what is present is an incredibly resilient and persistent malware that can communicate to other similarly-infected systems via the sound card, and apparently to affect more than one operating system, having successfully affected Apple’s OS X and Windows, as one might expect, but also Linux and even OpenBSD, the latter of which is a very unusual target.

This is, in some ways, what was feared by many when Intel said it wanted to move from BIOS to EFI/UEFI.  Intel had some very good reasons for this as the capabilities of BIOS were interfering in general computing hardware advancement, but when you put what amounts to an operating system in the firmware with room to expand, there stands a good chance that it’s going to be abused.  UEFI sits under everything, and while it’s not quite a virtual machine host (yet), it has many of those same capabilities as it can read what’s going between hardware easily, giving it the ability to alter data at many points.  It also makes it extremely difficult to pry out as few if any malware detection mechanisms can look into the hardware.

Based on a recent (mediocre) book series I’ve been reading, the thought crossed my mind that it may have been secretly sent to one or more researchers so that they would find it specifically in order to derail some secret capability developed by a state-sponsored agency or group. That’s getting into conspiracy theory, something I don’t tend to do, but those happen online more than they happen in meatspace.

In any case, it’s still something I’m watching, and I’m sure there are researchers working to develop similar capabilities. It’s not something I worry about hitting my systems, because the complexities of doing so are enormous. Most computer hardware is built to handle very specific information, but the microphones still start and speakers still end as analog, and the quality of both diverges significantly from one system to the next, even within the same model of hardware. I can see how data can be delivered via sound–we’ve done it for decades with modems–but aside from targets picked very carefully, I have difficulty believing that this could be used for something widespread, especially since the infection mechanism needs a different entry point.

It’s an interesting piece of targeted malware (if real), but it’s not going to take over the world.

Google sacrifices privacy in the name of speed

A couple of days ago, I was invited by Google to enable a new mobile Chrome feature. Thinking that perhaps this was the new QUIC protocol, I went ahead and accepted. What I got instead was an offer to run all cleartext traffic through Google’s proxy servers.

Still in extremely limited, invitation-only beta, Google’s claims regarding improved performance are probably accurate.  Being in the middle of the connection, the proxy certainly can compress traffic and convert images to a format better suited for a mobile device, particularly one with low screen resolution, reducing the amount of data to be downloaded and thus improving network performance, especially over slower connections. Exceptions would be made for HTTPS traffic any anything coming from an Incognito session.

But this is at a severe cost in privacy.  Every single unencrypted connection in a normal browser session would run through Google’s servers, allowing not only possible interception of passwords and other sensitive data (remember that not all data is legally protected) but also the possibility of feeding otherwise hidden pages into Google’s index.  Despite the potential (certainly not assured) speed advantages, I fear that Google will at least make this a prominent option for users to enable without understanding the risks.  Most people will choose convenience (in this case speed) over security given the option.

This is one of those things that I’ve long warned against.  I’m fine with home filters, but those are generally under the owner’s control.  A proxy that you don’t control gives ultimate power to whomever does own the proxy.  It could block the traffic for any (or no) reason and the information that the user gets back about the block may or may not be accurate.

It also makes for a central point of monitoring that any government would love to have the opportunity to use.  Looking at things optimistically, I’m sure the FBI would love to tap it in criminal cases, but there are plenty of other countries (like India) that are trying to or have set up monitoring as a fact of life, and I doubt that those countries’ networks will be made exempt from this feature.

I can’t get excited over this at even the most basic level. Usually when I see a new Google feature, I see what they’re trying to do even if the implementation is a little iffy. However, in this case I really can’t see the net good to come from it.

Compilation of NIST docs with sensible filenames

For some time, I’ve been collecting NIST SP800 and FIPS documents to have locally, such as when in a meeting and the need comes to reference one of them.  I have some of the older versions around, too.  A few months ago, I started renaming the files themselves with a more normalized format, and recently thought that others could use them.  The format is generally <document number>-<YYMM>-<suffix> – <Description>, though there is some slight variation.  I typically don’t keep drafts around, so you won’t find them here.  The lists themselves are after the break.

Continue reading “Compilation of NIST docs with sensible filenames”

User security rebellion? Maybe you have too many rules

On a recent pen test engagement, I found myself comparing two very different security environments and drew a lesson from it that can benefit them both.  Both are familiar environments (an IT department in one case and a flight home in the other), both are heavily regulated, and both can easily irritate their users.  The actual results, though, are very, very different.  In the first case, there is widespread compliance and in the second case, there is widespread rebellion, even if at a level that’s harder to track.

Continue reading “User security rebellion? Maybe you have too many rules”

Leading a SANS SEC504: Hacker Techniques Mentor class starting in July

To those in the DFW area (or those who know someone in the area), I will be conducting a SANS Security 504: Hacker Techniques, Exploits & Incident Handling Mentor class beginning in July.

Running over ten sessions, students are able to train with SANS at a pace designed to allow more time to absorb the course content while not being out of the office for a week or incurring travel costs.

Class starts July 23rd and will meet over 10 Tuesday evenings running from 6:30-8:30PM.  Full schedule and details are available at

Tuition is $3077 if you register by June 25th, using Discount Code DRIVE13.

Some of what you will learn includes:

  • The tactics used by computer attackers
  • The latest attack vectors and how to stop them
  • Proactive and reactive defenses for each stage of an attack
  • Strategies and tools for detecting each type of attack
  • Attacks and defenses for Windows, Unix, switches, routers and other systems
  • Application-level vulnerabilities, attacks, and defenses
  • How to develop an incident handling process and prepare a team for battle
  • Legal issues in incident handling
  • How to recover from computer attacks and restore systems for business

When registering, it would be a great help to me if you would enter “MENTOR RECRUIT” in the Comments section of the registration.

Thanks, and I look forward to seeing some familiar faces in July.

Oracle realizing that Java engine security is broken

Oracle is not a company I’m fond of.  I dislike its business practices immensely and its security stance has historically been very much a reactive one.  I realize that they have immensely complex products, but when quarterly patches regularly cover dozens of security fixes, it’s time to start wondering how seriously they take security.

Over the last couple of weeks, though, two things have happened that give me some hope that a new direction is coming.  They don’t yet cause me to change my recommendation that Java should be removed where feasible and secured where it must be present, but it’s a good change nevertheless.

Continue reading “Oracle realizing that Java engine security is broken”