graduated script kiddie

Myths of Security

2010-01-13T14:04:00.000-08:00

I recently got myself a copy of Myths of Security written by John Viega, and am honestly impressed; so much so that I decided to blog about it. Not that I expected unimpressive work from John, I am just usually unhappy with books unless they break out they assembly and topsy krett 0dayz; although this book isn't super technical, it is definitely awesome. With short, entertaining chapters, John takes a head on approach to addressing the bullshit in the security industry (win!!!) by discussing it with language that is technical enough to be enjoyable by geeks, but non-technical enough to be understood by the masses. This is really a shining point of the book: by speaking to both audiences, he bridges and explains the frustrations from both sides in understandable terms. You can seriously recommend this book to your parents to help them understand why you have screaming fits whenever the local news mentions anything about hacking; he holds no punches calling out any part of the security industry, and the end-users it sells to. He calls out AV, HIPS, HTTPS, and even Apple fan boys (win+1!). After exposing all the snake oil, he then follows through with some sincere, candid suggestions that truly aim to secure users. Overall an awesome book.

I WON TEH PWNIE!

2009-08-10T11:34:00.000-07:00

I WON THE PWNIE FOR BEST SONG @ BLACKHAT 2009!! WOOT!

I am very grateful! Thanks to my supporters, my friends, my fans and the Pwnie judges! I received a lot of positive feed back for the track throughout Blackhat and Defcon - I will be trying my very best to get some sort of recording setup out here to make more music.

Nice Report

2009-07-22T06:45:00.000-07:00

I am nominated for the Pwnie Awards again this year for my song Nice Report. I'm really excited and hope I win, although not having a video to submit seems pretty detrimental after last years winner :(

time(), GCC, and the linker

2009-07-10T19:24:00.000-07:00

While debugging some of my own crappy code I discovered a bug that I thought was interesting. If Kenshoto were to have hosted the game again this year, I think this may have been a fun bug to stage in a vulnerable CTF service. (Actually, I vaguely remember talking to someone who did this years quals who said that there were some "cute bugs that involved clever timing" -- it is very possible it was of the same nature.)

Long story short: if there is an implicit declaration of a function because a header file wasn't included, GCC will warn about the implicit use but allow it. Without the header, GCC doesn't know the expected arguments or return value of the function (logically, it has no prototypes to reference). If the linker can find the function being used, it is linked to during that step.

Consider this contrived and barely functional code sample:

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <stdlib.h>

void (*fp)(void);

void handle_error(void)
{
    printf("you're doing it wrong\n");
}

void handle200(void)
{
    printf("you're still not doing it right\n");
}

void setvalue(int x)
{
    if (x == 200)
    {
        fp = handle200;    
    }
    else
    {
        fp = handle_error;
    }
}


int main(int argc, char *argv[])
{
    time_t mytime;
    int x;
    size_t bufsize = 65 * 1024;
    char *buf;

    buf = malloc(bufsize);
    
    memset(buf, 0, sizeof(buf));
    fgets(buf, bufsize-1, stdin);
    x = atoi(buf);
    setvalue(x);
    mytime = time();
    printf("my time is %u\n", mytime);
    fp();
    free(buf);
    return 0;
}

There is no inclusion of time.h as required for the time function, but the code compiles and executes. If GCC is issuing warnings, during compilation it will say timebug.c:44: warning: implicit declaration of function ‘time’.

I was an idiot for not having warnings enabled while compiling the code I was working on, it would have saved me tons of time (u see wat i did there?)

The prototype for time() is:

time_t time(time_t *t);

And the action taken by time() is as follows:

Get the time from the system.

If the time_t pointer supplied as the only argument is not NULL,
dereference it and store the time there.

Return the time.

In the code sample, since the last value pushed to the stack is the value passed to setvalue(), and as it still resides on the stack when time() is called, it is taken as the argument to time(). If the atoi() call on the buffer returns anything that is not 0 (aka NULL), then time() will treat it as a valid pointer, dereference and write the time to it. This wreaked havoc on my code as in my case, the last value to the stack was a structure pointer full of linked lists and things, and the bug didn't trigger until free() happened on those lists. Serious pain.

Clever uses of this could be done to stage a fun CTF service. If an attacker had this vulnerable app to work with and a means of manipulating time (like a MITM of the Network Time Protocol), they could have a fun instant write-4-anywhere. Additionally, every 4.2 minutes the lower 8 bits of time rotates. Every 18.2 hours, the lower 16 bits rotates. By properly offsetting (say, only overwrite the high 16 bits of a function pointer/EIP) in conjunction with heap massaging or exploiting other application-specific traits, this bug could be fun ;]

MOAR POSTS

2009-07-05T12:51:00.000-07:00

So I caved in and joined Twitter with all the other techno-hipsters. Apparently the security industry has a hard-on for a broken down over simplified version of web text irc. Yet still, it is a fun and efficient way to keep in immediate touch with friends and other interesting people. With my time being occupied by getting prepared to move, and tweeting, I haven't spent any time posting blog updates. I promise something interesting soon.

For now, I'll just leave this here:

This is what we needed.

2009-04-01T18:55:00.001-07:00

My buddy Jeff said it best - this is what we needed: I TOLD YOU SO.

Why does the media hype things like Conficker into terms such as "an unthinkable disaster". How is it unthinkable? Is Conficker going to leverage the technology of its compromised machines to transcend reality and do something beyond the scope of human comprehension? Is it going to build Skynet and go back in time looking for Sarah Conner? Is it going to use PC speakers to generate vibrations that manifest doom spores in the air that infect us and turn us into zombies?

