Cooking With Technology

I haven’t used antivirus for near five years now, and yes, even on my Windows hosts. According to the popular opinion of the Internet, my Windows machines should now be zombies supporting the botnet efforts of Russian organized crime - but they aren’t. The reason for this is, and I am going to make a bold statement here, is I am just as secure without antivirus software as I would be with it. Now that you all know where I’m heading, I’ll explain why it is true for me, and why it is probably true for you too.

The secret lies in the reasons people would have you believe you need antivirus software. Obviously the reason is to prevent and clean infections, but the effectiveness of these tasks is dependent on the signatures created for the software. To give a rough outline, the process goes like this:

1. Virus is coded and released
2. Antivirus labs obtain a sample of the virus
3. Labs reverse engineer and create signature for the virus
4. Signatures are downloaded by your AV software to be able to detect and clean the virus

Ignoring heuristic scanning for a second, note that between events one and four you are vulnerable to the virus that was released. The amount of time it takes for AV labs to release a signature for a virus varies, but in that time you are unprotected from it. That means that your signature based virus detection and cleaning system is effective only for attacks that have been around for a bit.

With heuristic scanning, there is a chance that it will pick up new viruses that don’t yet have signatures. This is fairly effective for trivial viruses that repeat methods used by other viruses, but poses no resistance to viruses using new techniques, engines for encrypting malicious code, or polymorphic engines. Unfortunately for Joe Public, the damaging viruses are the advanced ones - heuristic scanning is only going to prevent you from doing something really silly (like opening that screen saver someone sent you in an e-mail).

Viruses aren’t even that dangerous. I’m sure I’ll catch some flak for this statement, but they are generally contracted by user ignorance or idiocy. Viruses by definition require user interaction to propagate, which means that if you are infected with a virus, it is because you did something to contract it. Worms are a different story, they can infect you without your participating in the event. However, antivirus is completely ineffective in blocking the initial wave of worm infections (even with heuristic scanning) anyway, which is the same time you are most likely to come in contact with the worm. If you don’t do anything to contract viruses, you don’t have to worry about them.

So say I am a discerning user who doesn’t open shifty attachments or download warez executables (ie, I in general know what I am interacting with) - what is my risk of contracting a virus with antivirus? Slim to nil. And without antivirus? Slim to nil, because I don’t open the attack vector required to be infected by viruses. And say I contract a virus using a new attack vector that catches me off guard because it uses some new technique - what is my risk now? Antivirus wouldn’t catch it even using heuristic scanning because it is using new techniques, so it doesn’t matter whether it is installed or not. My risk hasn’t increased because my machine lacks antivirus software.

This plays out practically, too. In my five years of not running antivirus software on a Windows box that I keep patched and behind a router with NAT (which is the new default setup for many families), I have not contracted a single virus nor been hit by a single worm. This isn’t something I’m bragging about - it is just a fact that defies the common notion that antivirus is a necessity, especially on Windows boxes.

If you don’t keep your machine patched, your company policy requires it, or you are gullible, you should probably have antivirus software - your risk will decrease by having it there. If you are security conscious, aware, and scrupulous, you can save your system resources and some money by ditching your antivirus software - you are no more secure with it than you would be without it.

I had a friend share a blog post of a story that has been all over the Internet lately regarding Microsoft having a government backdoor in Windows. The story shared is located here, but I’m sure drudging around tech news sites run by 14 year olds or ignorant IT professionals will expose you to similar content.

Full disclosure: I’ve been using Linux for over five years regularly, and am typing this post from my laptop running Debian Linux to my server running Debian Linux, but I do use Windows on my desktop. Hopefully that sentence will cut down on comments accusing me of fanboyism, because I’m going to stick up for Microsoft here.

Actually, I don’t need to stick up for them - because the ‘backdoor’ doesn’t exist as far as anyone knows. I can’t pretend to know whether one exists (a huge reason why open source is better in cases like this), but in this instance the authors of titles are just being media whores and trying to amplify the situation for traffic. The reasons why this is true are straightforward, and numbered for your pleasure:

