Today was the first day of this year’s BlackHat Briefings in Las Vegas. The biggest security conference of the year, it’s always an interesting place to be and often involves the release of new and previously unknown exploits.

The keynote speaker was Ian Angell, of the London School of Economics, who was speaking, ostensibly, about risk. He is described as having “very radical and constructive” views on the subject. His primary point was that when you put together a bunch of parts into a system, it often goes off the rails — every action leads not just to a reaction, but a loop wherein the unintended consequences feedback into themselves. This makes control very difficult (he brought up Goodhart’s Law, “any observed statistical regularity will tend to collapse when pressure is placed on it for control purposes.) The IT industry is obsessed with providing more information, but omnipresent computer screens distract and cause errors in judgment — people come to rely entirely on the system, suspending independent thought and just blindly following the machine, while simultaneously missing details in the information overload.

Humans are obsessed with categorization — the attempt to treat the similar as identical. We deal with complexity by dropping less-significant relationships from our mental models — but those relationships still exist, and this creates uncertainty and risk. Not just computer systems have this problem; bureaucracy is the most effective way to deal with normal situations, but as anyone who has dealt with one knows, it is terrible at dealing with anything out of the ordinary.

However, for all this, I found Professor Angell basically useless. He’s comes across as very smart and amusing, but he points out problems without the slightest inkling of a solution. Yes, systems create complexity, from which comes risk. Shall we then abandon IT security in favor of a hunter-gatherer society? I don’t think I could get an answer on that from him.

The next presentation was by Billy Rios and Nitesh Dhanjani on the phishing culture and community. They observed some phishing code and noticed common strings, and thought to do a Google search on them with the intent of finding other places that phishing code was in use. Instead, they found thousands of credit card numbers, SSNs, and other identity information all over the Internet, in public forums, searchable on Google. The phishers throw around identities constantly, just to prove their authenticity. Meanwhile, they phish each other constantly — most of the phishing kits they found had back-doors in them or secret code to email a copy of all identities captured to their author. They’re not hackers at all; they generally know just enough to upload a kit someone else wrote to a site someone else hacked and collect the information. Also, ironically, the Google anti-malware blacklist turns out to be a fantastic way to find already-hacked sites to put phishing kits on — it’s full of Administrative logins and passwords.

This was followed by Dan Kaminsky’s DNS update, which I’m going to discuss in a separate post; for all its hype, I think it lived up to it. Faulty DNS is a Really Bad Thing.

Michael Ossmann had a presentation to give on software radio and the future of wireless security. Unfortunately, it was long on software radio and short on security. He mostly spoke about the USRP, a piece of open-source hardware (also available pre-built for $700) that gives full software radio capabilities to a PC. It can capture a significant amount of bandwidth in a range up into the 2.4 GHz band. Ossmann’s demonstration of this involved doing packet-capture on Project 25 radios, and a replay attack on a remote-control toy. Essentially, command-line tools can capture radio on most frequencies, and then (as it’s just a bitstream) DSP techniques can manipulate it arbitrarily.

While his speech had very little about security in it, the implications are significant in the long term. Making a good radio means either using very expensive analog components, or using cheap analog components and a lot of CPU power. In a few years, “a lot of CPU power” will be available on your phone, just given the rate at which CPUs improve. Wireless (802.11) security didn’t become a big issue as soon as it was possible to crack WEP (i.e. almost instantly) — it became a big issue when wireless cards with raw packet injection and monitor mode started to be cheap and ubiquitous. Wireless hacking takes a $700 USRP now; it’ll take a cell phone in 5 years (since as CPUs get more powerful, software radio gets cheaper than hardware, it’s only a matter of time until radios in phones and such are pure software, and thus reprogrammable.) You can see the beginning of this in THC’s GSM Project. If the cell phone network finds itself, security-wise, as badly off as 802.11 is today, it could be a frightening thing.

Alex Stamos and company from iSec Partners had a presentation on Rich Internet Application frameworks.  Rich Internet Applications aren’t well-defined, but they contain one or more of the following: AJAX UIs, local storage, an offline mode, running outside the browser, access to hardware resources, or the general appearance of a thick-client app.  Adobe, Microsoft, and others have created various apps and tools to help developers create these rich web apps.