Sure it could fuck things up. It could delete everything on the infected machines. It could steal information. It could probably wreak DoS havoc in the internet. What's so special about this beyond any other worm of mass propagation? Nothing. It has some semi-clever components, it isn't as absolutely stupid as other worms, and it has an obsession with Rivest's aglorithms. OoOOoOo It must be the end of the world.

So to everyone out there: I told you so. We're still alive. Congratulations on reliving y2k over a worm. Again don't get me wrong: it could cause a bunch of stress and rain on some parades. In fact it might still do something after April 1st. Is it worthy of the hype? Is it an unthinkable disaster? Certainly not.

No Moar Free Hugz

2009-03-26T03:19:00.000-07:00

This last week at information security conference CraqPipeWest, security researchers Dr.Raid, Postmodern, CD and Pierce have all decided to make and live by the following mantra:

"NO MOAR FREE HUGZ"

This statement follows the annual conference's competition called Struggle2Snuggle, where in hackers compete to try and get as physically close as possible to girls who also attend the conferences. The contest works in 30 minute rounds, and at the end of each round the hacker who achieves the highest public display of physical interaction with a consenting female wins $50 cash for the round in addition to a free stick of AXE deodorant. The researchers were later quoted in interviews, after being asked about their views regarding the monetary value of hugs:

"No moar free hugz to me really means that these girls can't just expect to get a hug from me for free. I mean I spend time weaponizing my hugs - and I don't even really know what that means when I say it - but it sounds cool. This isn't something I do to make other people money, so they shouldn't be making money off of me. If we're going to be spending time hugging these beautiful women, they should be paying us" - Dr. Raid, Chief of Substance Abuse at Portland based SophSec Research Labs

"It's time that we recognize the effort that hackers have to put into being social like this. I don't smell good, and I bet you don't either. Do you think it's easy for us to hug women?" - Pierce, Manager of Useless Languages, SophSec Research Labs

"Women just don't like getting a beard rubbed in their face." - PostModern, another SophSec member stated before being escorted out of the conference by security for throwing a beer bottle at another attendee wearing a 'Got Root?' shirt.

"I'm actually not legally allowed to have contact with women who are not family, by court orders. This makes hugs really tough for me. Money is really the only thing that makes it worth the risk" - CD, Chief of Epic Lulz, SophSec Research Labs

These views were clearly not held solely by SophSec members, as demonstrated by the crowd who started to cheer on as the contest progressed. It would appear as though Information Security Industry as a whole has been making a collaborative move towards selling hugs to vendors. As time progresses this may open up entire new market places for vendors to exist, and may even spark hope for revitalizing a broken economy. Until next issue, this is Fail Nobra, reporting for Fired Magazine.

Nostalgia

2009-03-16T14:36:00.000-07:00

The IRC wars, the epic battles over the control for servers and the constant beef between hacker crews added fun to being involved in security back in the 90s and early 2000s. Recently a friend linked me a monologue of ownage which brought me back memories of watching these types of wars happen back in the day. Having my name in the greetz also pretty nostalgic ;].

Google Native Client security contest

2009-03-12T17:10:00.001-07:00

The Google Native Client (NaCl):

"Native Client is an open-source research technology for running x86 native code in web applications, with the goal of maintaining the browser neutrality, OS portability, and safety that people expect from web apps. We've released this project at an early, research stage to get feedback from the security and broader open-source communities. We believe that Native Client technology will someday help web developers to create richer and more dynamic browser-based applications."

A security contest is being held by Google to try and busticate their native client code. Some interesting submissions have already shown up on the issues list. Pretty impressive competition.

Real talk

2009-02-02T16:11:00.000-08:00

xkcd is pretty good about hittin the point:

Dont know what you're talking about? Just make up a buzzword!

2008-12-23T14:56:00.000-08:00

Blah Blah Blah, clearly indicative of a Kingpin attack, blah blah blah.

Have you been following the news regarding voting machines being hacked to manipulate the 2004 Ohio elections? Did you catch the brand new sneaky unheard-of totally-0day w00t attack they used? Its called a "kingpin" attack; it works by inserting a computer to intercept and modify traffic between other systems. This is not to be confused with the known-about, popular, common, simple Man-In-The-Middle attack. Nope. This one is completely different. The only similarities it shares with a MITM is EVERY-FUCKING-THING ABOUT IT.

Why am I so upset? Consider this scenario:

person> ohai drraid. how are you?
drraid> hey! good. you?
person> gr8, what do you think about kingpin attacks?
drraid> never heard of it?
person> you haven't?
person> they used it to perform the hack on the '04 Ohio elections
person> what are you new or something?
drraid> i hate you.

Mind you, it is very possible that the government just has some super secret term for MITM, and "kingpin" is just what intelligence agencies call it when they do this. Even if this were the case, it would be in their best interest to call it by its public name for the sake of public documents - otherwise they're disclosing their code names. But come on, let's be real - someone made up this term because he flat out didn't know better, was an avid comic reader, and was fond of the idea that this guy was responsible for the voting hack.

Now, this type of stupidity can't be stopped. So instead of trying to stop stupid people from making up stupid names, I've developed an entirely new stupid name scheme (I TOO CAN BE A STUPID PERSON!):