1. The component in question is not a part of Windows by default.

The program the article’s author is claiming has a backdoor is the Malicious Software Removal Tool, which does not ship by default with any version of Windows. Yeah, it is a component produced by Microsoft, but even if there was a backdoor in it, it isn’t a backdoor in Windows.

2. It isn’t a backdoor.

Backdoors allow an outsider unauthorized access into a system. As the article reports, the Malicious Software Removal Tool may report the IP address of the machine through the tool to a central location. Reporting an IP is nowhere near the same class as a backdoor. While I won’t argue that doing this against the user’s will is a breach of privacy, people seem to be in love with escalating issues, and it is as stupid as it is unfounded.

3. Everything is speculation.

Find a fact worth the attention these stories are getting. Everything is based on interpretation of events, and the discussion following those interpretations are once again removed before “facts” are arrived at. Sensationalist writing has always annoyed me, and that people take it seriously even more so.

So there you have it. The fabled Microsoft Windows government backdoor is a manifestation produced by someone who fails both at basic computer security and journalism. Just as the title of this post states: the Microsoft Windows government backdoor… isn’t.

As is plastered all over the Internet, Ubuntu 8.04 Hardy Heron was recently released for the public to feast upon. I really don’t care about the release itself, but I *do* care about Mark Shuttleworth’s blog post regarding the release. Specifically:

We all owe a great deal to the team who make Debian’s “unstable” repository possible, and of course to the upstream projects from GNOME and KDE through to the Linux kernel.

Read the rest of it here.

I think Mark’s statement shows maturity in the Ubuntu project, and I respect him for showing the open source community some love.

I’m not affiliated with the Debian project in any official capacity (yet!), but I’m happy they are getting the credit they deserve. Kudos to the Debian team and every package maintainer - you don’t hear it enough, but there is a large percentage of the technically aware population that appreciates the work you do beyond measure.

Barcamp Rochester 3 was Saturday, and it turned out to be an *amazing* event. The idea behind Barcamp is that it is an informal conference where there are no spectators, only participants. This means that everyone who attends gives a talk on something, ranging from programming languages to intellectual property to enacting political change through technology.

The talks ran from 10:00am to 10:00pm in three separate rooms, and given that multiple talks were going on at the same time it was impossible to see everything. I did attend Google employee Jordan Sissel’s “cool stuff I’ve worked on” presentation, jquery creator John Resig’s jquery presentation, frequency ninja Andrew Potter’s wireless and spectrum lecture, and a round-table discussion on politics. Needless to say, it was a very full day.

I personally gave an hour lecture on the same material as my most recent Society of Lectors lecture, covering hacking through exploitation and shellcode. The turnout for my talk was great, and for anyone who attended that is now reading this, thanks for being part of such a great audience! I really enjoy giving this lecture - I get excited about the topic, and it is great to see other people getting excited about it too. The questions at the end are always my favorite part, and given more time, I could have talked forever about some of the topics that were brought up because of them.

The biggest event of the day for me was a talk on how we can use technology to inform people, with a special focus on the US political system. It started as a round table discussion led by Remy D of the NYPIRG and James Turk of the Sunlight Foundation labs, with Dave, Heewa, and myself attending. It moved from ideas to implementable actions, and while I entered the discussion skeptic, I left with the feeling that it is possible for individuals to make a difference in a system that is much larger than themselves. I hope to engage in future work that will spread the same kind of hope to other individuals, because the opportunity exists to shake the popular apathy for our communities - and knowing it is somehow comforting.

On top of everything else, I’m helping Dave and Heewa with the One Laptop Per Child program at RIT. The organization is sound, and their ideas are worth pushing forward. I’m particularly interested in the mesh networking capabilities of the XO laptop, and my contributions will most likely be related to software that takes advantage of it. The reason I’m bringing this up in a post on Barcamp is because Dave and Heewa gave a couple talks on the initiative and their plans for it at RIT, and having finally obtained an XO laptop, I got to play with it! John Resig also had one, so we messed around with chat and video feeds. It was pretty cool, even though the size of the XO makes it kind of difficult to work with.

