This requirement was put in place to prevent use of certain older C runtime functions that lead to buffer overrun flaws and have been deprecated. In the Security Development Lifecycle book, an entire chapter is dedicated to the topic of banned function calls. In the book, we also provide a copy of the banned.h header file on the companion CD. This header file allows you to locate any banned functions in your code.

On MSDN, we have document the SDL list of Banned Function Calls, but the header file has not been publicly available outside the SDL book until now. Today, we are providing the banned.h header on the Microsoft Download Center.

Find the banned.h header here

By including this header file, then using #include “banned.h”; you will be able to locate any banned functions in your code. The full list of banned APIs is also included in the header file.

Alternately, if you are using the compiler in Visual Studio 2005 or later, you have a built-in way to check for these banned functions. To catch banned C runtime functions, you can compile with /W4 and then triage all C4996 warnings. In code reviews, you should always remove any code that disables the C4996 warnings - e.g.: #pragma warning(disable:4996). This is one simple way to ensure your code is released without banned functions.

Sanitizing your code to remove potentially insecure APIs is a vital protection. Whether you include the banned.h header file or leverage the /W4-C4996 warnings in the Visual Studio 2005 compiler, you now have two ways to check your code and meet another SDL requirement in your development phase.

My favorite talk, as expected, was the Sotirov/Dowd talk on How To Impress Girls With Browser Memory Protection Bypasses. The attack is a conceptually simple, yet completely reliable technique for exploiting vulnerabilities in web browsers. Of course, the media has sensationalized the impact of their findings, but ultimately, this is still significant as far as browser-based exploits are concerned. It’s worth mentioning that part of the technique allowing them to load a .NET DLL at an arbitrary location under Vista was reliant on an implementation bug wherein the OS disables ASLR if the version in the .NET COR header was below a certain value. However, the address space spraying and stack spraying techniques are likely to be extended to other platforms utilizing similar memory protection mechanisms.

As for the girls? I can report first-hand that the ladies at TAO on Wednesday night were hanging on Alex’s every word. They were particularly impressed when he whipped out the laptop for a live demo. Unfortunately, none of the dozen iPhone owners in the immediate vicinity thought to snap a picture (too busy Twittering). Oh well.

I also enjoyed Hovav Shacham’s talk on return-oriented programming. Simply put, he described a generalization of the return-to-libc shellcode approach with the intent to demonstrate that one could achieve Turing-complete computation using “found code” in process images. By chaining together series of mini-computations ending in return (RET) instructions, it was possible to build higher-level programming constructs such as branches and loops. The nature of the x86 instruction set provides some flexibility because instructions are interpreted differently depending on how you align the instruction pointer (i.e. the old shellcode trick of searching the process image for any JMP EBX instruction and using that as your EIP). In RISC architectures such as SPARC, however, you don’t have that luxury; if your %pc isn’t aligned properly you get a bus error. So it was quite interesting to see that they were able to extend the concept to RISC. The practicality of the attack technique is limited by the fact that the shellcode is tuned to a particular binary image — if the shellcode was built using instructions extrapolated from glibc 2.3.5, it won’t work for a system running glibc 2.4.

I thought Scott Stender’s talk on Concurrency Attacks in Web Applications was interesting as well. In a nutshell, spewing thousands of simultaneous requests at web application transactions that are not thread-safe can create interesting problems. In the presentation, Scott ran his demo against a VM running on the attack machine. I found myself wondering how effective the same attack would be over the Internet — would it be significantly less reliable (or not at all)? Race conditions are generally easier to exploit locally than remotely due to more predictable execution conditions. Certainly this is an under-tested vulnerability class though.

One presentation I wasn’t able to attend but want to follow up on is Nate McFeters, John Heasman, and Rob Carter’s talk which discussed the GIFAR attack I’ve been hearing so much about lately. The gist is that you can create a file that is both a valid GIF and a valid JAR, then use some Java applet tricks to initiate HTTP requests on behalf of the victim.

Finally, the Pwnie Awards didn’t fail to disappoint. Drama ensued over the Most Overhyped award, but at least this year some of the winners showed up to claim their awards! Halvar rapping Symantec lyrics was also quite memorable.

All in all, a fun and informative week, but as usual, I was relieved to get the hell out of Vegas and head home on Friday morning.

P.S. For a much more entertaining BlackHat/Defcon Recap, read Jennifer Jabbusch’s account of the week’s events. It’s my favorite one so far!

