Basic learning: Tricks & Code =============================================== Version: 1.3 Date: 2003-10-07 Written by: anonymous@warindustries.com feedback: postmaster@warindustries.com or http://forums.warindustries.com/ url: http://www.warindustries.com =============================================== Welcome back, this document assumes you read Basic learning: Finding bugs(Part1), and Socketfunc(Part2), Common techniques (Part3) You can find them here: http://www.warindustries.com/html/?p=6 Document series Part1 - Basic Learning: Finding bugs Part2 - Basic Learning: Socketfunc Part3 - Basic Learning: Common techniques Part4 - Basic Learning: Tricks & Code Please read previous documents before proceeding. Introduction Yet again we play with the virtual reality. This time I will take alot of examples directly from unix environment, including some c-code, I will talk about , brute force, some other stuff, and more security ofcourse. Like always, simplified to the max, hope you learn something new this time aswell. Okay alot of these examples are done in unix/linux, so you have to get something for a start, like I mentioned before I recommend slackware for a start, it's free to download. Just take a look at their website: http://www.slackware.com/ , it's fairly easy to install and get connected, I might make a tutorial for that in the future. For you people still in windows, read on and learn, I will be making more windows examples in the future, some of the things applies to both windows/unix (computers in general), but please, if you want to advance, get *nix. It's not so hard that many people in general think. Some clarifications, when you see ( root@r00tbox:/# ), this is just similar to the command prompt in dos, only in linux instead. Just like C:\ in dos. So what we have there is a linux (bash) command prompt. GCC is a (linux/unix) c compiler, that makes the c-code into an executeable file. ---------------------------------------------------------------------------------------------------- 1:1 Safe Browsing/Surfing 1:2 Unix/Linux stuff 1:3 C ,sockets / data (linux/unix c) 1:4 The 4th dimension 1:5 Brute Force 1:6 User input ---------------------------------------------------------------------------------------------------- 1:1 Safe Browsing/Surfing Never ever expect to be safe when you open a website, even though you might have tuned your security level settings, set cookies to not be accepted nor run activex controls/java, it's still fairly vulnerable. It's partly based on the subject I was discussing in the previous document, buffer overflows. The same deal goes with browsing websites, and this is not the only type of attack that you might stumble upon, but it's a common one. It works the same way, someone might make a certain code in java to exploit a buffer overflow vulnerability in internet explorer for example, let's say every visitor on a specific website with a certain version of internet explorer are affected, code are loaded into the memory, and 2 seconds later you have a trojan installed, plus the maker of the website probably has your ip for future abuse. Don't panic now, it's not like every website is like this, if you keep up with the frequent explorer updates from windows update you should be a bit safer, but it's the unknown unreleased bugs/exploits you should worry about, perhaps stuff Microsoft hasn't fixed yet. Thats no news is it? Microsoft ;) I would never keep sensitive stuff on my internet computer, not in pure text anyway, you can use PGP or any other encryption method for files containing usernames/passwords if you store it on your computer that has a active internet connection. Once you have nothing (secret) on your computer you can surf without fear :) - another thing comes to mind though. If the maker of the website injects some kind of code to benefit, he could be using your machine as a "hacking portal", you'll be surprised the day you get a phonecall from FBI accusing you for hacking. Just watch out, if your computer starts going slow all of a sudden, or acting weird you should have a look at running processes, always keep track of open ports and established connections. This way you're pretty safe. There is a great Win32 utility that tells you what .exe file (application) is in charge of a specific port, basically it lists all open ports and the application using it. This tool is called fport and can be downloaded here: warindustries.com/archives.php Look in category: "security" Supports: Windows 2000, Windows NT4, Windows XP Don't even start with me about WinME/Win98, you shouldn't be using that! 1:2 Unix/Linux stuff Some utilities here, first there is a little program called chkwww, it's good to have handy, it checks a server and reports what webserver it's running. DL: warindustries/archive.php Look in category: "unix" Usage: root@r00tbox:/home/stuff/pychkwww# ./pychkwww.py SYNOPSIS: pychkwww.py [options] [HOSTS ...] Example: root@r00tbox:/home/stuff/pychkwww# ./pychkwww.py www.msn.com www.msn.com (207.68.171.245): Microsoft-IIS/5.0 --------------------------------------------------------------------------------------------------------------------------------------- Shellcode generator. You've got something to make shellcode, called (shellforge), very handy, converts C code into shellcode/asm. DL: warindustries/archive.php Look in category: "shellcode" Example: We have the hello world simple application in .c , so we do this: root@r00tbox:/home/stuff/shellforge# ./shellforge.py hello.c ** Compiling hello.c ** Tuning original assembler code ** Assembling modified asm ** Retrieving machine code ** Shellcode forged! \x55\x89\xe5\x57\x56\x53\xe8\x00\x00\x00\x00\x5b\x83\xc3\xf5\x8d\xb3\x50\x00\x00\x00\xfc\x8d\x7d\ xd8\xb9\x03\x00\x00\x00\xf3\xa5\x66\xa5\x83\xe4\xf0\xbf\x01\x00\x00\x00\x8d\x4d\xd8\xba\x0e\x00\x 00\x00\xb8\x04\x00\x00\x00\x53\x89\xfb\xcd\x80\x5b\x89\xf8\x53\xbb\x00\x00\x00\x00\xcd\x80\x5b\x8 d\x65\xf4\x5b\x5e\x5f\xc9\xc3\x48\x65\x6c\x6c\x6f\x20\x77\x6f\x72\x6c\x64\x21\x0a\x00 Simple enough :) - like I said it can save alot of time, just remember to keep track of the nulls. ;) 1:3 C ,sockets / data (linux/unix c) We're making a simple connect application, some c knowledge here would be good to understand this one. It wont get much easier than this, I think you will have a clue about what we're doing by simply reading the code. There are alot of examples like this out there, just make sure you understand the basics. Notice that there are some different socket types to use, there are stream sockets, (SOCK_STREAM) which we use in this example, and there are datagram sockets, (SOCK_DGRAM), stream is tcp and dgram is udp. Another type of socket is called RAW socket, the difference between stream/dgram sockets and raw sockets is that the protocol headers are filled in by the specific program that uses the socket instead of the kernel, this means that all the stuff the TCP/IP stack normally does for you, it won't in this case - you have todo it yourself. You don't really need to know more about raw sockets at this point. Simple socket connection with stream socket. -----------------------------------------------CODE-------------------------------------- #include #include #include #include #define TESTPORT 999 #define TARGETIP "127.0.0.1" int main () { int testsocket; struct sockaddr_in thetarget; testsocket = socket(AF_INET, SOCK_STREAM, 0); thetarget.sin_family = AF_INET; thetarget.sin_port = htons(TESTPORT); thetarget.sin_addr.s_addr = inet_addr(TARGETIP); connect(testsocket, (struct sockaddr *)&thetarget, sizeof(struct sockaddr)); perror("connect"); } ------------------------------------------------------------------------------------------------ Okay if we now compile this we should be ok, : root@r00tbox:/home/stuff# gcc test.c -o test "test" becomes the executeable file. Off to run it: root@r00tbox:/home/stuff# ./test connect: Connection refused The little piece of code itself works, but we couldn't connect to 127.0.0.1 (ourselves), on port 999 because there is no port 999 open, but if for example you tested this, made a simple server prog and then made the connect it would work. Note this code does not have much of error handling, you have to study c in order to get it 'right'. This is minimal, for what you need in order to make it work. What we did with the above code in short, we made a socket called testsocket, we choose to make it a stream socket. Finally we made it connect to our choosen ip/port which we #defined. We added a little error handling to the connect process, so that it will spit out a default message if the connect fails, like "Connection refused". I take it some of the code might be confusion to you, it's a good start to grab a c book and study a bit before beginning with socket coding, and so on. When doing buffer overflows, that I discussed in the previous document you might want to build up a large chunk of data. We can do like this: -----------------------------------------------CODE-------------------------------------- char the_buffer[1064]; int i; for( i = 0; i < 1064; i++) the_buffer[i] = 'A'; ---------------------------------------------------------------------------------------------- We fill "the buffer", with A's, 1064. If we want to use this in a socket program, for example send the data, we could do: send(testsocket, the_buffer, strlen(the_buffer), 0); And so we have connected, and sent data. This helps you recognize socket c type code in the future, and hopefully make you understand it a bit better. I can't sit here and teach you everything about c :)- you have to grab books and other tutorials for that ;) 1:4 The 4th dimension When you're trying to find new bugs and make your own code to exploit them you will fail alot, and there's almost no limit of how hard it could be to break or figure out a certain thing to progress with whatever you're constructing or trying to break. When I speak of the 4th dimension within hacking I am talking about doing 1+1. Buffer overflows does not only come in one single type or form, you don't necessarily have to exploit it in the ways we talked about. Let me talk about a bug in a ftp server application based on unix/linux. It's a buffer overflow bug, this particular bug can be exploited by making a special file, when you upload files to the ftp they are processed, just like servers do with data. If you crafted a file in a certain way, the ftp would get overflowed, so in theory here you could craft a file containing shellcode that will eventually go into the memory for execution. You have to think in all possible directions, hence the 4th dimension I call it, it's not only one way of doing things. Within each method there are millions of ways, and thats where you have todo the math (1+1). Remember that an easy way to find new found buffer overflows is to test on yourself. Let's say you're in Win32, no problem. Have you ever heard of G6/BPFTP Server or even Serv-U ftp server? You probably have, they're very common on windows. What exactly would you do if you wanted to find a buffer overflow bug/possible vulnerability in one of those applications? Think about it for one second, then continue: Hopefully you could think of something yourself, given the fact that you read the 3 first documents. One example would simply be to write a program that will connect and send well crafted packets of data, so called "intelligent" strings, containing an amount of data enough to reveal a buffer overflow. Depending of the maturity of your own hardcoded buffer overflow testers you might be surprised and come up with a bunch of interesting stuff ;-) - Don't forget to write your tools in a smart way, this is the 4th dimension aswell when it comes to constructing intelligent stuff. Instead of just trying 1024 data chunks on your server software you have to make it smarter, cause you probably wont come up with anything unless you put some effort into what you're making. I just said that so you won't get dissapointed when you really try :). Why do you want to use your own tools when there's better ones available? For one, when learning...it's a HUGE benefit to be able to craft your own stuff, it's like magic, you have to learn it to make use of it. Then when you know how it works, you can use other persons spells. This is the best way, if not the only way to learn properly. If you use stuff not made by you ALL the time you will never figure out how it really works. I will release applications with these documuments in the future, with very well made documentation so that you can learn how they're written, and understand exactly how they work. Some day you might make something similar yourself, try out new stuff, then add functions and play around with it. With the audience I am targeting, I'm really on thin ice, I have no idea how many of the readers would be ready to put enough time in to learn linux/unix c-programming, alot of people does not have the time, but I do hope for the greater good that you're one of those. If however you feel that c is not your thing at all, there's still hope. Many people choose to use alternative languages, that is a bit less time consuming, unless ofcourse you're making really advanced stuff. There's : perl , ruby, python. 3 decent languages. Perl - http://www.perl.org/ Python - http://www.python.org/ Ruby - http://www.ruby-lang.org/en/ 1:5 Brute Force Brute Force is also a very known and common method, it's not even near as good as 'real bypassing', using overflows and whatnot, but it can be useful in some cases. Brute force is a trial and error method used by programs to decrypt data, such as passwords, or any type of encryption, using (brute force) rather than intellectual strategies. Just like someone would try to pick a lock on a door using a gazillion different keys, not very efficient in most cases, but sometimes it can be a benefit. There are tons of "brute force" applications spread across the internet. Some simple types of encryption might be breakable fairly quick, but for the harder stuff it's not a rational method. 1:6 User input So far it has been 4 documents, and I have covered quite alot of ground. You should by now have a basic understanding of how tcp/ip , udp communication over network/the internet works. By knowing these things you can figure out alot on your own, like what could be a possible security risk. In version 5 I will base alot of the material on user input, anything in particular you find a bit shady? Perhaps you would like a deeper insight into a particular field? Like buffer overflows for example. I will discuss and clear things up based on what the reader (you) wants to know in part 5. Any question/suggestion for topic/content is welcome. I decided to make this in order to target the next 2 versions of Basic learning towards (frequently asked questions) from the readers, or special requested topics. We have a forum where you can post suggestions and input for topics/content for the next document: http://warindustries.com/phpBB2/viewtopic.php?t=74 Emailing is okay aswell: postmaster@warindustries.com