The event overall is just something you have to experience. There is nothing quite like a gathering of a bunch of smart people talking about what interests them. With few exceptions, everyone is really friendly and down to earth, which makes it really easy to just focus on the goal of the day: to share ideas, meet new people, and leave just a bit better than you were when you came.

Here’s looking forward to Barcamp Rochester 4!

I got hit with a weird bug when I upgraded to VMWare 6.0.3. Before, my Debian Linux guest could happily browse the Internet with a NAT interface. After, I could resolve both internal and external IP addresses, but could not resolve any domain names using DNS.

I can only guess at why, but I believe the problem was not the configuration of my guest, but rather that the problem lays in how VMWare deals with the DNS queries. I use DHCP to obtain an address from the built-in DHCP server, and I was being assigned a DNS server along with my IP (as verified by checking /etc/resolv.conf), but it wouldn’t resolve any names for me.

My solution for now is to step around the assigned DNS address given by the DHCP server, and choose another one instead. I opted to use OpenDNS’s servers, and configuring Debian to use them is trivial - just open /etc/resolv.conf as root with your favorite editor, and change the ‘nameserver’ line to use OpenDNS’s DNS servers. Mine looks like this:

domain localdomain
search localdomain
nameserver 208.67.222.222

Restarting the network isn’t even necessary, the next named request you make should be resolved successfully and everything should be peachy!

If you want to make the change more permanent, you can assign a static IP and a static nameserver to the active interface of your guest operating system (hint, /etc/network/interfaces), which will circumvent the DHCP server. If you want to keep using the DHCP server, you’ll have to change the nameserver line every time you request a new address.

Hope this helps someone else!

Yesterday I gave the second lecture in my “hacking” series. We’ve progressed beyond general descriptions and terminology and moved into the technical aspects of the stack, vulnerable code, and crafting exploits. The lecture ran about 45 minutes, and was accompanied by a live demonstration of exploiting vulnerable code.

For those that came late or missed it, the slides are available here (pdf format), although once again the real content was in the accompanying talk.

The demonstration used three source files. The shellcode was written by BreeZe of binbash.org, while the other two are my own. They are:

• The vulnerable sample program
• The shellcode
• The exploit code

Running the Exploit

First, I only tested the exploit running on Debian Linux, running a 2.6.23 kernel on a 32bit x86 machine. It probably won’t work on Windows or a Mac, and it definitely won’t run on your SPARC.

Second, I used version 3.3 of gcc’s compiler. Newer versions contain checks to make stack smashing harder, but 3.3 is free of any of these security features. You’ll have to use it when compiling these, which can be done by issuing gcc-3.3 -o <name> <name.c>, like:
gcc-3.3 -o exploit exploit.c

Third, Linux kernels after 2.6.12 do virtual address space randomization, which will prevent the exploit from running successfully after being compiled. To disable this, issue (as root):
sysctl -w kernel.randomize_va_space = 0

Fourth and finally, if you want to trigger a core dump in the vuln program, you have to lift any restrictions on dumping core files. Something like the following should work:
ulimit -c 100000

Note that the shellcode file is superfluous, I only included it as an example and guide.

Next Time

At this point, I’m not sure what I’ll be covering next week. There is a lot I could do - writing shellcode, showcase more advanced shellcode, demonstrate gaining a remote shell (remote exploitation is a whole other beast), secure coding, polymorphic and self-modifying shellcode… there are a lot of topics, and only one lecture left before the end of the series.

Regardless, it will be fun, and we’ll all learn a hell of a lot.

I’ll be at Barcamp Rochester 3 this Saturday in GCCIS, and more likely than not I’ll be talking about anything and everything computer security. If you have any questions anything or find something I’ve said interesting, hit me up! I’m friendly, and always up for talking about computer security :)