My favorite talk, as expected, was the Sotirov/Dowd talk on How To Impress Girls With Browser Memory Protection Bypasses. The attack is a conceptually simple, yet completely reliable technique for exploiting vulnerabilities in web browsers. Of course, the media has sensationalized the impact of their findings, but ultimately, this is still significant as far as browser-based exploits are concerned (here is a more accurate report). It’s worth mentioning that part of the technique allowing them to load a .NET DLL at an arbitrary location under Vista was reliant on an implementation bug wherein the OS disables ASLR if the version in the .NET COR header was below a certain value. However, the address space spraying and stack spraying techniques are likely to be extended to other platforms utilizing similar memory protection mechanisms.

As for the girls? I can report first-hand that the ladies at TAO on Wednesday night were hanging on Alex’s every word. They were particularly impressed when he whipped out the laptop for a live demo. Unfortunately, none of the dozen iPhone owners in the immediate vicinity thought to snap a picture (too busy Twittering). Oh well.

I also enjoyed Hovav Shacham’s talk on return-oriented programming. Simply put, he described a generalization of the return-to-libc shellcode approach with the intent to demonstrate that one could achieve Turing-complete computation using “found code” in process images. By chaining together series of mini-computations ending in return (RET) instructions, it was possible to build higher-level programming constructs such as branches and loops. The nature of the x86 instruction set provides some flexibility because instructions are interpreted differently depending on how you align the instruction pointer (i.e. the old shellcode trick of searching the process image for any JMP EBX instruction and using that as your EIP). In RISC architectures such as SPARC, however, you don’t have that luxury; if your %pc isn’t aligned properly you get a bus error. So it was quite interesting to see that they were able to extend the concept to RISC. The practicality of the attack technique is limited by the fact that the shellcode is tuned to a particular binary image — if the shellcode was built using instructions extrapolated from glibc 2.3.5, it won’t work for a system running glibc 2.4.

I thought Scott Stender’s talk on Concurrency Attacks in Web Applications was interesting as well. In a nutshell, spewing thousands of simultaneous requests at web application transactions that are not thread-safe can create interesting problems. In the presentation, Scott ran his demo against a VM running on the attack machine. I found myself wondering how effective the same attack would be over the Internet — would it be significantly less reliable (or not at all)? Race conditions are generally easier to exploit locally than remotely due to more predictable execution conditions. Certainly this is an under-tested vulnerability class though.

One presentation I wasn’t able to attend but want to follow up on is Nate McFeters, John Heasman, and Rob Carter’s talk which discussed the GIFAR attack I’ve been hearing so much about lately. The gist is that you can create a file that is both a valid GIF and a valid JAR, then use some Java applet tricks to initiate HTTP requests on behalf of the victim.

Finally, the Pwnie Awards didn’t fail to disappoint. Drama ensued over the Most Overhyped award, but at least this year some of the winners showed up to claim their awards! Halvar rapping Symantec lyrics was also quite memorable.

All in all, a fun and informative week, but as usual, I was relieved to get the hell out of Vegas and head home on Friday morning.

P.S. For a much more entertaining BlackHat/Defcon Recap, read Jennifer Jabbusch’s account of the week’s events. It’s my favorite one so far!

Sorry for the lack of content yesterday. Due to a PBCAK failure to pay attention I neglected to publish write yesterday’s article. So, they’ll trickle out over the next couple days I’ll try to do better while Dave takes some time off to work on a personal project. Thanks to all of our new subscribers that joined us yesterday. Welcome!

Click here to subscribe to Liquidmatrix Security Digest!

And now, the news…

1. The Science behind 3-1-1 Mental Note - When flying this weekend, do not play the part of a vain astronaut.
2. DeCSS is now illegal in Finland Quick - jam the inflatable boat back into the travel pouch — Hurry!
3. Microsoft Whitepaper: Comparing Features - Windows XP SP3 and Vista SP1 smell the slow burn of a sweaty Ballmer
4. CFP (Computers Freedom and Privacy) Conference Roundup from Wired’s 27B/6 MmmmMmmmm… Cyberdyne me baby
5. RIM will not give Blackberry Keys to India Ahhh yes, but to which national governments (besides the Mennonites) have the boyz in Waterloo given the keys?
6. Elevator disables UAC on a per-application basis Do you want to Allow or Cancel?
7. Nottingham University Student Detained DWB (Downloading While Brown) from the US Gov’t - Go Directly to Secret Detention
8. President Bush Signs Landmark Genetic Nondiscrimination Information Act Into Law Gattaca… Gattaca… Gattaca…

