Luigi Auriemma

Often many people not in the computer's field think that finding bugs requires magic powers or incredibly high skills... I know these things help a lot but anyone is able to find good security vulnerabilties.

In reality what are bugs? Just only programming errors, a forgotten check, an unitialized variable, a wrong or an absent parameter and so on.

Here I would like to know what are the preferred methods used by other people, and so I will start with mine.

The following things are written just for giving a generic introduction so if necessary I will update them in future.

Just a bit of personal history, from the end of the 2000 I started to have a certain interest and curiosity about security vulnerabilities in software and so I started to follow the stuff posted by the other people on Bugtraq and on other websites like Packetstorm and so on.
Anyway after some time of "read-only mode" (ih ih ih ) I decided to try to find vulnerabilities by myself and so I started to do some manual tries with some software, the first of which was Apache for Windows.
Well, with the help of only notepad and netcat and some time of tests I found my first bug, a Denial of Service in Apache for Windows caused by a off-by-one vulnerability.
Really not bad as first bug ih ih ih

What I want to say with this small anecdote is that anyone can find bugs, important and less important (but what really makes a bug important? Personally I prefer interesting bugs to "famous" bugs), and luck is ever one of the most important things.
An example of luck?
Strangely I have ever had many luck with vulnerabilities but one of the best episodes was again with Apache (and ever the Windows version!) since the new 2.x version introduced a directory traversal bug and casually I tested just that new version and found that bug before any other one... that's luck.

In short what I usually do is simple:

- learn the protocol
for example games have all different protocols and so everytime I need to understand a new one while other software are usually based on open or common standards like for example the HTTP servers
Understanding the protocol is an important step, remember it

- find possible weakness caused by the protocol
exist protocols or part of protocols which can lead to vulnerabilities more easily.
For example we could have a 32 bit number which tells how much long is the data which follows it, in this case is possible that the application tries to allocate the amount of data specified by that number and in this case we can force it to fails the allocation hoping it doesn't check it, or it uses a fixed buffer for storing the data without checks and so we can cause a buffer-overflow, or could exist a problem of sign and so on... this is only an example

- finally find the bugs caused just by the software
this section is practically an extension of the previous one, anyway take the previous example and imagine if the data received is a chat message and the program visualizes it on the screen using a printf() without format argument... the result will be a format string

The consecutives "tries", which I think can be called manual fuzzing, have been ever my preferred technique for finding vulnerabilities.

If you have the source code of the program to test you can also decide to follow the code auditing choice, which means controlling the source code manually searching vulnerabilities, or you can use the tools which automatically check the source code.
In both the cases you can't be sure of the bug until you test it in practice.
For example there was a game with a visualization function which uses sprintf() with a stack buffer of 2048 bytes or similar but the maximum data you can send to it (for example from a client) is 1024 and so the bug in reality doesn't exist.
Same thing with the Quake 3 engine and the function which handles the authorization packet where could be located a very interesting bug but unfortunately (or fortunately) the destination buffer had the same length of the source one although this thing wasn't quickly visibile and I needed to do some tests before confirming it... yes another anecdote ih ih ih

A similar thing as the source code auditing can be made with closed source software too, just follow the assembly language... ok it's not confortable as having the source code but you can catch something interesting.
Usually this technique is used with the inserting of breakpoints to known functions which often lead to programming errors like sprintf, sscanf, strcpy, strcat and so on.
Actually I don't remember bugs I have found using only this technique, but my memory is a disaster so this is probably normal.

Well, for the moment I think it's enough... I wait your stories!!!

Nice luigi thank's for the share it was a good read.Ill write some thing up tonight !! :lol:

I have always been curious on how things work since the age of 11 when I got my first Commodore 64. I would sit up all night programming in BASIC and I didn't even know how to save my work, but I would continue to learn how to make a cube on the screen or print something to the user. For the past 5 years I have become passionate about bug research and have taken several courses, but I have never found the "starting point" on how to go about finding bugs. Do I start with a fuzzer, but then you have to know what fuzzer to use and what arguments to feed it, do I start with notepad and netcat and start feeding a program a bunch of garbage and study the results or do I review the source code and do a code audit. As I scrambled to learn I have discovered that finding bugs requires you to learn every piece about the application your trying to find a vulnerability and there is no 1 piece of software that does the "magic" trick. I have yet to find 1 bug, but I am enjoying my learning experience and learning from others like Aluigi who has created such a place for us to come together and share our knowledge/experience.
Happy Bug Hunting.

I think i started back in 2006-06-02 looking for exploit's,I didn't realy understand much back then.So had a little play with html tag's:D.And came across the (marquee) Denial of Service Exploit for fire fox.

After that i started to look into exploiting http server's with overly long http request's nothing new and found a few dos exploit's.Then i think i started to look into client application's.Then came across the xfire client dos exploit.This is where i thought i was getting some where.

