This tutorial will be broken down into 3 main sections, they are as followed:
1. Finding Vuln Hosts.
2. Getting In.
3. Covering Your Tracks
It really is easy, and I will show you how easy it is.
1. Finding Vuln Hosts
This section needs to be further broken down into two catigories of script kiddies: ones who scan the net for a host that is vuln to a certain exploit and ones who search a certain site for any exploit. The ones you see on alldas are the first kind, they scan thousands of sites for a specific exploit. They do not care who they hack, anyone will do. They have no set target and not much of a purpose. In my opinion these people should either have a cause behind what they are doing, ie. "I make sure people keep up to date with security, I am a messanger" or "I am spreading a political message, I use defacments to get media attention". People who deface to get famous or to show off their skills need to grow up and relize there is a better way of going about this (not that I support the ones with other reasons ether). Anyways, the two kinds and what you need to know about them:
Scanning Script Kiddie: You need to know what signs of the hole are, is it a service? A certain OS? A CGI file? How can you tell if they are vuln? What version(s) are vuln? You need to know how to search the net to find targets which are running whatever is vuln. Use altavista.com or google.com for web based exploits. Using a script to scan ip ranges for a certain port that runs the vuln service. Or using netcraft.com to find out what kind of server they are running and what extras it runs (frontpage, php, etc..) nmap and other port scanners allow quick scans of thousands of ips for open ports. This is a favorate technique of those guys you see with mass hacks on alldas.
Targetted Site Script Kiddie: More respectable then the script kiddies who hack any old site. The main step here is gathering as much information about a site as possible. Find out what OS they run at netcraft or by using: telnet www.site.com 80 then GET / HTTP/1.1 Find out what services they run by doing a port scan. Find out the specifics on the services by telnetting to them. Find any cgi script, or other files which could allow access to the server if exploited by checking /cgi /cgi-bin and browsing around the site (remember to index browse)
Wasn't so hard to get the info was it? It may take awhile, but go through the site slowly and get all the information you can.
2. Getting In
Now that we got the info on the site we can find the exploit(s) we can use to get access. If you were a scanning script kiddie you would know the exploit ahead of time. A couple of great places to look for exploits are Security Focus and packetstorm. Once you get the exploit check and make sure that the exploit is for the same version as the service, OS, script, etc.. Exploits mainly come in two languages, the most used are C and perl. Perl scripts will end in .pl or .cgi, while C will end in .c To compile a C file (on *nix systems) do gcc -o exploit12 file.c then: ./exploit12 For perl just do: chmod 700 file.pl (not really needed) then: perl file.pl. If it is not a script it might be a very simple exploit, or just a theory of a possible exploit. Just do alittle research into how to use it. Another thing you need to check is weither the exploit is remote or local. If it is local you must have an account or physical access to the computer. If it is remote you can do it over a network (internet).
Don't go compiling exploits just yet, there is one more important thing you need to know
3. Covering Your Tracks
So by now you have gotten the info on the host inorder to find an exploit that will allow you to get access. So why not do it? The problem with covering your tracks isn't that it is hard, rather that it is unpredictable. just because you killed the sys logging doesn't mean that they don't have another logger or IDS running somewhere else. (even on another box). Since most script kiddies don't know the skill of the admin they are targetting they have no way of knowing if they have additional loggers or what. Instead the script kiddie makes it very hard (next to impossible) for the admin to track them down. Many use a stolden or second isp account to begin with, so even if they get tracked they won't get caught. If you don't have the luxery of this then you MUST use multiple wingates, shell accounts, or trojans to bounce off of. Linking them together will make it very hard for someone to track you down. Logs on the wingates and shells will most likely be erased after like 2-7 days. That is if logs are kept at all. It is hard enough to even get ahold of one admin in a week, let alone further tracking the script kiddie down to the next wingate or shell and then getting ahold of that admin all before the logs of any are erased. And it is rare for an admin to even notice an attack, even a smaller percent will actively pursue the attacker at all and will just secure their box and forget it ever happend. For the sake of arugment lets just say if you use wingates and shells, don't do anything to piss the admin off too much (which will get them to call authoritizes or try to track you down) and you deleting logs you will be safe. So how do you do it?
We will keep this very short and too the point, so we'll need to get a few wingates. Wingates by nature tend to change IPs or shutdown all the time, so you need an updated list or program to scan the net for them. You can get a list of wingates that is well updated at http://www.cyberarmy.../lists/wingate/ and you can also get a program called winscan there. Now lets say we have 3 wingates:
212.96.195.33 port 23
202.134.244.215 port 1080
203.87.131.9 port 23
to use them we go to telnet and connect to them on port 23. we should get a responce like this:
CSM Proxy Server >
to connect to the next wingate we just type in it's iport
CSM Proxy Server >202.134.244.215:1080
If you get an error it is most likely to be that the proxy you are trying to connect to isn't up, or that you need to login to the proxy. If all goes well you will get the 3 chained together and have a shell account you are able to connect to. Once you are in your shell account you can link shells together by:
[j00@server j00]$ ssh 212.23.53.74
You can get free shells to work with until you get some hacked shells, here is a list of free shell accounts. And please remember to sign up with false information and from a wingate if possible.
SDF (freeshell.org) - http://sdf.lonestar.org
GREX (cyberspace.org) - http://www.grex.org
NYX - http://www.nxy.net
ShellYeah - http://www.shellyeah.org
HOBBITON.org - http://www.hobbiton.org
FreeShells - http://www.freeshells.net
DucTape - http://www.ductape.net
Free.Net.Pl (Polish server) - http://www.free.net.pl
XOX.pl (Polish server) - http://www.xox.pl
IProtection - http://www.iprotection.com
CORONUS - http://www.coronus.com
ODD.org - http://www.odd.org
MARMOSET - http://www.marmoset.net
flame.org - http://www.flame.org
freeshells - http://freeshells.net.pk
LinuxShell - http://www.linuxshell.org
takiweb - http://www.takiweb.com
FreePort - http://freeport.xenos.net
BSDSHELL - http://free.bsdshell.net
ROOTshell.be - http://www.rootshell.be
shellasylum.com - http://www.shellasylum.com
Daforest - http://www.daforest.org
FreedomShell.com - http://www.freedomshell.com
LuxAdmin - http://www.luxadmin.org
shellweb - http://shellweb.net
blekko - http://blekko.net
once you get on your last shell you can compile the exploit, and you should be safe from being tracked. But lets be even more sure and delete the evidence that we were there.
Alright, there are a few things on the server side that all script kiddies need to be aware of. Mostly these are logs that you must delete or edit. The real script kiddies might even use a rootkit to automaticly delete the logs. Although lets assume you aren't that lame. There are two main logging daemons which I will cover, klogd which is the kernel logs, and syslogd which is the system logs. First step is to kill the daemons so they don't log anymore of your actions.
[root@hacked root]# ps -def | grep syslogd
[root@hacked root]# kill -9 pid_of_syslogd
in the first line we are finding the pid of the syslogd, in the second we are killing the daemon. You can also use /etc/syslog.pid to find the pid of syslogd.
[root@hacked root]# ps -def | grep klogd
[root@hacked root]# kill -9 pid_of_klogd
Same thing happening here with klogd as we did with syslogd.
now that killed the default loggers the script kiddie needs to delete themself from the logs. To find where syslogd puts it's logs check the /etc/syslog.conf file. Of course if you don't care if the admin knows you were there you can delete the logs completely. Lets say you are the lamest of the script kiddies, a defacer, the admin would know that the box has been comprimised since the website was defaced. So there is no point in appending the logs, they would just delete them. The reason we are appending them is so that the admin will not even know a break in has accurd. I'll go over the main reasons people break into a box:
To deface the website. - this is really lame, since it has no point and just damages the system.
To sniff for other network passwords. - there are programs which allow you to sniff other passwords sent from and to the box. If this box is on an ethernet network then you can even sniff packets (which contain passwords) that are destine to any box in that segment.
To mount a DDoS attack. - another lame reason, the admin has a high chance of noticing that you comprimised him once you start sending hundreds of MBs through his connection.
To mount another attack on a box. - this and sniffing is the most commonly used, not lame, reason for exploiting something. Since you now how a rootshell you can mount your attack from this box instead of those crappy freeshells. And you now have control over the logging of the shell.
No comments:
Post a Comment