When targeting an individual host, the first step most attackers take is to scan and probe the system in order to gather information about it. Most generally this means scanning the system with nmap, determining open ports to find what the machine is serving, identifying the version of each service available, and then attacking the vulnerable ones.

The game changes when the attacks are automated, such as when they originate from a worm. Worms rely on only a select number of attack vectors, and without being artificially intelligent, are not capable of identifying and attacking new vulnerabilities. This means that when a worm scans, it is probing machines to determine whether they susceptible to a specific set of attacks.

But scanning is hard. It is slow. With the 2^32 addresses that exist within the IPV4 space alone, scanning with only one host can take an incredible amount of time. IPV6 is even worse. With a 64 bit address space and thus 2^64 addresses, the conventional means of scanning are extremely inefficient - a fact the IETF is well aware of. So now attackers and worm writers are faced with a new problem: how can we make this process faster?

I have an idea for a solution, and a proof-of-concept in the works to demonstrate it. Why not use IANA themselves to help? My solution involves not increasing the speed of the actual scanning, but by increasing the intelligence with which hosts are chosen to be scanned. The allocated IP blocks are published by IANA and made publicly available. Take a look at it: 41 /8 blocks are unallocated and 36 are reserved, dropping our problem space down by 77 /8 blocks. If the scanner was particularly stupid and was previously scanning the full range of IPs, this would result in 1,296,908,325 less addresses to scan, increasing our theoretical speed for a complete scan by 30%. When you are talking performance in computer science, a 30% speed increase is a big deal, and to a worm author, that relates directly to faster propagation.

The improvements are even more drastic for IPV6. Blocks of IPs cost money, so they won’t be snatched up immediately. Scanning only the allocated blocks of IPs means that the 64 bit problem space becomes less ominous. If we consider that the transition to IPV6 will occur when most addresses in the IPV4 space are used, then intelligently scanning only those addresses results in a 1.84×10^19 reduction in hosts to scan.

The long and short of it is that scanning isn’t likely to get much faster, but intelligently choosing what is scanned can produce real results that only lose effectiveness as the number of actual hosts increases. I’ll post a POC in some time that will showcase this methodology, so keep your eyes locked ;)

On Tuesday I gave the first of a series of lectures following the “hacking” track. I’m staying far, far away from an IT perspective - I’m not teaching nmap or how to use wireshark, nor am I discussing web vulnerabilities. No - I strive for a higher path, focusing the audience on dodging the skiddie [1] bullet and pointing them toward the real stuff. The talk went well, the audience was very engaged, asked great questions, and had good ideas when I asked for them. 98% of the content was in the talk, but as promised, the slides are now available for your viewing pleasure.

View the presentation here (Google docs, no download necessary).

There are varying requests for where to go next in the series. I had originally planned on gradually introducing more complex topics over a set of three lectures, hence the very general nature of the first. However, the group that came seems more interested in jumping directly to application, requesting a live demo of an exploit and accompanied explanation. When this idea was first presented I was a little hesitant - I was hoping to give people the knowledge necessary to be a jumping point, this is a little more direct. While it will take a lot more preparation, I think I’m going to end up using a demonstration to fuel my next lecture, conflating theory and practice.

A couple questions were asked that I think deserve more attention than I could give them on Tuesday:

Q: Are people who use Gentoo and compile everything more secure than someone who uses prepackaged binaries?

A: Absolutely not. The argument provided in conjunction with the question was that some compiler flags may change the layout of the program in memory, thus making new exploits developed for common versions of programs ineffective against the customized versions. Yes, there are a number of cases where this may be true, but that number is likely negligible. Compilers modify logic, unroll loops, and handle other things that have to do with instructions - rarely do they modify data, which is what we care about in the track we are following. Because the stack isn’t modified so heavily that the vulnerable components are removed, a bigger NOP [2] sled is often all that is required to have the same exploit work on your optimized code.

