Privilege excalation

[H1t M0nk3y]

Once you have a shell with low privileges on a box, how do you get admin/system/root privileges?

I am looking for some advice on privilege escalation techniques on both Windows and Linux. I know it depends on a lot of factor, like remote or local, type of os, service packs, etc. But I am looking more at how to find the solution.

Also, I know that if you use the Metasploit framework, Core Impact, etc, it gets pretty easy. But I want to do it manually.

I know on Windows, we could use the at command. But what if it doesn't work?

Anyway, I have been on google for a while now and I find it difficult to find good explanations, examples, tutorials or "how to".

The only solution that I know right now is to go on milw0rm, exploit-db.com, etc, find an exploit, compile it and use it. Is there any other "tricks"?

Thanks

[hayabusa]

There are many ways, H1tM0nk3y, and I'll let others answer, too.  But often times, it's a matter of simply using the access you've already gained to find other exploitable services, etc, on the target, which you can then go after (such as services that, from the ourside, were filtered by firewall, but from local machine, are easily reachable.)

Other methods vary, from uploading and running existing exploit code, to starting up an exploitable service or program on the target, which then enables you to hook into system dll's, with escalated privileges, etc.

Edit:  I'll try to post some relevant links later (time is NOT on my side, this morning,) unless sil or others beat me to it!  

[ziggy_567]

To add to hayabusa...there's always a good chance you'll find a misconfiguration or "human mistake" you can leverage, such as private keys carelessly stored, backup shadow files/SAM databases, etc., etc.

Its not the "sexiest" way to escalate your privilege, but usually its the easiest!

[ajohnson]

Once again, it goes back to recon and information gathering. See what you can find in terms of users, hashes, running services, file contents, etc. Is the machine running any network services? If so, can you capture traffic on it? Search for scripts and batch files. I've found credentials stored in those on numerous occasions. Why waste time trying to be l33t when they have the info sitting right there for you?

[hayabusa]

Why waste time trying to be l33t when they have the info sitting right there for you?

Amen!

[MaXe]

The most used technique on Linux is:
- Look at the kernel version (uname -a) and try an exploit (from e.g. exploit-db) matching that version.

