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!

@ 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

Hey Catesby, A popular option (if available to you) is to install kali on your attack server, ssh right into it, bob's your uncle. Some fun stuff you can do with netcat (or even ncat with --allow and --ssl flags) to forward or reverse the shell of the attack server right to your laptop. Might make the routing easier on you if you move the attacking OS onto the server. Can still keep kali on the laptop.

Dear Hak5ers, Apologies if this has been discussed, I only went a few pages in to see. So what I'm goofing with is the whole isolation proxy thing, using whonix-gateway in a VM (couldn't build successfully on my extra physical box). I followed the basic guide provided by them just to get er up and running. I'm a vmware man myself, but some extra work involved so went with the suggest virtualbox. So the guide suggest the following (actually a mix of two) vm #1 - the Whonix gateway. It has 2 NIC's : one is NAT so we can reach out on the net to TOR, second is an internal (called whonix) running on 192.168.0.10 by default vm#2 - kali (not whonix-workstation) with one NIC (the internal one called whonix) running on 192.168.0.20 So what's my beef? Well, a lot works in terms of tunneling everything through the whonix gateway, which is essentially the goold ole' "how to route everything through tor" debate. But the one item I'm trying to tinker with is getting metasploit to behave. Which it doesn't by default. What happens is (bear in mind this is through Armitage) regardless of the IP(s) you enter for testing, they all A) basically say every bloody port is open, and B) just to get things moving, I used a known vulnerable VM to see how exploits got handled in all this routing. Well, not to smooth. Basically they EOF over and over, so you'll see the box pop (turn red and lightning) then just die (End of File). Before I start pulling hair and messing with routing tables, and most importantly, mucking the whonix gateway which I shouldn't really touch to mouch, wanted to run this scenario buy you guys. See if anyone has tried this out, worked/not worked etc etc. Would love to work this one out with some discussion. Thoughts?

Hey guys, So the question I have is regarding pivots and what I'm assuming is going to come down to the 'route add' command on kali. Here's the scenario: Attack machine = 192.168.14.110 (which is assigned through tap0 from a vpn connection) Also, the vpn connection above, automatically attaches me to a 192.168.15.* network Target network 1 = 192.168.15.* range mentioned above. Target network 2= 10.1.1.* One of the machine on target network 1 has been compromised and i've pivoted through metasploit to launch new attacks at target network 2, because this compromised machine is attached to target network 2. So that's not a problem. What I'm trying to figure out, is how to route everything through this pivot, outside of metasploit. With the MSF pivot, I can only use whats inside metasploit, as I'd like to be able to recon this new network using general means. I tried a couple route add commands, but I'm definitely not doing it right. Any help would be much appreciated. Just to sum up simply: me = 192.168.14.110 ---> 192.168.15.* (vpn conn on tap0) target net 1 = 192.168.15.* target net 2 = 10.1.1.* need 'me' to pivot through 'target net 1' to reach 'target net 2'

@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.

and cracked

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

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

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.

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.

@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!

@can Hey can...other commentors hit the nail on the head, and you definitely have some options as to your setup. But to address your inital concern about security, digininja's points are dead on as per what approach to take. A rule of thumb to keep in mind when debating how to setup some perimeter defences and how they reflect your concerns about the outside world, is that as you start to increase your security level and mechanisms to a substantial amount, functionality, err I should say ease-of-use has the tendency to go down. Also, the more you add in to whatever it is you try to setup, the potential to increase the attack surface whilst trying to highten security can occur. That's why, like digininja said, if you spend some time identifying what specific threats you think you face, coupled with what it is of value you think you have to protect (other than the crap feeling of being hacked) are, adjust accordingly. I mean if each machine on your network is run through some form of hardening, nothing to insane, you're good from a vast majority of hackers (more like scriddies). Outside of that, as for home machines and networks, I feel the real threat comes from what you 'invite in' so to speak. Defences become irrelevant if you bring an infection, malware inside the network. As for you NAS arrangement, apologies if I read wrong but I have something similar and 1)yes it required networking (obviously) but 2) it does not NEED to face the internet in any way, if you setup something wher the NAS is accesssible by all machines on the internal network, make settings or just manually deny external access to anything other than one machine with (like digip said) some kind of tunneling in, your going for a mitigation approach. Talking about rules of thumb, the 'least privilege' mentality can be a life saver. Anywho, thought I'd chime in..sry if I missed the mark, dead tired and haven't slept for about 28 hrs

@digininja Hey all, new to the forum, glad to be here yadda yadda :)..gotta agree though with you digi as while still an entry guy into pentest circuit (cry for help RHL9 post I made)..I do a decent amount of forensic study and while yes Kali et. al. are great to cover a wide spread of purposes for the user, what tools get picked for the job is dependant on the job I feel. Like logicalconfusion said "the leaner the better". One of my lab setups has a few VM's dedicated to what I'm doing forensics on. Like I got all the usual forensic distros i.e. SIFT, NIST, CAIN, even PlainSight lol, but in the end what I did is I got a winxp and 7, an OSX and couple flavors of Linux with just what I need on each one to get a job done. In forensics ppl have a lot of opinions and far be it for me to talk like an authority, but as an example, if I'm doing recovery/forensics on mac drive, I like to image it and load it in a mac with tools geared to mac partition schemes and all that..same goes for others. If need be I'll branch out and test elsewhere. Think what I'm getting at with the rambling is whether it be a lab or custom distro/toolkit, it's kinda difficult to make a be all and end all setup. Anywho, my 2 cents.

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.