Adobe AIR is the most full-featured of them — an AIR application runs in a full desktop runtime based on Flash.  There’s no sandboxing — a locally-installed AIR app has the full powers of the user, like an ActiveX control.  You can develop them in Flash, Flex, or JavaScript.  However, AIR apps can be launched from the web by ordinary Flash files (assuming the app is already installed on your computer.)  There is a remote mode, for running directly off the web with reduced privileges, but there’s a method for communicating and even passing objects between the local (full-trust) and remote modes.  Overall, it’s a scary thing, in the way that EXEs are scary (i.e. it’s insecure, but not any more insecure than everything else.)

Microsoft’s Silverlight is rather more restricted; it’s closer to Flash than to AIR.  Silverlight apps can be written in XAML with any .NET language, and use a scaled-down .NET runtime.  There is socket support, like Flash, but it is limited to certain sockets (4502-4534) and requires a policy file (clientaccesspolicy.xml) on the target server, even if the target server is the same site it came from.

Google Gears is even less functional than Flash and Silverlight; it’s essentially running HTML and JavaScript from the local machine.  There is local storage, and data sync with an API and SQLite for relational-database-like storage.  Also, it has the ability to run processes in a threadpool outside the browser, so as not to get shut down by the browsers’ tight-loop detection.  Bizarrely, it allows the app author to customize the installation warning dialog, making it quite easy to convince people to install weird Gears apps.  It would be good for distributed malware, like cryptanalysis.

Yahoo! Browser Plus is designed to make it easy to write browser plugins, which is kind of like making it easy to make bombs.  There are some things that shouldn’t be easy, because the less of them, the better, and browser plugins (almost all of which seem to be adware/spyware) are one of them.  BrowserPlus add-ons are initialized by an HTTP call to Yahoo!, and run with full trust.  It’s like ActveX with a built-in Ruby interpreter (an old, buggy one, even.)

Finally, Mozilla Prism is a site-specific browser with the browser UI stripped off.  Formerly known as WebRunner, it’s used to “desktopize” web apps.  The risk here is comparitively low, though the script has XPCOM privileges (basically, control over the browser itself, like a Firefox extension would have.)

You can also just use HTML5 for some rich functionality, like local storage.  There is DOM storage, allowing you to persist up to 5MB of data locally, as well as SQLite-based database functionality.  DOM storage is essentially the ability to save immense cookies that are subject to SQL injection attacks.  The W3C has had better ideas.  Also, unlike cookies, you can’t easily turn DOM storage off (there’s a Firefox about:config setting, but nowhere in the UI.)  As mobile devices bundle Webkit browsers (like Safari), they’ll be subject to this type of storage — it would be pretty easy to DoS a mobile device by writing dozens of 5MB cookies.

So, what does all this lead to?  A host of new security issues we never had to think about before, of course!   The RIA data stores are vulnerable to XSS — if your email or other personal data is in an AIR or Gears app, and someone gets an XSS on the sites the apps come from, they can steal your entire data store.  You can have SQL injection against JavaScript now, thanks to SQLite databases.  The same Flash-based XSS attacks we’ve seen now work on Silverlight and AIR as well.

On the bright side, they had some good prescriptive guidance for app developers:

1. Don’t use predictably-named data stores
2. Parameterize SQL, even on local SQLite stores
3. Domain-lock sites if possible
4. Don’t use AIR when Flash/Flex/Silverlight/etc. will do fine
5. Let users opt out of RIA functionality

Finally, Ty Miller had some shellcode to show us — reverse DNS tunnelling staged-loading shellcode, in fact.  The trend in vulnerabilities has been toward client-side exploits of late, now that socket-based servers have been hardened significantly.  However, if you do buffer-overflow a client app and get it to execute shellcode, the challenge is often getting a connection back to the attacker.  Clients are often behind firewalls, proxies, NATs, or all three.

Of the common shellcode techniques (port binding, callback, find-socket, address reuse, download & execute, and HTTP tunneling), only one (HTTP tunneling) works reliably with client apps — and Metasploit’s HTTP tunneling shellcode only works on IE6 with ActiveX enabled.  DNS tunneling (like Kaminsky’s OzymanDNS from 2004) would also get back — and even more reliably than HTTP, since it wouldn’t need to worry about authenticated proxies.

DNS gets through everything.  When you make a DNS request, it goes to your company or ISP’s DNS server, which forwards it on to a top-level server (like .com) and then to the DNS server that owns the domain name.  Practically everything makes DNS lookups (as Dan Kaminsky went into today), and nothing works if they’re blocked, so any computer is all but guaranteed to have DNS access.  With a malicious DNS server, you can actually tunnel arbitrary data through DNS.