More as I process it all (seriously, where the hell does Dave find the time for this every.single.day?)

Tags: News, Daily Links, Security Blog, Information Security, Security News

My choice of words seems to raise a few eyebrows with my audience. You, like several others, may ask- “That seems like an ‘untechnical’ term, shouldn’t you say it ‘disables’ the port?” 

Well, no, we shouldn’t say that. When we talk about ‘enable’ and ‘disable’ for ports, that’s actually a port property designation within the switch. When we disable a port in the switch, we’re turning it off and preventing it from passing any traffic.

When we have an 802.1X-enabled port that’s unauthenticated, it still has to pass SOME traffic types, such as EAP (and possibly discovery protocols, such as Cisco’s CDP). Otherwise, we’d never be able to authenticate, right?

So, I, like many others in the NAC world, usually refer to an unauthenticated 1X port as being ‘shut off’ or ‘closed’ just as a means to distinguish it from ‘disabled’ which does have its own meaning.

# # #

Well, it turns out that Windows will override this setting if you insert a USB drive that your computer has already seen. I received an email from Susan Bradley that links to an article on Nick Brown's blog, "Memory sitck worms." Nick mentions the MountPoints2 registry key, which keeps track of all USB drives your computer has ever seen. I'll admit, I didn't know this existed! I'm glad Nick wrote about it, though.

Nick also includes a little hack that effectively disables all files named "autorun.inf." Interesting, but something in me prefers to make Windows just plain forget about all the drives it's seen. So now I will amend my instructions. In addition to what I wrote earlier, you should also write a small script, and execute it through group policy, that deletes the following key:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

When I searched for it in my registry, I also found a few others, so maybe you'd want something that would search through the registry and delete them all, although I don't know if such a tool exists -- I've never had a need to look for something like that.

That’s right, it’s your data. Any of the other elements could easily be replaced. But if your data vanishes, well then, you might as well close up shop and take residence on some forsaken island in the middle of the ocean. It’s your data that gives you your competitive edge, your data that constitutes a large part of your business, and your data that is most attractive to attackers.

Why, then, is there still so much emphasis on protecting all the plumbing that moves the data around, but little interest in protecting the data itself? My guess: old habits die hard. For most of the history of information security, emphasis on security has roughly followed this model:

Historical approaches to security have placed most emphasis on the network, with decreasing consideration of individual computers and the applications they run, and the least amount of consideration for the security of the data. (I’ve purposefully placed the physical layer outside the triangle, partly as a joke and partly for real—when I visit data centers I routinely discover physical security problems!) Once upon a time, this was the correct approach: computers and applications weren’t designed with much regard for security, and the only way to protect the data was to protect the network. And indeed, because it was generally the network that the bad guys were after, this approach worked.

The old model is no longer appropriate today. The bad guys really don’t care about your network anymore: they’re going after your data. Attackers were once motivated by pride: Mafiaboy was notorious for bragging about bringing down large parts of the Internet in February 2000 (and his bragging became his undoing). But these days, attackers are motivated by profit: they’re out to make money. The economics of the game have changed, and along with that so have the bad guys’ skills and the capabilities of their tools. Let me repeat: they want your data. They’ll steal it and sell it to your competitors, they’ll damage it and put you out of business. The network and your computers exist only as a means to get to your data. So we, as defenders of information assets, must change our tactics to react to—and possibly get in front of—the tactics of the bad guys. We’ve got to invert the traditional thinking and now emphasize security by following this new model:

Because protecting your data is now paramount, data protection deserves the bulk of your attention. Application security—developing applications with a mind toward security and how they might be purposefully abused by an attacker—is similarly critical. Good host security will remain important in this world as well, especially the security of mobile computers of all kinds. Because people use computers to run applications that process data, it’s these layers that are crucial. If you apply this model, the network can return to doing its only true job: moving bits around as fast as possible.

Traveling to the new world

So how do you get from there to here? One word: cool technology (OK, two words).

Full drive encryption