You could also try:
- Read the /etc/passwd (readable, useful to find accounts to bruteforce into) and /etc/shadow (shouldn't be readable, but you never know.)
- Exploit a vulnerable (perhaps local) service running directly as root.
- Bruteforce the root login (su or sudo)
- Try "sudo", your current user may already have sudo privileges! (You may be able to read /etc/sudoers in rare cases.)
- Look for "personal files" that may contain hints to what the password might be. (Some people write their passwords in text files on their computer.)

On Windows, there's a few modules in Metasploit that I know of which has been implemented.

I know that the VNC Injection usually drops a command prompt running as "system" too.

The Meterpreter payload is able to migrate into other processes, and migrating into a process running with higher privileges is also and usually possible where you're usually able to gain higher privileges this way too.

However on boxes with Vista, XP, 7, etc. you're usually already Admin or local Admin. If you're not, try "Pass the Hash" to gain access to other computers or devices on the network which may be a part of an AD (a domain), look for "files" or clues on these boxes too.

Well, that's mostly what you can and should do   There is of course, probably a lot more techniques.

Oh yeah, +1 to ziggy_567 and dynamik, "backups" of passwords etc. is good to look for as well, along with the default admin / admin and admin / password credentials.

Don't forget MitM attacks too if you're in a live and real network! I used that method to grab all the passwords for the mail clients in a real (IRL) scenario, however be _sure_ that you don't do any mistakes so the clients on the network won't loose their Internet or network connections.

[H1t M0nk3y]

I couldn't ask for better answers! Thanks guys!

I am still new to this field, but you guys gave me a lot of nice things to look for.

So I get your point now. I could also add:

- Configuration files (web applications with the database credentials, etc)
- Maybe browser cookies?!?

 

[ajohnson]

Oh for sure! I <3 DB connection strings.

You can then get the user hashes for whatever app they're using, and you'll occasionally find people that reuse them elsewhere. Jackpot.

[hayabusa]

You'd be suprised at JUST how much data you can get, and how frequently users re-use passwords among disparate systems.  I had a guy on a pentest recently, whose passwords for his personal accounts matched his work accounts.  So I sniffed his machine (the one I had low privileges on to begin with) traffic, and grabbed his login to his personal email.  Lo and behold, same creds worked internally, and I went a whole lot further.  It's all about search and discovery, and taking one's time in the process, so as not to stumble and be spotted in the process.

[H1t M0nk3y]

I really get your point now. I can't thank you guys enough!!!   

And as far as tools are concerned, just in Backtrack 4, there are 57 tools in the "Privilege Escalation | All" directory. But you guys already know that...

[ElCapitan]

Check out Kon-boot:

http://www.piotrbania.com/all/kon-boot/

[sil]

Alright, so things have slowed down for me enough to post a long rambling (rough week had interop testing, presentations, etc). Let's take a 50K foot view and review with what I'll call "I haz shell now what?!"

What steps did you go through to get a shell account. For those reading this, it will be a part intro, part explanation and so on. Typically the penetration tester will go through phases to access a machine. These phases include a variation of the following:

• Recon
  Enumeration of services
  Enumeration of accounts if possible
  Collection of exploits against the services (where vulnerable)
  etc., etc

When you set out to test the security of this machine from a penetration tester's point of view, you at some point had to run some form of "mapping" software to determine what services were running on the machine in order to circumvent slash exploit one to work your way in. You've made your way in but have determined, it's not where you need to be. You need to escalate for one reason or another.

Sidetrack: In most cases, getting in is enough period (believe it or not) and anyone who tells you otherwise is off their rockers. Analogy time: Imagine coming home from dinner one day to find your apartment was burglarized. Nothing was stolen, but someone ransacked through all your belongings. Do you sit there and say: "So what! Nothing was taken, no harm no foul." Highly doubtful. There is the entire concept of someone going through your personal belongings. Not to mention the fact of insecurity you will feel. "Will they come back again", "will they clean me out next time" and so on.

Forwardtrack: So you've managed to get access... How did you get access again? Through a process. You now need to go through that same process using a different approach. The procedures are the same:

• Recon
  Enumeration of services
  Enumeration of accounts if possible
  Collection of exploits against the system you're on

On *nix

Where am I first of all

Code:

gary7:~$ pwd
/home/mail

Who am I and what groups am I in?

Code:

gary7:~$ id
uid=8(mail) gid=8(mail) groups=8(mail)

I can't read shadow, maybe I can find an account I can escalate to

Code:

gary7:~$ more /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:11:11:proxy:/bin:/bin/sh
backup:x:12:12:backup:/var/backups:/bin/sh
Debian-exim:x:100:102::/var/spool/exim4:/bin/false
statd:x:101:65534::/var/lib/nfs:/bin/false
identd:x:102:65534::/var/run/identd:/bin/false
sshd:x:103:65534::/var/run/sshd:/usr/sbin/nologin
postfix:x:107:107::/var/spool/postfix:/bin/false
snort:x:108:109:Snort IDS:/var/log/snort:/bin/false
ossec:x:1003:1003::/var/ossec:/bin/false
mysql:x:110:111:MySQL Server,,,:/var/lib/mysql:/bin/false
ntop:x:111:112::/var/lib/ntop:/bin/false
nagios:x:112:113::/var/log/nagios:/bin/false
arpwatch:x:113:114:ARP Watcher,,,:/var/lib/arpwatch:/bin/sh
osirismd:x:114:115:Osiris management daemon,,,:/var/lib/osirismd:/bin/false
postgres:x:1000:1000:,,,:/home/postgres:/bin/bash

In some cases, this file could be really large especially in an enterprise. Let's see only accounts worth seeing (get rid of nologin and false):

Code:

gary7:~$ awk '!/false|nologin/{print}' /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:11:11:proxy:/bin:/bin/sh
backup:x:12:12:backup:/var/backups:/bin/sh
arpwatch:x:113:114:ARP Watcher,,,:/var/lib/arpwatch:/bin/sh
postgres:x:1000:1000:,,,:/home/postgres:/bin/bash

I see there are mechanisms/programs in place to potentially see/monitor what is going on (snort, ossec, osiris, arpwatch, nagios). Better play it safe and keep things silent (non-noisy as snort will see it) man sleep Meaning, if I need to do something network related, I want to keep my intervals high to avoid tripping IPS/IDS alarms. If an interval command is not available, I'll use sleep for N amount of seconds, e.g.:

HEAD 10.20.30.2 ; sleep 180 ; nextCommand

Anyhow, Let me see what other networks I'm on...

Code:

gary7:~$ /sbin/ifconfig
eth0      Link encap:Ethernet  HWaddr 00:14:22:0F:BE:EF
          inet addr:208.47.125.33  Bcast:208.47.125.255 Mask:255.255.255.0
          inet6 addr: fe80::214:22ff:fe0f:8019/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:530490559 errors:45 dropped:5036 overruns:0 frame:23
          TX packets:849641363 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3489730358 (3.2 GiB)  TX bytes:2252362147 (2.0 GiB)
          Base address:0xdcc0 Memory:dfbe0000-dfc00000

eth1      Link encap:Ethernet  HWaddr 00:14:22:0F:BA:BE
          inet addr:10.20.30.40  Bcast:10.20.30.255  Mask:255.255.255.0
          inet6 addr: fe80::214:22ff:fe0f:801a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:313524793 errors:35 dropped:119137 overruns:0 frame:17
          TX packets:257953444 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2316259519 (2.1 GiB)  TX bytes:49064241 (46.7 MiB)
          Base address:0xccc0 Memory:df9e0000-dfa00000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:105669960 errors:0 dropped:0 overruns:0 frame:0
          TX packets:105669960 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:632006627 (602.7 MiB)  TX bytes:632006627 (602.7 MiB)

Now that I see a private address, let's see what is visible on the private side. Forget nmap since it may NOT be on the machine and there is no way in hell I'm setting off alarms. Hello good old faithful netcat, I need you as a scanner today. You come preinstalled on just about everything nowadays:

Code:

gary7:~$ nc -v -z 10.20.30.40 1-20000
gary7 [10.20.30.40] 5038 (?) open
gary7 [10.20.30.40] 3128 (?) open
gary7 [10.20.30.40] 3000 (?) open
gary7 [10.20.30.40] 2266 (?) open
gary7 [10.20.30.40] 113 (auth) open
gary7 [10.20.30.40] 80 (www) open
gary7 [10.20.30.40] 25 (smtp) open
gary7 [10.20.30.40] 22 (ssh) open

Strange, these weren't visible to me from the outside world when I ran nmap. Let me keep note, find a potential matching program and see if I can find any potential working exploits against these services....

Code:

gary7:~$ nc -v 10.20.30.40 5038 -q 1
gary7 [10.20.30.40] 5038 (?) open
Asterisk Call Manager/1.0

gary7:~$

I can go Google exploits against this later. Right now, just jotting down what's visible slash accessible to me. Get the picture? It pays to understand systems from a systems administrator perspective otherwise one will always ask the question: "I haz shell now what?" Hopefully this made sense to those who've been asking themselves that same question. The remainder is sort of elementary. Much similar to gathering data from the outside view, gather it now from the inside view. This could mean finding services, finding an account with better privileges (more /etc/group), finding any errors with file permissions. Finding any potential TOCTOU issues and so on.

It's good practice to build a "dossier" of the system your own instead of trying to hack it wildly. The time you spend doing so (hacking wildly) could lead to you being detected and or kicked/blocked off the system rendering your test moot (to a degree... After all you did get in). Practice, patience and understanding allow you to go far. I can't stress it enough, one needs to truly understand a system from even a junior admin level as it makes things easier and allows one to streamline processes to make things quicker, more effective and more stealthy sometimes.

For anyone with an OMFG on this in regards to gary7, take note, I replaced my system information with gary7. I wouldn't go fiddling with that machine if I were you. (No really I wouldn't)