Then i started testing local file for buffer over flow's after reading about marsu advisory's,And come across the opera torrent file dos exploit.But didn't look into it as much as i should have and idefence took the hint and started looking into the bit torrent protocol of opera ,And took credit for a buffer over flow in the opera client when parsing malformed torrent header's ,Strange coz i had only released the dos a few weeks earlyer.So from that point i releaseid if i was going to test software test it to the full.Then i came across a buffer over flow in MagicISO,I was not in full control of the eip register i tried every one who i heard about just sending them random email's asking for help.And vade79/v9 v9@fakehalo decided he would try and help me,He wrote the first advisory with poc code describing haw he got the cue file to execute shell code.

I then relized hey ill test UltraISO then came across a standard buffer over flow,And was able to execute shell code wrote my first real exploit.
why the application crashed and what can we do with the bug.

I've thought many time's im going to give up and just before im about to give up i came across vulnerability's if you put 100% into exploit development and don't give up you will succeed it's not if it's when.

But i was in the security related subject's for over 7 year's now started as a skiddy lol,Every one got to start some where and got bored easy with skiddying about and wanted to learn more and decided the right way to go was exploit development.

I think if you want to be a hacker it's not about downloading other people's exploits and just compile and run.Its about finding your own 0day and using it.


I've wrote a little list that alway's help's me..

1).Chose software look for information read the read me lol.

2).Put it through ida pro or some other disassembler.

3).Look at the part's of the program which take user input any file or protocol.If it data readable data and you understand what it is doing you might be able to extend the buffer.

4).Always's have a debugger attached to the process when testing.

5).If you do come across a buffer over flow be prepared to write a poc code to help reinact the bug or exception.

6).Write fully working exploit and release.!



Be prepared to get into trouble,Like last month i managed to get access to a hosting company's admin login through using a google dork id been thinking about for a while.So be prepared on haw far you want to go with hacking it can get you into some serious trouble if you go to far.When i got access to the web hosting panel i had access to 41 thousand + host's,I had to do the right thing and notify the web hosting company so i did i've added the talk i had with the guy from the hosting company.

{Transcript.}


Pete: hi
security advisor: hi
security advisor: could i talk to the guy in charge please
security advisor: Of the whole company
Pete: Well, please let me know your issue
security advisor: I've got some very important information\
Pete: let me know
security advisor: nvrmm im not sure what is ur position im in a funny position i've come across some very important stuff to do with your company
Pete: Please let us the know that stuff so we can assist you further
security advisor: Yes but im affraid of haw can i put this any action being taken against me if you understand .>
security advisor: I dont think it's a case of haw u can assist me it's haw i can help you m8
security advisor: Ok there has been a breach in your security for a start im only here to let you know i have no intention in causing any harm or any thing
Pete: Please let me know the exact issue
security advisor: well i was able to acsess all your domain's all 41741
security advisor: Im trying to do the right thing i hope you understand
security advisor: hello are you still there
Pete: yes
Pete: Please go ahead
security advisor: Would any action or any form of any thing what would get me in trouble happen ive not done any thing to any thing in company.
security advisor: You have to understand i dont want any trouble from this i just wanted to inform you but i was advised it could get me in trouble
Pete: ok
security advisor: Ok you need to change the admin pannel password for the hosting here is the password i was able to get from google on some one else site
security advisor: https://resellers.ipowerweb.com/panel/index username: +++++ password : ++++
security advisor: That's what was in the file
security advisor: i can try and find the site it was hosted on so you guys can get it removed
security advisor: Do you understand what im saying now m8
Pete: thsank you
Pete: thank you for the update
Pete: We will change the password
security advisor: that is ok i just didnt want it falling into the wrog hand's you recognise the password and user name
security advisor: that would have been a masive breach to your customer's and sensitive information nothing has been changed
Pete: We appreciate your concerns for us
security advisor: Loool goood im pleased i was able to help m8 it feel's good to help some one out you guys have been very lucky
Pete: I am updating this issue to My Admins now, We are all thankful to you and appreciate your concerns for us
security advisor: np take care m8 i have no idea haw they were on some one web site but they were so just change the password and username all should be good ..
Pete: I would appreciate if you let me know a google link
security advisor: I will have to find it give me 2 min's the file was called
security advisor: *****.doc
Pete: ok, thanks
security advisor: there was some more info in the file but im not sure if it's connected with your web site
Pete: please provide us..let me check if this some ex emploee
You are not currently in a chat session.
You are not currently in a chat session.

I had pulled 2 dbx file's of the hosting company's site.Which contained customer's scanned personal detail's credit card detail's driving license and loads of other detail's which they had took for id.And sent them through email.They all got destroyed after.

n00b you have catched just an important point when you talk about testing better the bugs we find.
In fact could happen that you see only a crash and you think it's only a DoS while instead it could allow code execution.
This happens often and happened to me moreover in the past or when I don't see a valid way for controlling the code flow.

Yeh luigi it's crazy ive saw people testing bug's and stuff and releasing a poc code with out any actual debugging information.If you look through all my poc code's they come with debug info attached.But alot of people who are starting out don't attach a debugger because they don't under stand the whole point of debugging in order to find out if any of the register's are controlled by our user supplied data.