For some time, I’ve been advocating that using host-based firewalls isn’t an option: it’s required. Ordinarily, you have no control over the traffic that appears at your Ethernet port. A host firewall gives you control. I now have a second requirement: full drive encryption, especially on portable computers. According to the 2006 Australian Computer Crime and Security Survey, for four years in a row, laptop theft is the most expensive attack weathered by the organizations who responded. The exposure (and expense) isn’t the hardware—it’s the data stored on the computers. This tells me that good-quality full drive encryption is probably one of the best investments you can make to help save your company money! So go ahead and upgrade those laptops to Windows Vista (Enterprise or Ultimate editions) right now, to take advantage of BitLocker full volume encryption, because the cost of the upgrade is most certainly less than the cost of losing your data (and your reputation).

Learn more about BitLocker: http://technet2.microsoft.com/WindowsVista/en/library/ba1a3800-ce29-4f09-89ef-65bce923cdb51033.mspx

Document protection

When Alice creates a file and wants to give Bob read/write access, give Phil read access, and deny everyone else, the traditional approach involves a lot of work on the part of someone else. Alice has to beg, cajole, and bribe the network admin to create a file share, create two security groups, add Bob to one and Phil to the other, and create access control entries on the share’s access control list. That’s a lot of work for someone who really doesn’t care about Alice’s problems. And it’s incomplete: sure, Eve can’t touch the file on the share, but she can certainly convince Phil to give her a copy—read access also permits copying. If Phil were particularly malicious, he could modify his copy of the document first. You see, network-based access control works only so long as the protected object remains within the network. As soon as someone opens the file, the local copy in the computer’s memory obeys no restrictions.

Windows Rights Management Services (RMS) and Microsoft Office Information Rights Management (IRM) give you an alternate form of access control that persists on the documents themselves regardless of where they live. When Alice assigns read/write access to Bob and read-only access to Phil, she doesn’t need to involve the network admin at all. The access she assigns is stored right in the document and enforced by IRM. When Bob opens the document, Word first checks Bob’s permissions and then disables functionality so that Bob can’t do anything more than what he’s allowed. In Bob’s case, Word will refuse to do anything other than display the content in the window.

In addition to enforcing policy through IRM, RMS protects documents by encrypting them. RMS-protected documents remain encrypted in storage and in transit. They’re decrypted only after an authorized user has been authenticated and his or her permissions have been enforced. If someone outside the RMS’s domain attempts to open a file, it’ll just appear as nonsense. Unless your computer is enrolled in RMS and you’re on the list of authorized users, this document is useless to you. It’s also useless to the friends you’ve given copies to on those ubiquitous USB drives littering the basement of your desk.

Learn more about Rights Management Services: http://www.microsoft.com/rms

Data security

One definition of news is “something that happens rarely.” Data breaches must no longer be news, then, because they seem to happen with increasing regularity. The best way to avoid a breach is not to store data you don’t need—after you process that credit card number, delete it, don’t retain it. Other sensitive data you do need to retain in some database as part of your business. The best way to keep this data secure is to encrypt it in the database. Microsoft SQL Server 2005 includes some great features to help you here—field-level encryption of data in storage, encryption of data in transit, and enterprise-level key management. An important project that you should soon consider is to evaluate all instances where your company is storing private or confidential information (especially about your customers) and add data encryption where appropriate.

Learn more about SQL Server encryption: http://download.microsoft.com/download/4/7/a/47a548b9-249e-484c-abd7-29f31282b04d/SQLEncryption.doc

Of course, there’s more to data security than just the physical storage. Equally important are policies and processes for classifying data. There’s an entire body of knowledge—too much to absorb, really—on this topic. Rather than send you off on some endless forage through your favorite search engine, I’ll share with you a classification scheme I discovered recently. It’s simple and elegant—which means it’s something you can actually use.

First, think about confidentiality classifications. These are important because they help guide your response in case of a breach. Four classifications should be sufficient: public, internal, confidential, and private.

Next, consider retention classifications. If you should ever be hauled into court for some reason, the discovery process will uncover a whole lot of your data. You could face major penalties if new information is discovered after a trial starts. Therefore, it’s necessary to follow a policy that routinely purges e-mails and file shares after a period of time. These three retention classifications are good enough for most cases: regulated data for seven years, historical business data for three years, and temporary data (like e-mail) for one year.

Finally, consider recovery classifications. How quickly, in the event of a disaster, will you need to recover certain kinds of data? Are employees allowed to store mission-critical information on home computers or portable devices? Here’s a sample recovery classification: for mission-critical data, immediate recovery; for urgent data, recovery within 72 hours; for non-urgent data, recovery within 30 days.

Security for the modern age

Attackers constantly improve their tactics as their motives become more sinister. By adjusting your tactics as well, you can be certain that you’re doing your part to keep your information secure.