[former33t]

So this won't work every time, but you need to rescan the box for vulnerable servies from the unprivileged shell.  Especially for legacy services, you may note that a favorite vendor "fix" is to tell you to firewall the service so it can't be hit from outside.  If you got on the machine, you are now on the trusted network... whack away!

On *nix don't forget to look at cron jobs, shell scripts, and setuid binaries that shouldn't be.  If you have limited sudo, try things like ed, vi, cat, cp.  All those can be used to repalce co figs and give you root.

 Last, remember that you don't have to be root to get valuable information.  If on a db server, I really want the db, mail server == mail...

[hayabusa]

Last, remember that you don't have to be root to get valuable information.  If on a db server, I really want the db, mail server == mail...

sil and former33t went further for you on where I was leading.  End point is, exactly as former33t put it in the quote above...  Ultimately, at the end of the day, the point is showing what you can get to, and as he said, if it's a mail server, and you can snarf all the mail, you've successfully achieved the goal.  Now on to the next box, and the next, and the next.  (Although, if you're wily enough to gain privileged shells, and enumerate usernames and passwords for OTHER machines on the same network, then you've made life all that much easier to continue.

Good luck!

[H1t M0nk3y]

Great post sil, thanks!!!

Of course proving you were able to steal valuable information is enough for a pentest. I guess I would only go further if I know I can get to even more sensible information by being root/admin/system, like having access to credit card numbers instead of "just" reading mail. As long as you can scare your clients, you know/hope they will fix their things.

But once you have a shell, you have access to a whole new world. And me, still beginner in the field, will see many moons before I feel confortable elevating privileges on a box... I will practice these techniques a lot in the lab.