Two Wrongs Make A Right?

While I was checking my feeds the other day I noticed the article here from The Register. The gist of it is a Russian startup has a service that will disrupt torrents.  The technical information is still sketchy, but here’s a quote of a quote from The Register article: “We used a number of servers to make a connection to each and every p2p client that distributed this film,” Klimenko says of the technology test. “Then Pirate Pay sent specific traffic to confuse these clients about the real I.P. addresses of other clients and to make them disconnect from each other.”  Sounds suspiciously close to the old TCP spoofed reset denial of service from back in the day to me.  Rather sending sending RST’s they’re just sending bogus IP info or something.

This seems like it would be on the wrong side of the law in some countries.  Maybe not, could be a grey area.  My thought: Is DoS-ing a service you (or your investors) think is wrong make it rightlegal?  And let’s look at what a DoS is from wikipedia “In computing a denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a computer or network resource unavailable to its intended users. ”  The Pirate Pay sounds like they’re DoS-ing a service to me.  I’d be interested to hear what the community has to say?  I don’t want to turn this into a “pro-piracyanti-piracy” debate, this more about the principal behind their approach:  What do you think about a company using tools or techniques to disrupt operations or traffic on other users’ machines?

Advertisement

Remote Pentest Setup – Multiple Default Gateways

Sometimes I’ll have an internal security assessment lined up and the client is amenable to having a remote testing device sent to them.  The goal being to be able to perform an internal penetration testsecurity assessment without having to physically be there.  This setup is win-win in my opinion: cuts down on travel costs which is good for everyone.  If you think about it, you don’t really need to be there, you just have to get access to the network.  You can even perform wifi pen testing, as long as your remote setup is near an AP.

I like to have a dedicated interface for ONLY remote access (sshnx serverfreenx or openvpn reverse back to me), when I’m doing 100% remote assessments.  Then I have a second interface for attackingscanning etc.  If wireless is in scope I’ll have my third interface (wlan obviously).

When I first started setting the remote machines up I experimented quite a bit.  I found that the setup was “flaky” if you simply assigned IP’s to the interfaces and hoped it worked.  I messed around with trying to manually set multiple default gateways, but that didn’t work very well.  I also found that a lot of tools (even the ones that allow you to choose an interface) will not sendreceive ALL traffic over the one you specify.

The solution that I chose was using IP ROUTE and IP RULE to ensure that any traffic sent to or from an interfaceIP would use the default gateway that i assigned it.

Example:

eth0 will be DHCP – It’s the interface the client can plug into their internal network.  You’ll get an IP from DHCP (with the default gateway).

eth1 will be statically set, and will be for your remote access (either reverse of bind).

First we need to create a special routing table:

 echo "1 pentest" >> /etc/iproute2/rt_tables 

Next, we set the routes:

ip route add 10.1.1.0/24 dev eth1 src 10.1.1.2 table pentest

ip route add default via 10.1.1.1 dev eth1 table pentest

Notice above we added the information to populate the “pentest” routing table.  It has a route and a default gateway now.

Below we set the rules to send all the traffic to and from an IP address to the pentest routing table.

ip rule add from 10.1.1.2/32 table pentest

ip rule add to 10.1.1.2/32 table pentest

Now, no matter what happens to eth0 your remote access interface is solid.  You can do the same thing for a wlan interface as well.  Simply create a second routing table and add the routes and rules.

I pulled most of this technique from this site.  Works like a champ for my purposes!

M$ Screencap Application For Troubleshooting… And Sleuthy Spying

I was recently made aware by an infosec colleague of mine DMFH (aka Donny Harris) about an M$ utility called the Problem Step Recorder, aka psr.exe.  It comes standard on Windows 7 machines.  In a nutshell it’s used to provide a step-by-step breakdown of user activity to provide to tech support after a user has re-created a problem, complete with screen captures!  NOTE: it does NOT capture keystrokes.  So, thankfully M$ did not embed a keylogger into Windows 7.  It shows a script of sorts of user’s activity in windows, info about PIDs, what mouse buttons are clicked and different hooks and internal system calls.  What got me was the screen captures… I know there are metasploit modules (screenspy and screenshot) and AutoIT apps, and that every keylogger on earth has a screencap ability.  DMFH made a good point tho: psr.exe would not be caught by most AV’s being that it is a signed and trusted system utility.  And, if a user sees psr.exe in their taskmgr and google it, they’ll see its an M$ troubleshooting tool, so they may be less concerned with it.

I realize that if you’re on a box and can run psr.exe you’ve already owned it, or are close to doing so; this is not the next l33t h@x0r attack, but another tool in your arsenal.  One use case could be you have shell access to machine (no meterpreter) and you can’t figure out a way to get tools onto the box for some reason.  If it’s a Windows 7 (didn’t find it on server 2k8 r2) you can grab screencaps and save them somewhere you can hopefully access.  Also, to reiterate my point, it’s an M$ utility so you don’t have to bring in another app that could trigger AV.

Below are a few pictures showing what the web archive (.mht) file contained.

Here are the commands to run psr.exe from the cli.  I did try it from a shell gained via metasploit and it worked like  a champ.  The key is migrate (if you’re not already running as them) into a PID of a user to capture that users’ session.

 psr.exe /start /output c:Usersusernametest.zip /sc 1 /gui 0

You need to issue (or schedule task) the below command to stop psr.exe from runningrecording.

psr.exe /stop

Here’s a blog post I found that details some of the switches of psr.exe.

Passed the Offensive Security OSCP Exam!

It has been an intense journey since I signed up for the PWBv3 course from Offsec.  But, now it is all worth it.  I received notice that I passed and can now claim the title: Offensive Security Certified Professional (OSCP).  I have taken many security courses, and have gotten a few certifications along the way, and I must say none have been as rewarding as this.  I cannot sing the praises of Offsec enough, even though sometimes during the course I wanted to curse their diabolical minds for coming up with some of the machines I had to penetrate.  I will admit that this was my second attempt at the OSCP exam.  I will not say I failed the first attempt (well actually that’s exactly what I did) but rather learned valuable lessons from it.  My first attempt was 23 hours straight (I took an hour nap) and at the end I knew I had come up short even before they emailed me.  But, this did not discourage me, it energized me!  I talked to many folks who had had a similar experience.  I will say that I hold this certification higher than any I have attained yet, bar none.

To those who are taking the course and may come across this post: Do not fret!  Remember what you’ve learned, and if you get knocked down get up and go at it again!  For those of you who are not (or have not) taken the course, check it out!  I guarantee even if you’ve been pen-testing for years this course will be a heckuva time!

VMware Releases New vSphere Hardening Guides. DISA STIG Precurser?

VMware announced January 25th that they have publicly released security hardening guides for  the vSphere virtualization platform.  The hardening guides are broken down via the following categories: introduction, virtual machines (vm’s),  host, vNetwork, vCenter, and Console OS.    I’ve read through them and they are broken down well, with brief descriptions of the security topic or setting that is being discussed, along with recommendations with detailed instructions, or links to guides with more in depth instructions.

I cannot confirm this via the Defense information Systems Agency (DISA), however I feel that these guides will play heavily into the development of a new DISA  ESX Security Technical Implementation Guide (STIG).  This is welcome news for those who work in the DoDMilitary workspace. Organizations that have implemented or are implementing vSphereESXESXi 4.0 have been relying on the old STIG, which was written with VI3 and ESX 3.5 in mind, and best practices to secure their implementations.  The subject areas these guides are broken into also mirrors the current DISA STIG checklist format, which leads me to believe that STIG checklists for vSphere won’t be far behind.