There are exceptions to this, but not in optimization flags. Introducing canaries is an option that is available to use when compiling with certain versions of GCC [3]. Canaries are simply two modifications: the first is introducing a random integer to a variable that gets placed between the rest of the stack frame’s variables and return address, and the second is a simple conditional that checks the value of that number. If the number is overwritten by whatever data we used in overwriting the return address of the stack frame, the conditional check will fail, and the program will exit with an error indicating a failed canary check (usually a reason for an admin to show concern). This is the only current compiler flag option I know of that will stop non-specialized exploits from delivering their payloads to your box.

More important however is the need to address the question’s ignorance. The short and correct answer to the question is “no, in fact you are less secure.” Feeling invulnerable is the most dangerous thing you can do for the security of your systems. It doesn’t matter how your binaries are obtained and compiled - if a vulnerability exists for the version of the program you are using, you are vulnerable. Your intermediate steps may have bought you time, but feeling safe causes complacency, and the second you feel complacent is the same second the security of your system is philosophically compromised.

Q: Isn’t it true that operating systems are running most programs in ring0?

A: No; in fact, the opposite is true. The full question was posed using language and concepts that hadn’t been introduced yet, so for those that were just being introduced to the field it was a bit foreign. Ring0 and Ring1 respectively refer to kernel and user space, which are concepts in operating system design that separate the operating system’s running components from programs the user runs. Without a separation, a user would have the ability to modify the kernel’s components which is a Bad Thing ™.

From the definition above, it should be obvious why the answer to the question is no. It is true that all programs make calls to kernel space functions exposed through an operating system’s API, but at no point does the user’s program enter the kernel itself to execute code. This was not always the case, but it has been for the last several years, and the separation only grows more defined with each new generation of operating systems. Note that there are ways to get code running in kernel space through drivers or kernel hooking (check out rootkits if this line of research interests you), but it requires some trickery and administrative access on the machine - no normal program does it.

And with that, I’ll close. The next couple days will be spent in part preparing the next lecture in the series, where we’ll see a demonstration, some actual shellcode, and a dive into further understanding memory and the mindset of the innovative hackers that develop these techniques.

[1] Script kiddie, a wanna-be hacker that uses the tools and work of others without producing anything of their own.

[2] No operation. Just burns a CPU cycle and increments EIP, the pointer that tells the processor which instruction to execute next.

[3] The GNU C compiler.

More updates for the Society of Lectors!

The next group of lectures is occurring tomorrow, Tuesday March 24th, 2008 in the first floor auditorium (room 1400) of GCCIS (building 70) at RIT. We are meeting at 8:00PM, and this new day and time has been settled on for the near future.

The reason I’m especially excited about tomorrow is that I am lecturing! I’ve been given the go-ahead to give a series of lectures on shellcode, a fairly heady computer security topic that is never taught in classes. Part one of the series is a very general, non-technical overview and topic introduction that is accessible to those of all backgrounds. After building a solid base of understanding, we’ll really dive into things with later lectures. Afterward, I’ll post the slides here and to the Society of Lectors group, as well as publish a corollary technical component for those that didn’t have their appetites whetted by the presentation. My blurb:

Computer hackers continue to be the bane of the networked computer - but have you ever wondered exactly how they strike? In part one of this series, we will dive into a very accessible view of how they gain control of computers they do not possess.

Heewa Barfchin is also presenting on neural networks from biological and computer model perspectives. Tomorrow should be great!

The Society of Lectors is a new group at RIT with the goal of enriching participants through lecture and discussion. Founded as an idea by Heewa Barfchin and further realized with help from David Brenner, the group promises to deliver an education beyond what can be taught in the classroom.

The first lectures will be this Wednesday, March 19th, in one of the labs on floor three of GCCIS (building 70) at RIT. It is open to all people from all backgrounds, as a diverse group of people only stands to enrich the experience for everyone. Heewa and Dave will be the featured lecturers, with things kicking off at 8:00pm.

The full details are in this post. I’m personally looking forward to it, and encourage everyone in the area to come check it out!