Miller’s shellcode consisted of a tiny first stage which finds kernel32, creates pipes for STDIN and STDOUT, then makes an nslookup (yes, it shells out to nslookup) for a TXT record on the malicious DNS server.  The TXT record type can be extremely long, and the record it gets back contains the second-stage shellcode and a command to run.  The second stage shellcode runs the command, captures the output, and sends it back in fragmented DNS requests.  It then polls periodically for more commands to run.  The DNS requests all have a sequence number in them, guaranteeing that they don’t get cached and always get through.

He’s making his code available at projectshellcode.com, a site where he hopes to focus shellcode research and start a collection.  I think this is of dubious value (unlike exploits, shellcode is not really very useful to security folks on the “good guys’” side most of the time), but it’ll be interesting to take a look at what he’s come up with.

Auren Hoffman at Summation has an interesting post on the “black hat tax.”  Essentially, how much do hackers and other online criminals actually cost us?  He estimates it at 25% of time and resources, after taking into account not just hackers but also scammers, phishers, and responding to law enforcement requests.  According to James Currier (who founded a good number of social-networking type sites, some of which are quite substantial), this “tax” is 25-40% for consumer Internet companies, with it being especially high in unexpected places (like online dating sites.)

That’s a lot of money.  More importantly, it’s a lot more money than most managers think we’re spending on security.

Now, the accuracy of these statistics is obviously dubious — even a respected and experienced person’s ad hoc estimate is still just an ad hoc estimate.  But it’s worth thinking about this for your company.  How much time and effort gets spent on problems that are, if not strictly security problems, problems you wouldn’t have were it not for malicious users?  This includes not just the things you do to defend your sites (firewalls, IDS, code reviews, etc.), incident response, and responding to subpoenas.  It also includes having to carefully write & test your emails to make sure they don’t get caught in spam filters, and setting up logging & auditing on your sites so you’ll be capable of responding to a subpoena if you get one in the future, and planning for regulatory compliance, and some of your disaster recovery & backup costs.  Consider not just purchases of security hardware & software and the hours of work by the security team, but also all the time consumed by product development and IT teams planning for or responding to security threats.

This “black hat tax” is your real security budget.  And importantly for security managers, this is a genuine, demonstrated cost, as opposed to the “risk” we spend most of our time talking about.  It’s one thing to say the company might suffer a $10 million loss in the case of a data breach, so we need to spend more on security.  Managers can go on believing that “it won’t happen to us.”  It’s quite another to say that the company already does lose $500,000 every year due to the cost of dealing with malicious users, and that we should spend that same money proactively, on planned security measures, rather than spending it reactively.  Don’t just think of your security budget as simply mitigating risk — think about what your company is already spending, just not on the security team.  Can you prevent some of that cost from being incurred?  Can you centralize some of these effors?  Security spending as a way to reduce cost, rather than as a cost center, may be a lot more appealing to your CIO.

A company named Phorm (formerly 121Media) has introduced a new product for ISPs.  The idea is that the ISP installs this product (basically a transparent proxy) on their network, and as their customers surf the web, the OIX  proxy replaces advertisements on web pages with advertisements on the Phorm network.  To make it more palatable, they also provide some minor anti-phishing services (the sort of thing that’s built into IE7 anyway.)

They make a big deal out of their privacy practices.  They do not maintain histories on browsers the way Google does — they just replace ads on pages based on the page’s content, kind of like Google AdSense but for image and rich-content ads as well.   Customers, unsurprisingly, don’t really care either way about this service — what’s it matter if I get CNN’s own banner ads on their pages or my ISP’s banner ads?  They’re still ads, and nobody likes them, but whose ads they are isn’t high on a consumer’s priority list.

However, products like this (generically called “ad replacers”) are going to be extremely important to the future of the Internet.  The linked article talks about how ISPs’ profit margins are narrow given their customers’ increasing appetites for bandwidth, and how this advertising revenue will help them recover.  What it doesn’t mention, though, is where this revenue comes from – it’s the ad revenue that would otherwise be given to the sites you browse.