Buffer Overflows are now called Juggernaut attacks. (I'M THE JUGGERNAUT BITCH!)

All cryptographic weakness attacks are now called Gambit attacks

Cross-site lameness attacks are now called Sailor Moon Episodes. I mean, attacks. Attacks.

Until next time, sniff some glue or something because this place is too depressing without it.

CTF Service Overview: GrimCreeper

2008-11-13T13:20:00.000-08:00

Before it gets too far past Defcon, I've decided to post about a service that SophSec submitted to our homies in Kenshoto to use as a vulnerable service for Defcon's CTF. (For those unaware, Kenshoto is the group of 1337 hax0rs who manage the Capture-The-Flag competition - a pretty cool contest requiring real-world application exploitation skills)

[This is a long winded post, I recommend getting your coffee now.]

I was lucky enough to be involved in writing a vulnerable network service to be used during CTF for the teams to try and compromise. What I submitted was GrimCreeper, a piece of code with a pretty neat bug. Provided below is a basic run down on the service and an overview of the subtle yet devastating bug it contained.

[Warning: Plot Sploiler] If you want to find the bug on your own, leave now [/Warning]

This write-up assumes a scenario using 32bit x86 architecture.

GrimCreeper is a simple network service, providing extremely basic (read: dumb) functionality to its users. Functionality includes a network echo service, time service, as well as a fortune like service returning a lie or a fact.

GrimCreeper had several psuedo-bugs; that is, lines of code which are intentionally designed to look buggy but are not exploitable. The service also contained one real exploitable bug caused by a signedness issue during a size check, involving bit shifting. This ultimately results in a memory copy for a user-specified length into a stack buffer.

This scenario is introduced by accepting a user-specified length variable for the copying of user-specified data. This isn't a typical signedness bug though. An example of a typical signedness bug could look like:

/* 
 * return true if size is reasonable,
 *  return false if it is too big
*/
int some_check_function(size_t net_size)
{
 int checksize = net_size;

 if (checksize <= MAXBUFFERSIZE)
 {
   return 1;
 }

 return 0;
}

With checksize being a signed integer, when it is assigned the value of the (presumably, user-supplied) net_size it will be negative if the value in net_size is greater than 2^31 - 1. If checksize is negative, of course the 'if' statement will evaluate as less than the MAXBUFSIZE macro definition, which is also signed. This type of bug isn't as common anymore, as developers have gotten better about using uniform unsigned size types as well as performing signedness checks before/after assignment.

A step up from this, GrimCreeper performs a size signedness check before handling the user-sizes for anything else. Consider the following code:

/*
 * returns true if net_size is "safe",
 * and can be assigned to a signed int
 * without causing it to be negative
*/
int check_signed_int(size_t net_size)
{
 unsigned int x;
 x = ~0;
 x = (x << 1)>>1;

 if (net_size <= x)
 {
   return 1;
 }

 return 0;
}

This check function can be used prior to the previous function to ensure that the size is not too big for a signed check. (I understand this is getting contrived, but it makes for a great bug setup :P). It is also not entirely unreasonable to consider that this type of code might be implemented in a real world program where mixing of type signedness occurs for size variables, such as in legacy applications/network protocols.

The interesting thing here is that the same function fails when applied to datatypes smaller than int. Consider the following code:

/*
 * function is intended to return true
 * if net_size is "safe",
 * and can be assigned to a signed short
 * without causing it to be negative
*/
int check_signed_short(unsigned short net_size)
{
 unsigned short x;
 x = ~0;
 x = (x << 1)>>1;

 if (net_size <= x)
 {
   return 1;
 }

 return 0;
}

This function will always return true ("safe") for any value passed into it, and thus does not work to check if a large unsigned short will cause a signed short to be negative. Strangely, if the bit shifting in the above function is spaced over two lines, the function does work properly and as expected. Observe the following:

/*
 * returns true if net_size is "safe",
 * and can be assigned to a signed short
 * without causing it to be negative
*/
int check_signed_short(unsigned short net_size)
{
 unsigned short x;
 x = ~0;
 x = x << 1;
 x = x >> 1;

 if (net_size <= x)
 {
   return 1;
 }

 return 0;
}

Voila! The basis for the bug in GrimCreeper. The seemingly subtle visual difference between these two functions has a huge impact on their functionality. Now for the breakdown of how, why, and where this bug happens..

By observing the binary generated by the compiler for each of these functions, the difference becomes apparent. The proper, working implementation of the function (using the shifts across two lines), results in the following binary output:
...

movw   $0xffff,0xfffffffe(%ebp)
movzwl 0xfffffffe(%ebp),%eax
add    %eax,%eax
mov    %ax,0xfffffffe(%ebp)
movzwl 0xfffffffe(%ebp),%eax
shr    %eax
mov    %ax,0xfffffffe(%ebp)

... Seen above, the

add   %eax,%eax

replaces (and acts the same as) the single shift left, and the

shr    %eax

represents the single shift right. The value resulting from these operations is 0x7fff, and is exactly as intended and expected. Now observe the binary generated by the single-line (and broken) version of the function:
...

movw   $0xffff,0xfffffffe(%ebp)
movzwl 0xfffffffe(%ebp),%eax
add    %eax,%eax
sar    %eax
mov    %ax,0xfffffffe(%ebp)
mov    0xffffffec(%ebp),%eax

...
Similar to the previous function, the code uses an

add  %eax, %eax

in place of the shift left. However, directly after this is a HUGE difference: a SAR. A SAR? WTF IS A SAR? SAR is a Shift-Arithmetic-Right, and its action differs from a SHR in that SAR is intended to be used with signed values and retains the state of the signed-bit. This shows that the value is being treated as signed, even though it was specifically declared as unsigned.

It should be noted, that when I first discovered this difference I paid no further attention to the assembly I had in front of me, and jumped directly to an incorrect conclusion. The use of the SAR (and thus treatment of an unsigned short as a signed value) in the single-line shifting had me convinced that this was the result of a compiler bug, and that GCC was generating faulty code. I discussed this difference and showed the C code to several sharp people who all drew the same conclusion as I did. Big thanks and props to Mark Dowd for pointing out what was actually happening.

The cause for this difference is an integral promotion of the unsigned short to a signed integer. This happens because in C every operation on a primitive type that is smaller than an integer results in that type being promoted a signed-integer for that operation, regardless of that original type's signedness. In the case of the shifting happening in two lines, the separation between lines allows for the type be demoted back to a 16 bit value. In the single line instance, the value is maintained in its promoted state, and thus results in a different value. Here is a breakdown of what is actually happening in the single-line example:

1. The value for all 16 bits being set (0xffff) is being stored in 32 bit register %eax.
2. %eax is then doubled via:

add    %eax,%eax

This represents the shift-left. The resulting value in %eax is 0x01fffe.
3. A Shift-Arithmetic-Right is then performed on %eax, returning the value back to 0xffff. The value of the lower 16 bits of %eax, stored in %ax, is then placed on the stack. Ultimately for the size-check routine, the value resulting from this is always going to be 0xffff.

Conclusions and Notes:

I. It is interesting to note that although SAR works differently than SHR, in this case it doesn't matter. The only real significance to SAR %eax being present is that it illustrates that the value is being treated as a signed integer - but since the signed-bit is not set, a SHR in place of that SAR would act the same.

II. During CTF the code for GrimCreeper was provided to the teams as a trick. This was intended to foster a code audit instead of the traditional reverse engineering or fuzzing. The idea was that without an in depth understanding of C and its integral promotion, this vulnerability is very difficult to spot. It truly stands in support of the belief that some vulnerabilities are easier to spot in assembly rather than source.

III. There are hints provided within the source code and the network responses by GrimCreeper which are meant to help teams find the vulnerability; these hints are flawed (accidentally) as they were written while I still believed this to be a compiler bug.

A friend pointed out a much sneakier way of introducing this vulnerability through obfuscation. In the original source code for GrimCreeper there are multiple functions for checking different typed size variables: one for unsigned integers, and one for unsigned shorts. This separation might warrant extra attention, as it appears quite suspect. By making a single #define macro to perform the shifting, the code is a lot cleaner and it becomes even less intuitive that the behavior of the shifting will change with different types:

#define STRIP_HIGH_BIT(var) \
  var = ((var<<1)>>1)

void func(unsigned short s, unsigned int i){
 STRIP_HIGH_BIT(i);
 STRIP_HIGH_BIT(s);
 ...
}

This would likely warrant less attention, and make the bug yet even harder to find, even to a seasoned auditor.

IV. Finally, as I am sure an astute programmer would have noticed, the use of two shifts to achieve this task is redundant. The check is easily performed using only one shift without introducing the bug. I initially discovered this bug during a real code review, and investigated it after wondering if there was any significance to the use of two shifts that wouldn't have been achieved with just one. I am under the belief that two shifts were used in the original code as a safety mechanism, in order to maintain the value of the highest bit, possibly as an old school assembly best-practice. Of course, it may have just been a mistake. Either way, without two shifts there'd be no bug, and no GrimCreeper.

Crypto Cracking

2008-11-06T08:07:00.001-08:00

The NSA may or may not be able to crack your password, but the the Turkish police can almost always crack your fingers.

Crypto key beaten out of suspect

I got Ownd.

2008-10-16T16:11:00.000-07:00

By a CPHFDoS Attack: Cross-Person-High-Five Denial-of-Service Attack. PostModern did this to me. It works like:

"heeey, up high, ooooooh sucker"

The lesson to be learned here: any cross-anything-anything attack can happen at anytime, to anyone. Anywhere. Always.

st0ck hacking

2008-10-12T19:29:00.000-07:00

Stock market manipulation has always been one of those sweet sexy movie-esque types of hacking. It grants hackers the financial gain, the international news props, and of course the power trip (ZOMG I R LEET!). Now that the economy is in the poop bucket, it looks like it might be manifesting - what an ideal time!

Late September, Google stock plummets after NASDAQ "fluke". What happened here? A glitch in the system resulting in massive amounts of requests for Google stock at a price much lower than it was selling for? Smells funny.

An undated article from 2002 reaches Tribune's most popular list, leading to indexing by Google news, and ultimately resulting in the drop of United Airline's stock. Here we have an article discussing United Airline's potential bankruptcy, but from 2002. The article being undated meant that new viewers were unaware that it was not recent information. After being picked up by other news media sources, all it took was commentary by someone popular in the financial market - and BOOM, stock plummets. I'm not going to make any preposterous claims, like that a 5 line shell script running wget + proxy could have made this article rise to the top viewed list ultimately causing all of this, but it is interesting to think about.

Finally, and not unheard of in previous mishaps, Yahoo! Finance misreported the Dow last week, stating over a 1000 point (11%) drop, when really only 300+ some drop had occurred. Short the Dow much?

None of these are necessarily signs of stock market hacking, and I'm not saying stock market hacking is happening. All I am saying is that STOCK MARKET HACKING IS HAPPENING. Anyway, i'm going to go eat flowers now.

PS. not worth reporting in more detail here: if you're a senator running for vp, don't use web mail for your work. thx.

BlackHat and Defcon

2008-08-11T17:37:00.000-07:00

Quick Breakdown:

- I apologize if you were present to witness my drunken ass-hattery on Wednesday evening. A special apology goes out to Greg and Alex for stolen and spilled drinks.

- My song 'Clockwork' did not win the pwnie, but my response from the crowd was still rewarding. A brief review of the awards here.

- Mark Dowd and Alex Sotirov are super pimps for their talk on "How To Impress Girls With Browser Memory Protection Bypasses". This talk introduced a very clever means of bypassing the memory protection mechanisms in Vista when dealing with browser exploits. Phenomenal talk with an awesome sense of humor.

- I passed the NOP cert by Immunity, with an embarrassing time in the mid to high thirties (I forget my exact time, but it isn't flattering). This was a fun test, and I recommend it to anyone who gets a chance to sit down and take it. In the 40 minute time limit, it tests your ability to find and exploit simple stack overflows on Windows 2000.

Clockwork Nominated

2008-07-22T13:15:00.000-07:00

My track clockwork has been nominated for Best Song at the Pwnie Awards! WooT! I'm apparently the only non-vendor supplied entry.. Wish me luck!

DNS, and Errata

2008-07-15T10:08:00.000-07:00

A serious DNS bug discovered by Kaminsky (lol surprise?) is rocking the Intartr0nz as people shit their pants and take guesses at what it is. Some interesting theories have come up, but it looks like we'll have to wait until his presentation at Blackhat to know for sure. My personal guess: you call Mrs. Cleo for the TXID to spoof. She knows everything.

On a side note, supposedly some cool (read: exploitable) bugs in Intel's chip errata are going to be presented this year at HackInTheBox Conference. These bugs are actual chip-level flaws that cause undefined or unwanted behavior - and apparently in some cases introduce vulnerabilities that are OS-independent. This type of security bug has been discussed in theory for a long time, so it will be interesting to see how it all turns out. More info about the errata bugs here

Address Space Layout Information Disclosure

2008-06-25T12:40:00.001-07:00

The software exploitation game is changing as new pieces come into play. Protection mechanisms like ASLR and stack canaries are changing how attackers approach memory corruption bugs. Both ASLR and canaries can significantly hinder traditional exploitation techniques. One interesting aspect of these protection mechanisms is that while they do hinder some attacks, they also magnify the severity of other vulnerabilities which were previously (for the most part) insignificant: memory information disclosure vulnerabilities.

As a code auditor, when I would run across some sort of pointer arithmetic or buffer walking that resulted out-of-bounds data reads, I would tag them as informational bugs. These are typically seen as the result of faulty logic or bad coding practices. Occasionally, depending on the type of information being disclosed, there would be some security value tied to the bug: credential exposure, plain-text exposure (where crypto was used), etc...but these are mostly corner cases.

However, now that security mechanisms like ASLR rely on the premise of an attacker being unable to get specific process information, these bugs transcend into an entirely higher class of value. If an attacker can get a consistent read from out of bounds on a given buffer, here are just some of the potential vectors it could be used for:

- Canaries: the most obvious answer. This case would completely subvert this securtiy offered by stack/memory structure canaries.

- Application Pointers: these are also obvious, as they would expose the address space layout of an application, defeating ASLR.

- Stack Frame Pointers: ..etc..etc..

- Library Addresses: ret2lib[X]

- Rick Astley's phone number: this is stored by default in every application compiled with the new Visual Studio.

Of course the conditions are rare, and are probably specific to each scenario, but this may become a serious consideration being that such trivial bugs may ultimately become enablers for threats which were otherwise de-fanged.

Just a thought.

DCCP

2008-06-09T16:47:00.000-07:00

The Linux Kernel team published an advisory about a vulnerability in DCCP that was reported by some asshat.

More information about the DCCP vulnerability here.

Sad media, sad kids

2008-05-30T13:16:00.000-07:00

Many may be aware of the script kiddie group called Kryogeniks for their recent antics which have gathered media attention. If not, here's some reminders:

17 year old arrested for AOL 'Hacking'

and

Comcast DNS Hijacking

Two separate incidents warranting public attention for big bad illegal hacking. From the way the media portrays these events, one would conclude that these attackers posses the technical skills of elite super-hackers. In truth, these kids are starter-level social engineers who couldn't write a HelloWorld, make any real use of access, and fail at keeping their spoils. How could I speak on this with such broad confidence? Because I have had the unfortunate luck of having to communicate with these kiddies from past exposure. (Truthfully it is embarrassing that I even know them, given their lack of knowledge and competence).

Don't go and misquote me now, for saying that social engineering is not effective -- it is effective. Very effective. In fact, to quote one of Murphy's Laws of Combat:

"If something is stupid, but it works, it isn't stupid."

Having gotten that out of the way, social engineering is the art of a conman. These kids are no more hackers than those behind the Nigerian check fraud scams that come in via email; just because you use technology to lie to someone does not make you a hacker. I am not excluding social engineering from hacking, or the obvious fact that deceit in general is a huge component of hacking. I am merely stating that this kids are not hackers.

Why does any of this matter? Because the media influences the public, and the public ultimately influences the security industry. When the media fails to distinguish between kiddies and real skills, the result is that these kids become classified in the same category as people like HD Moore or Kostya Kortchinsky. The reverse association causes the public to then think that people with real skills are the same brainless morons who deface comcast.net with a social engineering phonecall that you're grandmother could have performed.

No wonder no one seems to take this shit seriously.

I told you crypto sux.

2008-05-15T11:09:00.000-07:00

Yeah so apparently someone on the Debian development team should have been forwarded the memo about Why Crypto Sucks. Great. Now half the of the fucking interwebz has to regenerate keys so that my private discussions with the Avril Lavigne fan club stay private. And nothing can be done to secure any information that was publicized in an 'encrypted' (encoded) state with the broken keys.

Broken: SSL. SSH. Half the universe.
Shit I might as well just break my ankle to make it a 5-for-1 discount. And a special someone should have their fingers broken.. I've killed for less.

I guess it really doesn't matter, since you can resolve any plain-text from public-key encrypted data by multiplying by 2/7.

Don't worry though, ROT13 wasn't affected by this, so all you brainiac developers with your homegrown crypto are still safe..LOLOLOL. Do you know what time it is? Hammer time. Hammer fucking time.

New Vulnerability Class - XSRR

2008-04-01T08:38:00.000-07:00

There has been a lot of buzz in the last two years over web app vulnerabilities like XSS and XSRF which had lead to a frenzy of research to find more new classes of vulnerabilities. I have been lucky enough to be associated with the discovery and naming of a brand new type of web application vulnerability, being called XSRR, or Cross-Site Rick Rolling.

To give you a rough breakdown, the XSRR attack is a user-assisted attack with the potential to yield full compromise of the victim's sanity. The attack is composed by convincing a user to open a media file or follow a link leading to a media file which contains music by the all-time heavy weight MMA super champion Rick Astley.

A simple walk though of this can be seen at this demo page.

Defenses for this new class of attacks are actively being developed, and there is currently a firefox plugin called RickRollDB which maintains a bkacklist of all known sites usable for performing XSRR. As you can see, I'm never gonna give you up, never gonna let you down; never gonna run around and desert you.

shmoocon 08

2008-02-22T09:51:00.000-08:00

Went to ShmooCon for the first time this year -- it was a killer time. Quick run down of stuff learned:

-- Solid-state drives and USB sticks should not be trusted as erasable media. Short end of the story: if you need to keep sensitive data on these, use crypto, because there's no guarantee you will be able to remove data when it comes time to delete. Recommended secure wiping for these devices: hammer.

-- Client side exploitation is becoming as (if not more) important in a pentest as server vulnerability assessment. This isn't new to any one in the security industry, but it seems like clients paying for pentests just don't get it. Jay Beale spoke about this, and it was a pretty entertaining talk.

-- SIP/VoIP vulns .. there was an ok talk on this stuff, but the demonstration of illustrated attacks fell through :(. The short of it: XSS/XSRF in web servers embedded into VoIP gear. Also, "chess grand-master" cryptographic architectural weaknesses in the nonce exchange/authentication used by many VoIP devices.

-- Nerdcore rap is becoming scarily popular. Expect more on this.

-- Open bar @ Shmoo party = hackers spilling drinks, and secrets ;P

2008 Security Predictions

2008-01-03T17:37:00.000-08:00

Happy New Year everyone! Today's post is about my complex and in-depth security predictions for 2008. This list covers the new topics we will see in security as 2008 progresses:

1. Vulnerabilities
2. Malware
3. More dumb fucking script kiddies
4. Botnets
5. Trolls on Full-Disclosure
6. Return of the AOL punter
7. Introduction of a new vulnerability class: ASCII-pr0n injection (API)
8. Vista pop-up security alerts
9. Automated web-application vulnerability scanners
10. Quiznos Chicken Carbonara

I know a lot of those seem out there, and sure, a few of them might be a stretch.. but mark my words: all of these revolutionary security topics will manifest in 2008.

Why Crypto Sucks

2007-11-08T15:55:00.000-08:00

Crypto can be used to do sleek, sexy things. Privatize information. Ensure data integrity. Dice onions. But it sucks, and here's why:

- Hackers use crypto to store their uber hush-hush topsy kretts.. but spew all their information after 4 drinks at a Toorcon party.

- The three letter agencies don't care about your crypto, because they've owned your box and watched you type in the password.

- Cryptographers have been known to write insecure code. Nice strcpy into your key_buf[], homie.

- Developers have been known to think they're cryptographers:

#define MY_KEY "lololol!"
void encrypt(char *data, char *cipher, int len)
{
int i;

/* nice. */
for (i = 0; i < len; ++i) cipher[i] = data[i] ^ MY_KEY[i % 8];
}

- Developers sometimes do use well established, certified crypto in their code... and then store the symmetric key in #define TOPSY_KRETTS.

So what do we do about it? I have a secret 0day crypto algorithm I'm releasing right here:

void secretz(char *source, *char dest, int len)
{
int i;

if (len == 5)
return;

for (i = 0; i < len; ++i)
{
dest[i] = (((((((source[i] ^ 5) & 0xff) ^ i) & 0xff) ^ i) & 0xFF) ^ 5) / voodoo[i % infinity];
}

exit(1);
return 4;
}

That should do it. I'm pretty sure its clownz.

This just about sums up code auditing

2007-10-14T19:38:00.000-07:00



int SumDumFunc1(char *s)
{
    blah blah;
    blah blah[45];

    blah blah blah blah blah blah blah blah blah;
    blah blah blah blah blah blah blah blah blah;
    blah blah blah blah blah blah blah blah blah;
    blah blah FUCKING VULN h blah blah blah blah;
    blah blah blah blah blah blah blah blah blah;
    blah blah blah blah blah blah blah blah blah;
    blah blah blah blah blah blah blah blah blah;
    blah blah ANOTHER FUCKING VULN RIGHT HERE ah;
    blah blah blah blah blah blah blah blah blah;
    blah blah blah blah blah blah blah blah blah;
    blah blah blah blah blah blah blah blah blah;

}

Malware Tag

2007-10-11T17:42:00.001-07:00

Proposal for Malware Tag:

With the pending inconsistencies and ambiguities around malware and its propogation through websites, it has become apparent that a change is in order. After long conversations with my good friend Imul from lul-disclosure labs, a solution has manifested: the malware tag. A revolutionary concept, this tag aims to unify how malware is represented -- allowing web browsers and their users to act accordingly.

The advantages of the malware tag are vast. Deep inspection firewalls would be able to filter traffic upon layer 7 detection of markup tags (previously the layer 3 evil-bit was the only option available). The combined ability of both evil-bit and malware tag detection gives network appliance vendors a very sexy yet functional and markettable product. The malware tag will redefine world class paradigms, and spearhead Web 3.0 as bleeding edge technology. Heres how it will work:

- Sites with malware must place <malware> </malware> around content which could be percieved as malicious software. Sites which fail to do so will not be Web 7.0 compliant.

- Sites which do not host malware should not use this tag, as it is misleading to users and may ultimately result in mis-representation/public relation issues.

- Starting in Web 4.6, all Browsers must observe the malware tag, and present the user with options pertaining to the malware type. Some suggestions would be to request the user to type in or email the site owner with all passwords/credentials (as to ease the transition into being owned). Randomly deleting files or sending the malware on to other users by hand are also options.

- Malware writers should categorize their products so that they may be easily representable in markup languages. This will allow for the creation of other tags like <deletes_files> or <botnet_client> . Classification of malware specifics will help browsers act accordingly.

-AV products may search for specific tags, which will determine how they should act: <detect_immediately> or <miscategorize> or <do_not_detect> are some examples.

This is just a draft, and some of the Web versions might need to be adjusted (for Ajax and things), however once thing is certain: <malware> is the new hotness. Suggestions/input/tag features are welcome via email, as long as they are in before I send in the tag proposal to w3c.

/GS pointer subterfuge

2007-09-18T13:58:00.000-07:00

Ok so after people complained of not having a valid code example for my previous post 'smoke & mirrors', here we go:

-- begin snip --


int main(void)
{
   meow();
   return 0;
}

void meow(void)
{
   int x;
   int *y;

   y = &x+3;
   *y = ((int )woot);

   return;
}

void woot (void)
{
   printf("owned\n");
   return;
}

-- end snip --

woot() is never called, but by pointer offset its address is used to overwrite EIP resulting in a jmp to it at the end of meow().. /GS does nothing.

infosec glossary

2007-09-18T10:49:00.000-07:00

Many people who are new to information security are overwhelmed by all the terminology, so I've created a light glossary of terms for quick reference..

Threat Model: Jessica Alba with a gun

XSS: the size of shirt making it appear so tight on the threat model.

Full Disclosure: what happens when that same shirt comes off :D

Remote Compromise: the agreement made between 2 television viewers over which channel to watch.

Denial-of-Service: this is what occurs if you enter a 7-11 without shirt or shoes.

Rootkit: a do-it-yourself bonzai tree package, usually given as a gift.

Heap Overflow: too much laundry to keep in one pile.

Stack Overflow: a similar pile problem, but with paperwork at your job.

Trojan: what you need before hitting the clubs -- you might meet a girl

Penetration Test: where the trojan will come into play

Backdoor: where she'll ask for it, if you're lucky

Zero-Day: time remaining for you to get that marketing proposal done

Firewall: where you line up at the unemployment center if you fail to finish the marketing proposal

..more to come..

Ssh! keep it secret.

2007-09-16T17:57:00.000-07:00

meow mix delivers

Buzzwords

2007-09-11T09:32:00.000-07:00

LoL! I got my ASLR AJAX DEP enabled with Web 2.0 hypervisor rootkit dual-core capacity. Now that my determined adversary's look-asside list is a dangling pointer, the biometric cross-site request forgery will probably end up with 802.11-N (mimo technology, ofcourse). This all assumes the penetration test rainbow table doesn't result in a 'trivial' iPhone TitanRain exploit condition. Its trivial, like quantum prime factorization.

Buzzwords are for bitches. Write some code. Word.

Infosec Burnout

2007-09-02T10:33:00.000-07:00

Information security sellout or burnout? The hype/buzz around the infosec sellout blog has died down now, with the apparent spammer compromise of the blogspot account where posts were made.. kind of a shame, considering the sketchy yet entertaining nature of the character(s) making posts.

Truth be told, I don't think there are sell outs anymore in infosec. All the good people from way-back who would sell out have already sold out, and anyone else is too new to have been anything other than an industry whore. The sad part is now we're in the age of the burnouts. The burnouts are both the sellouts aswell as those who with-held from sacrificing their pride. The hacker rockstars who molded the very industry by revolutionizing how security is perceived, now so sick of the bullshit that they don't even touch computers anymore. It is a tragedy of sorts. I find myself meeting up and talking with legends who have re-aligned their life interests, changing how they want to live -- abandoning security altogether. With the commercialized snake-oil, branded bullshit selling off the shelves (John-Joe Pentest and Company), and lawsuits against anyone doing anything interesting (Apple, Apple, and Apple), there just isn't enough room for any truly talented hackers. Smoke crack.

Sm0ke & Mirrorz

2007-08-28T13:30:00.000-07:00

[Update-6/6/2008]: A friend pointed out that this post is only relevant for Visual Studio 2003. Newer implementations of the /GS flag, (in Visual Studio 2005, etc) XOR the EIP with the canary. This implementation is a lot sexier and makes the description by Micahel Howard accurate. It should be noted that if there is more than one pointer that an attacker can use to perform a read and a write, it may still be possible to subvert EIP without triggering /GS.

All the pretty lies tickle me pink.

Remember when..

- "You won't get owned if you don't open the email."
- "You can't get owned just from viewing a picture."
- "An overflow? Oh but it's on the heap, we're ok."
- "Our WiFi has the SSID hidden + WEP, so unless you know about it.."

Time and time again the false sense of security shared by technology users gets shattered with the publication of a total-pwnage proof-of-concept. With their faces hitting a rough pavement of truth, eventually you would think that they learn. But really, SHIT NEVER CHANGES. Presently, you have these dumb-f^cK$ running around, acting like ASLR + Stack Canary + DEP means they can let their guard down and resume smoking crayola rock. It gets worse when a trusted information security source provides incorrect information that gets turned into a Bible reference.

Take Writing Secure Code, 2nd Edition by Michael Howard, for example. This book is relatively well written with a lot of accurate information intended to help developers understand and write secure code. Before I say anything else, I would also like to give Michael his props -- he knows his stuff. The problem is that even the slightest technical mishap in the description a coding bug or protection mechanism can result in a cult of ignant developers. Yes, I said ignant. Especially when the book is dubbed 'required reading' within a corporation.

Page 168, in the context of describing buffer-overflow mitigation, outlines the security-add offered by the protection mechanism within Visual Studio's /GS flag. (For those *nix people out there who won't/don't/can't touch MS Visual Studio, the /GS option implements stack cookies/canaries similar to those of Crispin Cowan's Stackguard, with a little more voodoo. For those of you who are not familiar with the stack canary/cookie concept, might I recommend a career in Basket Weaving.) On each point listed on page 168, a known attack method (stack smashing, heap overruns, etc) is given with a description of if/how the mechanism can be used to prevent exploitation. For 'Pointer Subterfuge' the following description is given:

"Overwriting a local pointer in order to later place data at a specific location--/GS can't stop this, unless the specific location is a return address."

This description would be 100% correct if it were just 7 words shorter; stopping at "/GS can't stop this". If an attacker controls a pointer directly pointed to the return address, and touching nothing else, there is absolutely nothing to trigger /GS. I mean this is pretty obvious, please don't think im saying this is something new -- it's just textually incorrect. Am I just being a pedantic asshole? You bet. Does my asshole-like nature inhibit developers from mangling security with this information? Not at all...

Again I should note that Michael Howard knows his shit, and he alerts developers not to place blind faith in the protection mechanisms described. I am by no means categorizing him with the idiots who unknowingly perpetuate stupidity on a grandiose scale.. My concern is that in a world where "Oh its on the heap, we're okay" was the mantra for years, the most minute inconsistency could ultimately lead to a slew of mayhem. These inconsistencies are everywhere, and they allow people to believe in smoke and mirrors.. Tickles me pink.

dr.raid, rainsec, and the revolution

2007-08-27T08:38:00.000-07:00

w00t. RainSec was killer this last Sunday; good turnout, awesome discussion, fluid group dynamic. We have things in the works. Things to be on the lookout for: united scene in Portland, party at defcon, and vote Dr.Raid 4 Emperor '08.

SophSec - WtF?

2007-08-24T09:00:00.000-07:00

With SophSec having released some code (well,..kinda ;), and having given a talk at ToorCon Seattle Beta, we've been asked "WtF are U, WtF do U do?". Good question.

We don't have a public business, we don't sell services, and our group motto is "Sketchy Shit, Competitive Prices". If we were a business, who would take us seriously? Even our name it self "SophSec" is a parody.. a parody of the bulk-sale snake-oil that manifests after some well funded assholes start a business using some shitty word with 'sec' in it, and calling it a Security Firm. This results in an organization that is devoid of talent, named "Clandestine-Sec Services", selling nothing more than a false sense of security. Ultimately these businesses end up giving those of us who are truly passionate about security a badname.

SophSec is just the opposite. We're trying to promote growth in the infosec field, sprinkled with a little bit of sketchy. We also serve as a front; we have an affiliate program for people who still want to work on cool security projects/PoCs/whatever without their name tied to it directly. In this way we almost operate like an intel agency, keeping the identity of our affilitates secret if they don't want to be known. At the end of the day, we're about getting shit done. Cool Shit. Movie hacker type shit. Word.

begin here

2007-08-16T17:26:00.000-07:00

So in my introduction I wanted to write something funny,.. you know, like those blog people who say silly shit like they handpaint the Ms on M&Ms for 14 hours a day, or are as laid back as Stephen Hawking. The truth is I'm just not a funny person. I occasionally find myself in laughing fits, but end up resuming normal activies after I forget where I dropped the rubber cement. Professionally, I work for a big security company doing security stuff, securely.