great post. i can code some exploits, even with stack-shield, amd64 arch, really small buffers, randomized stack etc etc but what i really miss is the workflow to find bugs.
i usually start from the code, i see that you do pretty much the opposite, you start fuzzing first
i would LOVE to see a session of you working! i really lack skill in fuzzing :(

this is a thing which a lot of people ask to me.
the main problem is making the video and making it understandable because naturally I can't know how much time will keep the research session of a specific software (minutes or hours and sometimes just seconds) and so what type of method adopting (if you don't find a bug quickly you make deeper tests), or if the software is open or closed source (the majority of my tests is on closed source software) and then each software sometimes require a different type of test, for example if it uses a proprietary protocol (the typical situation which I find) is required first to reverse it and then building the fuzzer/tester manually.

I can explain with words what I did for example with a software like McAfee ePolicy Orchestrator where I found a nice format string in its framework which is used also by other McAfee programs that consequently are vulnerable if they use that bugged logging function:

http://aluigi.org/adv/meccaffi-adv.txt

This was a blind protocol reversing since I had no example packets on which working to identify the protocol, so all the protocol reversing and the rest of the research was made only with a debugger.

The first step was to understand what type of data composed the TCP packet (although it's TCP is ok to call it packet for easy comprehension) so I placed the program to test under debugger with a breakpoint on recv and wsock32.recv and then with netcat I sent some AAAABBBBCCCC chars to the port on which it listened.

The next step was placing a memory breakpoint on the first A of the packet for reaching the place where started all the operations on the data.
The first data of the packet is a text part so there was a "rep cmp" which compared my strings with those of the program and then an instrunction for reading the DataSize value which contains the size of the data we want to send (data1 and data2)

So at this point, after some reversing, we already know that the packet is composed by a text header followed by two types of data, the second of which is encoded.

For the first data was enough to watch the "compare" operations made by the program for checking the values in it, this was also good to check if these instruction were or not responsible of possible buffer-overflows (like missing checks or integer overflows) but they were ok.

For the second data luckily the encoding was a simple XORing of the data with 0xaa which was easy to figure.
This data is composed by fields with a fixed size so there were no problems here to figure them.

So I arrived to this point without finding bugs and the next step was to test for a possible format string placing the classical printf formatters in these strings which caused the exception.

Usually the format string bugs are just in the logging functions so I opened filemon and sent a valid packet to check if was written a log file and then I saw that there was a log file and the content used by the attacker was just placed in it without the needed format arguments.

Naturally after having the working client emulator in my hands I tested also for other possible vulnerabilities but that format string was the only one I found after many tests.

Bug found and released the same day 8-)
I know that this is not as watching a video but I hope it can be of help

that's really clear. of course a video would be better , even if you don't find a bug should be nice to see for example just a session with all the tests you make :p
but i understand the problem related to recording and i don't want to push much on that.
thanks very much for the detailed post! i will start to fuzz-test much more :D

after reading your post i'm thinking that auditing open source programs can be much tougher... the code is much more secure, for example now it's really really hard (or impossible) to find format string bugs because they are already fixed... the only bugs you can find is where the bug is triggered in really strange ways...

what do you think about that? can you make an example similar to the one you just posted but regarding an open source program?
many thanks!

ciao :)

The most recente examples of format strings I have found in open source software are the following:

http://aluigi.org/adv/whitedunboffs-adv.txt
http://aluigi.org/adv/vlcboffs-adv.txt

Naturally the one in VLC is the most interesting since it's remotely exploitable and if I'm not in error I found it through fuzzing since I simply sent a file with various HTTP parameters followed by format string values.

Anyway format strings are ever a current type of vulnerability on both open and closed source.

omg how can a big software like vlc, in 2008, still have format strings bugs?
great find again, and thank you for writing such detailed advisories!

First of all, Thanks to n00b and Luigi, this topic give me a lot of insight into Vulnerability research, I'm new myself to this

and i wanted to ask, since its 2009 and OS and applications starting to use more built-in protection mechanism (NX, ASLR...)

does that mean Buffer/heaps overflows and other memory curroption flaws will disappear, who knows something new might come up in the future :)

and i hope I'm not moving away from the main subject of this topic.

Thanks,
Ab

obviously it's normal that more time passes and less cool bugs remain.
an example is the fact that 90% of the ehmmm "bugs" are web stuff (probably simply because anyone can find them without particular skills) and the rest are usually integer overflows (like buff = malloc(your_number, sizeof(int)) with the subsequent copy of the data in buff) and vagues "memory corruption" problems.

so imho the future will continue to be in this direction and moreover with an eye on those software which implement the horrible and risky script engines (like javascript in a pdf reader, what idiocy) which can even allow to transform a harmless null pointer in a code execution bug.

uhmm what else remains? uhmmm ah the activex bugs but they are so ridiculous that I don't consider vulnerabilies at all, the vulnerability is just the same concept of activex (which in fact is used only by IE) and obviously is not possible to find a bug in a bug :)

anyway don't forget the other types of vulnerabilities, for example those which cause a denial of service in the server application (like null pointer, because a DoS can be considered a bug only if it affects the server or can be exploited versus the other clients connected to a server from another client (usually games)) or other non-programming language related bugs like the directory traversals and informations disclosure.