In other words, ubiquitous use of ad replacers would boost ISP revenue while destroying ad revenue paid to web sites.  This is a tremendous threat to Google as it eliminates their sole revenue stream!  For that matter, if an ad replacer can substitute ads, why not substitute the first page of Google search results?  Google won’t sell you #1 placement in organic search… but with an ad replacer, Comcast (for example) could sell you #1 placement on Google for Comcast users.  In addition, all the small niche websites that currently pay their hosting bill (and their owners’ salaries) off of advertising revenue may find themselves unable to do so.  People hate advertising, but what happens to the Internet without it?  The free, ad-supported Internet goes away, replaced with paid, subscription-based walled gardens.  Nobody wants that, but that’s the world ad replacers lead to — and ironically, it’s a world that has no room for them, as they would then have no ads to replace.  This is difficult to fight economically, though — an ad replacer can be a tremendous source of revenue so long as there aren’t many of them.  There’s lots of incentive to make them, even though in the long run they kill the ecosystem.

What this will lead to is a new security arms race.  Publishers will have to start finding ways to “hide” ads in their pages, so that ad replacers do not recognize that they’re ads and replace them.  This will be particularly hard for the large ad networks like Google’s where the ads must be embedded in thousands of dissimilar web pages.  As the publishers come up with better ways to hide ads, the ad replacers will be updated to find them.  The result is likely to be quite a mess, and result in neither the ISPs nor the publishers getting as much revenue as they’d like.  In addition, while Phorm may promise not to build up profiles of private information on you, an ISP who did engage in Google-like privacy invasion would be able to do it far better than Google can — after all, they have all your billing info since you’re a paying customer.  Unlike Google, they really do know who you are, personally, and not just by your browsing habits.

In the long run, international backbone providers could even start replacing ads in order to avoid local legislation, though this would lead to the ridiculous situation of the same ad on a page possibly being replaced several times on its way to the user.  I don’t see any solution to this other than legislation — the same sort of “net neutrality” laws  that forbid content-based traffic shaping or Comcast-like protocol tampering could also forbid ad replacers.  Unfortunately, economic incentives aren’t likely to have much effect, since the actual end users won’t change ISPs to go to one that promises not to run ad replacers — as only the publishers, not the end users, care whose ads are seen.

Don Parker at SecurityFocus has an article called Skills for the Future about how to get a job in information security. He outlines one path, and while I don’t deny it’s a good one, and probably the most common, it’s not the only way, either.

There are quite a few different areas of specialization within information security. The one people most often think of is the network security specialist — someone familiar with configuring firewalls, network intrusion detection systems, routers, and distributed defense mechanisms like anti-virus and patch management. These people are primarily charged with securing the perimeter.

However, there are others. I’ve made my career mostly in application security — studying how to develop software to be secure, so that even if perimeter defenses fail and an attacker can interact with an application, they’re unable to take control of it. This requires different skills than the network security path — specifically, it’s important to know several programming languages, have a background in software engineering, and be familiar with how application exploits are constructed (stack buffer overflows, heap overflows, pointer arithmetic issues, command injection, cross-site scripting, etc.) and the various defenses that exist against them (both coding techniques and tools like DEP/NX, GS, ASLR, SAL, etc.)

Other specializations in security include compliance auditing and penetration testing. Compliance auditing is less technical, and involves ensuring that internal controls match up with various regulatory and industry requirements, but often those requirements are security-focused. With recent regulations like SOX and industry standards like PCI DSS, there’s an amazing amount of demand for compliance auditors. Penetration testing is often seen as the most “glamorous” of information security jobs, as it essentially amounts to being hired by companies to hack into them. It requires a very broad array of security knowledge, since the best way into a system is wherever the system is weakest — sometimes this will be network security, other times application security, and other times the people operating and configuring the system. Thus, flexibility is key. However, due to the “mystique” of penetration testing, there are more people who want to be pentesters than are qualified for the job, and more people qualified for it than there is demand for it, so it’s not a very good entry point for the security industry.

There is one thing that is important to success in the information security industry — what I call the “security mindset.” You have to be the sort of person who, when you look at a system, thinks about what’s wrong with it. In my experience, some people have just always thought this way, and some people never do. For example, in The Art of the Steal, Frank Abagnale mentions a man who happened to share a name with a notorious drug dealer. As a result, he had to carry a letter from the Department of State to show to airport security whenever he tried to fly internationally, as his name would come up on every imaginable no-fly list as someone to be detained. What do you think of when you hear this story?

