Thursday

How Servers are Hacked by hackers

How are servers hacked? Its an age old question passed around by the
people who have never done this before. The hacking of servers isnt
easy, to some people it is, and to some people the script kiddies
and the newbies prehaps would think its hard due to the fact that
they dont know anything about it. Lets get started on this tutorial.

When planning to hack a server, you need to use your intelligence.
Gathering information is a key factor to this task. Why must you
gather information? Because information is always needed especially
when its server information. But what type of information on the
server is needed? Well lets take a look deeper inside.

There a various ways of gathering information on servers such as
Banner Grabbing. For those who dont know wat a banner is, it is
the message echoed back to a remote connector to a server. For
an example of a banner grabbing situation read below:

telnet www.server.com 80 (hit enter) (hit enter)

HTTP/1.1 200 OK
Date: Thu, 17 Jul 2003 17:00:51 GMT
Server: Apache/1.3.27 (Unix) mod_log_bytes/1.2 mod_bwlimited/1.0 PHP/4.3.3RC2-dev FrontPage/5.0.2.2634 mod_ssl/2.8.14 OpenSSL/0.9.6b
X-Powered-By: PHP/4.3.3RC2-dev
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

The example above was me using telnet to connect to a remote
server on port 80 (HTTP) to get the HTTPD banner of the server.
But what does this tell us? This can tell us a lot such as...

- the server runs apache 1.3.27
- the server runs linux
- the server runs php 4.3.3 RC2-dev
- the server runs frontpage 5.0.2.2
- the server runs OpenSSL 0.9.6b
- the server uses chunked transfer-encoding

Well this is alot. but some are asking, it says unix though,
how do you know theyre running linux? Well this is where the
intelligence comes in, not everyone would take the guess of
stating the remote operating system of the server without the
use of a fingerprinting tool, but grabbing the http banner
kinda gives it away. If it says Unix, majority of the time its
some sort of Linux distro, which one? it does say so you dont
know, sometimes when i would attack a server that only said
linux and did id;uname -a in their shell, it would say GNU
Linux, but that was only one server. Most other servers will
say their operating system in the HTTP banner, such as Linux-RedHat
so right there you would see it was redhat linux.

Other questions such as "Where do people find the exploits
to hack these servers??" can also be answered. Majority of
people will visit security sites and exploit websites to find
these exploits either because they themselves dont know how to
code, or they dont have any "connections" or friends with
the newest exploits aka 0day's.

How else do people find exploits... Well lets take a look
even deeper in how this is done. Say for example you want
to attack some server thats running FreeBSD, you know theyre
running it because you used some fingerprinting tool or a
remote operating system detector and know it. Yet you want
to find some sort of way you could exploit something on this
server, how would you do this? A lot of people can usually
easily do this, How? Well what many script kiddies and newbies
dont do that the real hackers do is actually Read advisories
first rather than go straight for the exploits thinking that
they can just hack about anything. Why are advisories important
though... they dont show you how to exploit. Yes, thats true
but your ahead of the game seeing what exploits plan on coming.
The advisories are always there before the exploits unless
some coder apparently finds this exploit first making it the
0day he'll give to few people being invisible to the world.
But... reading an advisory, how does this help at all. Lets
say for example your on packetstormsecurity.nl, you made the
choice to look over the top 10 advisories rather than the top
10 exploits, you notice theres one advisory for FreeBSD, you
take a look at it. Remember... you dont know what version of
FreeBSD this server is running... If you do then thats great
but lets continue on as if you didnt know, But you can still
tell what version of FreeBSD they would be running if you look
at their server statistics for example heres some code from
a FreeBSD exploit:

} targets[] = {
{ "Just Crash Remote Apache Server / 0x41414141", },
{ "FreeBSD 4.0 x86 / Apache 1.3.14 / 0xbfbfdc00", },
{ "FreeBSD 4.0 x86 / Apache 1.3.9 / 0xbfbfde00", },
{ "FreeBSD 4.1 x86 / Apache 1.3.20 / 0xbfbfc000", },
{ "FreeBSD 4.1 x86 / Apache 1.3.22 / 0xbfbfc000", },
{ "FreeBSD 4.2 x86 / Apache 1.3.19 / 0xbfbfdc00", },
{ "FreeBSD 4.2 x86 / Apache 1.3.14 / 0xbfbfda00", },
{ "FreeBSD 4.2 x86 / Apache 1.3.17 / 0xbfbfdc00", },
{ "FreeBSD 4.3 x86 / Apache 1.3.19 / 0xbfbfda00", },
{ "FreeBSD 4.4 x86 / Apache 1.3.12 / 0xbfbfdc00", },
{ "FreeBSD 4.4 x86 / Apache 1.3.22 / 0xbfbfdc00", },
{ "FreeBSD 4.4 x86 / Apache 1.3.26 / 0xbfbfdc00", },
{ "FreeBSD 4.4 x86 / Apache 1.3.20 / 0xbfbfd800", },
{ "FreeBSD 4.4 x86 / Apache 1.3.24 / 0xbfbfda00", },
{ "FreeBSD 4.5 x86 / Apache/1.3.23 (Unix) / 0x80f3a00", },
{ "FreeBSD 4.5 x86 / Apache/1.3.23 (Unix) / 0x80a7975", },
{ "FreeBSD 4.5 x86 / Apache 1.3.19 / 0xbfbfde00", },
{ "FreeBSD 4.5 x86 / Apache 1.3.23 / 0xbfbfda00", },
{ "FreeBSD 4.5 x86 / Apache 1.3.24 / 0xbfbfd200", },
{ "FreeBSD 4.6 x86 / Apache 1.3.19 / 0xbfbfda00", },

What does this tell us? Well lets see... If you do a banner
grab on the FreeBSD server to get the http banner, you'll
see for an example Server: Apache 1.3.24. How would that help?
Take a look at the exploit code for all the FreeBSD versions
with Apache 1.3.24, you will notice that only two of them have
its, FreeBSD 4.4 and FreeBSD 4.5. Apparently you would say
to yourself its either, most likely the newer version, but
this method isnt always right, a hacker isnt always right, its
learning from your mistakes that make you wiser, testing and
testing over and over again, and luck has nothing to do with it.
Anyway back to advisories... You notice that you see an advisory
for FreeBSD, you look deeper into the advisory and notice that
FreeBSD 4.4 systems are affected to say for example a CVS exploit
that you can cause a buffer overflow in giving write access and
possible remote command execution, Now remember, its just an
advisory, But how can you impliment it? Theres the part where
many people get stuck, thats why its best when you code your own
exploits. Right here is the part where im sure i shouldnt go on
because its the part where a lot of people get stuck but i will
say this, Hackers or Coders would impliment this advisory by
creating a 0day or just an exploit that happens to create the
buffer overflow and i dunno, probably bind shell or port and let
you in or just remote command execution. Thats why nowadays its
a good thing to start learning to code c and c++, and even perl.
Learn shellcode, learn to understand what shellcode is, and how
to create your first exploit, and understand what all the commands
are telling the server to do for a further understanding of
even how every other exploit works and their process to give people
access, learning is a key in hacking.

0 comments: