Cry for help on RHL 9

[ksecurity]

Howdy Hak5 folks..

Well, I'm expected some "try harders" and other such encouragement :)..I'm at the very tail end of the CPT exam. If anyone is unsure of it, first part is multi-choice (aced it!) ..second is compromising two VM's..got first in minutes happy to say..the second one......here is where I'm losing my hair very quickly.

The objective is root password on both vm;s...this second one is where I seem to be hitting a dead end, and this is the first reaching out for help attempt. Basically, from what I can gather, this particular vm needs to be compromised via a local exploit be it privy escalation, shellcode yadda yadda..I have tried (I think) most methods that I can figure out (at my level at least) and just getting killed with each attempt.

Not looking for someone to spell it out for me, after all I've been at this VM for 2 weeks now before asking for some guidance. So I'm happy to start a dialogue with anyone interested to help. I'll spill some of the VM details here and if someone is kind enough to brainstorm with me, it would be much appreciated.

Cheers

VM Info:

• Red Hat Linux 9 (Shrike)
• Kernel 2.4.20-8
• i686 athlon i386 (bear in mind this is on a VMWare Workstation, host is AMD chip fyi)
• gcc 3.2.2
• 2 non-root accounts have been acquired, no sudo privileges, long story short, these accounts can't do squat
• The accounts allow direct (local) access on the vm, or via ssh etc. from attack VM
• Tried out about 12 known exploits (mainly exploit-db et.al) for OS version and kernel
• The discovered services have some minor-medium level vulnerabilities, but none from what I can tell help to getting to root/shadow file.
• FYI, for the exploits tried, (I'm a sooper noob with shellcode, but learning fast and taking ANOTHER course fml) some backfired entirely, some compiled but failed to run, some compiled ran but seg-faulted etc etc, so they may work and I'm just inexperienced at compiling or altering them appropriately
• I've done some local enumeration of possible config, suid etc etc flaws but cant really determine an approach

Think that about does it for a 'where I'm at'...like I said, I actually dont really want the "Here's how.." but some discussion or tips would really be appreciated. Just kinda fried and probably overthinking but having trouble getting focused and feel kinda burnt as far as ideas go.

[digininja]

I just googled "2.4.20-8 vulnerability" and it came back with a local privilege escalation as the first result. A look in Exploit DB shows two exploits.

I'd guess that that is the way in.

[ksecurity]

@digininja Thanks for the reply. I have grabbed every potential privy code I could find related to this system. I mentioned in the opening post that I could just be having compiling issues so I'm not giving up on that just yet, but I appreciate the input nonetheless!

[digininja]

That kernel is a well known vulnerable one so I'd go with it being that and you doing something wrong building or using them.

Are the VMs remote or do you have them locally? Would be very easy to get root if you have them local.

And how do you plan to get the root password once you have root access? You would still need to crack the shadow file unless they leave the password lying around in a text file. If it is crackable then you might be better brute forcing it from the start.

[ksecurity]

It is well known indeed. The VM's are local. I debated imaging the vmdk and mounting in another vm, but not really the point of the exercise. As for actually obtaining the root password, yes the objective is to grab the shadow and crack offline. I have a feeling they aren't exactly complex and brute forcing is on the backburner. They objectives outline says, although not necessary that by using the standard account credentials obtained from the first VM, which work on this one, should be used to somehow exploit locally as a logged in user. However doesn't have to be i.e. brute force.

I'm taking a stab at debugging the mremap exploit (if that was the one you were referring to)..its compling but segfaulting so trying to isolate where, maybe non executable stack or something. But yes, I have local access, local standard account creds, if I can grab the shadow, extremely confident in cracking the hashes. But open to suggestions.

[ksecurity]

Gonna add also, as for the exploits, I've been building a few ways and testing them all..I have another RHL9 VM unrelated to the course that I'm compiling on. Been doing things like : # gcc code.c (just to get an a.out) , # gcc code.c -o code (standard) , static flag now and then....think thats it.

[digininja]

It won't be DEP that is causing your problems as DEP wasn't introduced to Linux till 2.6.8 ( http://en.wikipedia.org/wiki/Data_Execution_Prevention ).

Why are you building on a different machine? As the target has gcc on it build on there that way you are building against its config not something that might be similar.

[ksecurity]

I usually run a similar machine so as to test ideas and what not while having full control. Good point about the DEP though, without looking in to it I assumed the SIGSEV could be caused by it, but chances are just exhaustion or incorrect addressing. Gotta figure out what I'm doing wrong with the exploit code

[ksecurity]

AHA!!! Got it..Funny how one thought can trigger another...your DEP comment made me think outside the box (like I should have been doing)..anyways, long story short..got the shadow..really appreciate the dialogue digininja, it helped

[ksecurity]

and cracked

[Foxtrot]

... What did you do in the end?

[ksecurity]

@Foxtrot well, don't mean to be rude but I'm not going to go into specifics just in case anyone other ppl stumble in with CPT issues, but essentially when exploits that should work given the kernel versions were sigsev'n on me ,I was gonna go through the backtrace in gdb and fix the likely memory addressing issues, instead I went with a combo approach. Worked a suid vulnerability with execv() code that helped trigger root owned executables. Chances are that this was a long way around a shorter issue, but hey it worked.

[B-17]

I know next to nothing about coding. Was your eventual success able to be accomplished with vulnerabilities found in the wild, or did you still have to do some code manipulation to get them to work?

[ksecurity]

@ B-17 :

Hey,

Was a bit of manipulation. I've moved on a looong way since the CPT to knock out the OSCP and OSCE (<--- insanely difficult). Wished I had done more in-depth practice before hand. Basically when it comes to pentesting certs, I prefer anything that has hands-on testing like breaching simulated networks. So obviously these virtual networks are designed with flaws that will work. Finding the flaws is only part one. My background in security really just came from being a network engineer and I never really had the need to dig into exploit development and reverse engineering, assembly etc etc. Abusing network protocols though, no sweat ;)

In my case, it was the fact that I despise point-and-click hacking. Even if it's allowed, I will learn absolutely nothing from doing so. What happened was the exploit that was disclosed against the particular target (in this case the version of the linux kernel) wasn't so much a download, chmod and go. I needed to look into the exploit (which is always a best practice as some people pack in shellcode for example into exploits that actually hurt you instead of your target) and tweak it to my needs.

If you're in lack about coding, programming, scripting etc etc., but are interested in hacking/pentesting, getting even a little under your belt is a massive help. Check out pentester academy from security tube (it's run by Vivek so you're in good hands, and I never endorse anyone lol). He wrote amazing crash courses on assembly, python for pentesters, and a few others that are just excellent starting points. Corelan Team are just awesome guys for exploit dev and understanding it. Shellcoders handbook is a bit heavy but worth having on the shelf (same with art of exploitation).

Happy to make suggestions or answer anything else!

cheers

[B-17]

Coming into this from a non-computer background I think I just jumped into the deep end of the pool :) I have to say that if nothing else the CEH has been a great way for teaching me how to teach myself (or at least use the internet more effectively). Ironically, after venting my frustration I was successful using a different methodology. As you said before, sometimes one thought can trigger another. I really appreciate the coding advice though. I think there is a lot of ground for me to cover before I dive into another cert.

[ksecurity]

Ahh gotcha..In that case, the CEH is a great place to dive in and learn about this side of the fence. My only beef with the CEH is that it gets too much praise or I should say misinterpretation as something that teaches how to pentest/ethical hacking. I mean ya you can apply the knowledge from it, but man, the OSCP and up are just pure 100% can you do it or not. At the same time it depends how people study for the CEH. If it's just textbook stuff then meh, but I know some places offer a mix of hands on and text based like CBT nuggets and InfoSec Institute. I think the cert scene is getting a little watered down and not really delivering, at least in terms of pentesting and offensive security. When I got my CISSP I was still under the impression that you had to be vouched for, turns out that's a myth that used to be true and all the old timer CISSP's are pissed about it. The certification body wants more people to have it and inevitably have to pay for it which takes away some of it's cred.

I think what Vivek is doing with pentester academy is just fantastic for people. It's dirt cheap, he's extremely respected and really gets you going. Offensive Security on the other hand really are my only trainers that I truly revere. When I meet someone else with a OSCP or OSCE and up, you just have to by them a beer because of the sheer hell they went through passing those exams. There's a lot of debate between CEH and OSCP etc., but in my book, if I wanted someone on staff whoe should really know about security from the attackers perspective and some legal/management elements dealing with security but they will never really do any security work, then CEH on their resume is good. On the other hand, if I needed someone on our red team I would give the CEH no credit, but anything like CTF badges or OSCP+ etc, definitely a consideration.

Really depends what you're going after. We have kind of a wacky company in that we do a lot of lectures and training, even helping out smb's with networking and management, and we're all out of our minds ;) but in the end I have to chalk up doing great jobs for all the hands on over the years. It's like Cisco training, videos and reading are great, but when I wanted to start down the CCNA/CCENT path I had to get some hardware and practice on that. Although GNS3 these days is pretty amazing.

Ever wanna talk shop just drop me a msg!

[saaj7735]

@Ksecurity, I know this is an old post but I'm exactly where you were when you made your original post. I aware of what a sigsegv and segfault are however I lack sufficient knowledge to modify the exploits to suit the RHL 9 VM. I've gathered quite a bit of information to use for privilege escalation to no avail. Any hints you could give in the right direction would be awesome.

[cooper]

I'm guessing that the public 'exploit code' has a deliberate flaw in it to chase away the skiddies. So try to figure out if the flaw is in the shellcode itself, or in the code leading up to the flaw. Just ad a number of printf's in there. Once you know where the flaw is, you can work on fixing it.

[ElliotHohenhiem]

Hey guys, I'm new to the hacking scene, been doing small tests like using metasploit, imbedding meterpreter sessions and ssh'ing into machines for fun. But I've recently focused on Wi-Fi hacking, and been having alot of fun with it. But however, I've come across this one hash that does not want to go down. No matter how many wordlists I throw at it, not matter how many different combination rules I throw at it, this hash REFUSES to bite the bullet and just give in. So, like any responsible penetration tester, I've decided to turn to the group's forum that got me interested in hacking in the first place. If you want, I can send you the fourway and you can give it a shot see if you have better luck at it.

[cooper]

Please make a new topic for that instead of hijacking this thread.

[saaj7735]

@Cooper, Thanks for the tip, I'm still havimg trouble understanding what to do next here so I think its time I take a step back and regroup. I'm going to spend some time looking at the videos from pentestacademy. I think its my lack of understanding of shellcoding/exploit writing that is causing me some issues here. I've only taken a CEH class from the infosec institute which mainly focused on basics of hacking and using Metasploit. If something in those videos jump out at me and I solve my issue I will let you know.

[Crustymonkey]

I know this is a year old but I need some help on this. I am at the same point as the OP but hit the wall.

[digininja]

Rather than resurecting an old thread why not create a new one saying exactly what you've tried and what you need. There were quite a few answers, if you've tried those then say, if you've not then try them.

[ekoston9]

This has helped others from what i am told.........................................

1. Go to Securitytube.com take the "Assembly Mega Primer" https://youtu.be/K0g-twyhmQ4. Also, take the "Buffer Over Flow Primer". If some of the vids are missing just search youtube and someone else will offer it. Great code examples/structure............

2. Your going to have to fix code, sorry....Code is sabotaged to keep noobs from going crazy with exploits. ( This is where security tube will help out along with other sources.)

3. Code depending on what your using and how it is written MAY need to be ran multiple times.

4. Learn about stack and kernel protections (how to turn them off).... gcc proctections.... compiling -switches and the difference between compiling on one machine versus compiling on another machine......

5. Shell storm/exploitdb/IRC rooms are all places to get code.

6. It is always best to replicate your target so you can experiment with it to help develope your approach and attack method. I would not practice robbing a bank at the bank i am going to rob, get the ISO's.

7. Its time to realize shit just got serious. Yes, dont take short cuts, going back and forth from Armitage to meta are not going to save you ( NO script Kiddie bullshit).

8. Google is your friend

All the things mentioned above should break you out of the loop. I hope this helps somebody out there. I will try and watch my messages if you want to message me.