For me, the immediate thought was, “Oh, so if I were wanted by police and needed to flee the country, I could just forge a letter from the Department of State saying that I was not really the wanted criminal who happened to share my name. It’d be easy enough to find out the name of some undersecretary in the State Department and get a copy of their signature. If you wanted to be really authentic, you could also buy a phone and give it to a friend who would impersonate the State Department for you, preferably one with a fax machine in case they ask for any corroborating documentation. Of course, you’d best use a prepaid cell phone so your friend doesn’t get caught, either.” It’s just how security people think — we look at a system or a countermeasure, and see how it goes wrong, and what bad assumptions the system makes. This is important because the attackers think the same way — if we can think of a weakness, they can, too, so it’s important to shore up those weaknesses. Software testers often have the same mindset — it helps them find bugs, by finding the things developers didn’t think of.

So, if you want to get into security, and you aren’t right now, what do you do? There are a few preparatory steps:

• Get at least a year or two of real-world experience in a related field — network engineering, software development, systems administration, IT consulting. You can’t get by with security knowledge alone — you have to know how to secure something.
• Get a CISSP certification. The CISSP is a great breadth-oriented certification — it shows that you know at least the basics about all aspects of security, and have knowledge outside a narrow domain. It does have an experience requirement — three years of work in one of the 10 CBK domains — but the domains cover practically everything in the IT industry, so as long as you’re not fresh out of school you can likely meet it. The CISSP exam isn’t so easy you could pass it with no experience, but it’s not very difficult, either. You’ll also learn a lot studying for it — no matter what your specialization is, it will cover areas you know nothing about (cryptography, physical security & life safety, and disaster recovery are new to a lot of prospective CISSPs.)

After that? If you really want an information security job, you really have to focus in that direction. Once you have a couple of years of experience in a related field, don’t keep taking jobs in that field — look for security jobs. If you’re not in a major metropolitan area, this can be difficult. However, I know from experience that I spent far too much time in general development jobs with a little bit of security exposure when what I wanted to do was full-time security work. I would try to get security-related assignments, doing security testing and fixing security bugs, but there’s only so much security experience you can get when it’s not your main focus, and prospective employers know this. What launched my security career was being willing to jump into an IT security job even when it was in a less desirable area for me (network & infrastructure, when my specialization was development) and involved a substantial pay cut. What that first job is doesn’t matter that much — once you’re there, you’ve gone from a person who wants to be in information security to being an “IT security professional.” It’s easier to move around to the job you want once you have a foot in the door. Remember, in the modern technology industry people often don’t stay in a job for more than 12-18 months; it’s not a lifetime commitment to take a less-than-ideal job.

Many people ask about certifications and their importance to a security career. I would say that the CISSP is vital — many employers use it as a quick check of if you’re a “real” security person. However, beyond that, there are many things that can be useful, but that experience can substitute for. I do see some value to the following:

• ISACA’s CISA certification. This is highly valued if a.) you want to go into compliance auditing, or b.) you want to work for a large consultancy. If you want to do internal, very technical security work for a corporation, it’s not important.
• Microsoft’s MCITP certifications (or their predecessor, the MCSE.) It’s a nice thing to have on your resume, showing you know a lot about Windows environments, which make up most of the corporate world. Unfortunately, these certifications are extremely test-focused. On the plus side, it means that you can pass them with no experience, just studying for the test. However, it also means that even if you have a ton of experience, you still have to study a lot for the test, as they cover a great deal of material that is rarely used in the real world (e.g. unattended deployment scripts for servers) that you’ll just have to memorize. There is a problem of “paper MCSEs” who have passed the test but know very little, which has devalued the certification in industry, but it’s still useful.
• For application security specialists, having something to show your development experience is good. Microsoft’s MCPD certification or Sun’s SCJP certification can do this. Your first job in application security isn’t going to be reviewing kernel architectures — most of the world’s applications are managed code, either .NET or Java. Thus, these are a good place to start.

I think that the technical certifications are very helpful for getting initial jobs, especially since they don’t have experience requirements like the CISSP. However, they do have a useful life — once you’re making $100,000 per year or more, no one will ever ask, or care, if you have an MCITP, MCPD, or SCJP. They show technical knowledge if people don’t have any other way to know if you have it — but a long career in IT or development will show technical knowledge even better.

The most important thing is to be good at more than one thing. Security is a broad field by its nature — attackers go for the weakest point in the chain. There’s a larger market for security generalists than specialists in any one area, and even the specialists need to have a general background. If all you can do is firewalls, you’re competing for a smaller pool of jobs than if you can do firewalls, but also UNIX or Windows sysadmin work, or programming.