Hi Folks,

This last weekend was my talk on Hackers 2 Hackers Conference 9th Edition @ São Paulo, Brazil. The talk was in portuguese and the slides are available here (download pdf) and (slideshare).

The subject of the talk was about layer 7 denial of service techniques and tools, using haproxy and socat to create a distributed denial of service from a single node, some XSS payload for DDoS and demonstration of the GoldenEye Mobile tool released today.

I am very happy with the results, with the public’s acceptance and reaction to the material presented and for the cheers from all the good friends and IT professionals from Brazil.

Also, thanks to Utah Networks, the talk was live streamed and recorded and the video can be found on this link or below.

TI Safe, the company that I currently work at, has also published some photos at their Flickr page.

As I promised to the attendees, the code for GoldenEye and GoldenEye Mobile are available at my github page.

Below a demo video of the GoldenEye Mobile tool in a test:

Talk apart, the whole event was AWESOME as usual. Spectacular specially crafted beer, excellent coffee-break, excellent service, excellent infrastructure! Hackers 2 Hackers Conference once again proved why is one of the most incredible confs at Brazil.

Thanks for people at H2HC for accepting the paper and doing such a great event.

Hi folks! I’m glad to inform that my paper “Advanced DDoS techniques: Layer 7, load-balancing and mobile tools” was accepted by the 9th Hackers 2 Hackers Conference (H2HC).

The event will take place on October 20-21 and it seems to be another success just like previous editions.

Don’t forget to check the event’s website for full line-up. If you can, enroll and enjoy!

I’ve been playing the last months with mobile pentesting within the Android platform. As I’ve been able to setup tcpdump-arm on my android phone, I began fooling around with it. I was trying to cross-compile Dug Song’s dsniff into armle architechture but it was only giving me headaches within the libnet/libnids dependencies and stuff.

So I wrote a quick one-liner to dump potential credentials (username/password) flowing in plaintext over the line:

And it works quite sufficiently:

Its not BY FAR efficient as dsniff, but can help out sometimes!

Today a friend shared me this link which pointed to São Paulo State’s Military Police website and showed a deface-like page with a hacktivist text and a youtube video.

The first thing that came to my eyes was the URL:

‘abrirframes.asp’ is ‘openframes.asp’ and ‘PAGINA=’ is ‘PAGE=’ in Brazilian Portuguese. Say no more.

That’s why I’ve said “almost hacked”. The site that was actually hacked was www.nova89fm.com.br (a Brazilian FM Radio) and not São Paulo State’s Military Police’s.

But São Paulo State’s Military Police website wasn’t clean at all. This ‘PAGINA=’ (or ‘PAGE=’) attribute clearly accepts any URL and this hacked website was ‘tucked-in’ to look like the police website was actually hacked. The proof that any URL can be spoofed is that (it will open a famous brazilian news portal).

This seems to be another action of script-kiddies and defacers (almost the same) using automated tools to call themself ‘hackers’. I’m kinda’ sorry for guys like these.

It would be better to do a decent vulnerability disclosure instead of doing such a lame hack. Those kids.

I’m always concerned about leaving terminal sessions open. I’ve used for many and many years the $TMOUT environment variable to close my sessions if idle for N seconds.

Just by exporting the TMOUT variable to the number of desired timeout seconds will close your shell (Bash, Ksh, Zsh and some others).

The following example will timeout in 300 seconds (5 minutes)

I am currently reading the book Secure Coding: Principles & Practices and the authors cited this timeout technique as pretty ineffective since it annoys more than it helps. I was obliged to agree. I got pretty mad with it some good times.

So I started looking for alternatives.

I’ve found a console application called vlock. It should be available on most distro’s repositories.

Just invoke vlock and the terminal session will be locked awaiting the user password to unlock. Pretty nice. Locking is definitely better than killing the session.

So I just started to wonder how to integrate vlock with zsh and after some research I’ve discovered that the shell will only be killed within TMOUT if no trap function for signal ALARM is set.

If you set an ALARM trap function, it will be called instead of killing the session. Perfect.

So I ended up with this in my .zshrc:

And now zsh locks my sessions after 10 minutes. It’s working perfectly even within tmux.

@UPDATE
As the comment from the reader Ehtesh Choudhury we can accomplish that in tmux only by adding to your configuration:

These past weeks I’ve been following the US drone hijacking by the Iranian Revolutionary Guards.

Recently the details of the hacking were posted.

The IRG says the communication signals were jammed forcing the UAV to go into autopilot (RTL – Return To Land, to be more precise). Then the GPS signals were spoofed to make the drone think that Iran Base was his Base.

US experts are still questioning these claims.

Truth or not it is very interesting.

From a few months some clients started to complain about their shared-hosting accounts being amazingly owned even if their PHP applications (WordPress mostly) were totally up to date.

The malware got into most of the PHP files including a PHP snippet that would eval and decode a base64-encoded string containing a script declaration loading Javascript from outside. This Javascript usually initiates download of .exe’s and stuff.

A friend’s account got hacked a few days back by this very same technique. He told me the attacker had left some files over so I asked him to hand me over so I could play a little and reverse-it.

Reversing

The code ended up being two times rendering 3 total ‘stages’.

Stage 1

Starts with two vars with random names containing hex-encoded strings that ended up being ‘create_function’ and ‘base64_decode’, two regular PHP functions.

Followed by that we have these vars called as functions

And it ends calling this assigned variable as a function…

The base64-encoded code is presented next at

Stage 2

What was base64-encoded is now a function that decodes content from another variable creating a payload string. The very first two variables are the most interesting because they are the “key” used to encode the payload, and the encoded payload.

All the characters of the payload string are presented as numbers that when put to the power of “key” will become the corresponding ascii character of the payload.

A very simple for loop makes the math and appends the string.

Stage 3

Well, what can I say, the decoded and evaluated string is a very simple PHP shell. It can run unix commands from a variety of techniques (popen, exec, system, passthru — the first available), can upload files, run php commands or connect to database hosts and run sql queries from the victim account.

Artifacts missing

The script actually used for the infection of the PHP file is missing. Unfortunately as it is a shared-hosting I can’t reverse the disk for deleted items but it’s not something very simple. What I deduce is a simple find looking for PHP files and then piping them to a custom-built parser that would add the evil line at the end or after some specific code.

I’ve seen variants that only infected WordPress’ footer.php template file (as it is included in every other page). This revealed to be a true application-targeted attack.

If there are no holes in the app, how the hell did he got here?

After some manual auditing on the client’s application I’ve stated that the compromise couldn’t be started by the application so I started probing the environment.

Nothing seemed really bad at first but then, when talking to a friend I’ve noticed the most primary mistake: Directory permissions. So I present you…

The attack vector

Some WordPress plugin developers make their plugins chmod upload directories world writable (chmod 777) to avoid problems. This is quite stupid but you might not know that most security-unaware developers do this quite often while having permissions issues.

We ran a quick find to see which directories where with write bit set on ‘other’.

Then, as expected, we got some entries…

Just having an account on the same machine is enough. The attacker simply copied the files over our writable directory and accessed via his browser.

As a hosting account with SSH access enabled is around 10 bucks/month, this is a really victim-untargeted, cost-effective attack.

Enumerating Victims

After we discovered the vector I jumped to my account and tried to ls /home but I was, as expected, denied.

So I though for a while and realized that /etc/passwd is readable. A little for function with some cut and the find above I was able to scratch down nearly 15.000 (YES, FIFTEEN THOUSAND!!!) world writable folders on this client shared-hosting machine.

Just stopped there because I’m on the light side ;)

Some nasty artifacts

The infection also affects .htaccess files. Even if you haven’t one, if you got owned this way, you probably have one now for each site you’ve hosted.

Google started to mark some sites as attack sites. The pointed out offending url is http://sweepstakesandcontestsinfo.com/nl-in.php?nnn=555. So I started grepping like there’s no tomorow. In instants my less become populated by some good eggs.

grep was pointing to many .htaccess files with strange RewriteRules statements. Then I opened the first one and there it was:

Apparently this malicious snippet is trying to hide itself from the site owner and direct hits, focusing only on hits arrived through search engines like Google, Bing, Yahoo! etc.

What the malware author missed and stood out like a shoot in the foot was that GoogleBot also got into that rule and started pointing out and alerting out users.

Just grep all your files for the URL mentioned on the report, or access your site from a search engine and see if it acts weird.

Fixing

The instant-fix is just runing an extended version of the above command.

The main reason this happens and have so many occurrences is that application developers often fail to properly configure the user account of the running application and the application’s filesystem folders so the application can only write to public directories or its user’s home (which the application is not located there).

Give the application’s folder owner and group permissions according to the application’s user and group, then give the application’s group to the accounts that need to rights to write on it (ex: developers, deploy daemons etc). Then, set up the permissions of the folders accordingly.

It could be worse

If the whole home directory is 777 (if this wasn’t bad enough by itself) (and we found some home directories like that on our probe) the attacker could put his key under ~/.authorized_keys and gain direct shell access to the account. And then it could be even worse…

I strongly recommend everyone that has a shared-hosting account to do this little test. It may save your life.

HTH!

I’ve stumbled on this article about using a custom-built hardware to bypass hardware enforcement on most DLP solutions available on market.

The solution uses an Atmel’s AVR microcontroller (the same on the Arduino‘s I’ve been playing around lately) and the V-USB library to create a virtual USB device and is crafted to announce itself as HID (Human-interface device). What common hardware fits this description: the keyboard. As you are not likely to forbid keyboard access to your users (or else they wouldn’t be able to type and thus work), this will gracefully pass through many enforcements.

The HID protocol allows bi-directional communication and this makes a perfect vector for data transfer.

The HID protocol allows communication in both directions by sending and receiving reports and feature requests. I’ve utilised this control channel to allow the PC to transfer files over the HID protocol to the device (…)

Thomas Cannon (the article author) had made experiments with a USB drive and other with an micro SD module attached to the custom-built hardware in order to store the transfered data since the AVR internal memory is quite short (maybe it’s fine for Bill Gates).

White-listing

While I’ve already seen some DLP solutions enforcing pendrives accesses through its vendor and model, I dunno if some had already made a way to enforce a unique fingerprint for each device (maybe yes, sounds feasible).

Can you trust drive signatures? What about the data they traffic?

What if drives signatures cannot be trusted anymore? We are left with the only enforcement left at input level: data monitoring.

Network IPS/IDSs are employed to detect (and sometimes stop) rogue data running on wires. Application IDS/IPSs are employed to detect (and sometimes stop) rogue data that come over inputs. Why not deploy IDS/IPSs at HID level? They are inputs, aren’t?

Suppose you have the latest DLP solution blocking all your USB drives, CD drives, Floppy drives, ZIP drives, iPhone etc etc. You also have all your network connections, email servers, HTTP traffic monitored.

An badly intentioned user won’t be able to upload malware through the drives nor download from web or network but what would stop him from actually TYPING the payload into notepad? Every hex or worse, every bit? Yes, sounds crazy and would take lots of time but hey – never doubt a determined person.

Things can be automated

Ok, so you think ‘Hey Jan, this would never happen, you are crazy. It would be very very very hard to keep track of every 0 or 1 typed’. Sure, I completely agree. The AVR-based hardware thus, does not.

This little beauty needs a piece of code on the host machine to make the data transfer possible so it has a stage where you simply open a notepad and the microcontroller (since he is actually a keyboard) will type it for you! Wow, zero work huh?

Seems that Moore was right after all

There are lot of microcontroller kits like BasicX, Arduino, Parallax and Pololu, just to name a few. Earlier at the São Paulo’s Hackers to Hackers Conference (H2HC) I’ve seen people using and R/C quad-copter holding an embedded system to crack WEP keys. Now we have a ‘robot-keyboard’.

Hardware is getting cheaper, fast as hell. A system is as secure as the complexity need to crack it. Cheaper hardware, more processing per second, greater the complexity has to be.

I wouldn’t be surprised if the next hackers cracking machines will be actually, machines.

In the past few days I’ve started following the work of Samy Kankar, which has some great work. Among all of them, I’ve almost-randomly picked one to play, Quickjack.

From Samy’s project page:

Quickjack is a tool developed to easily create pages with the capability to clickjack users no matter where they click on the page. The tool has an extremely intuitive interface and is literally a point-and-click tool. It also allows frame slicing and other features such as referral scrubing and more.

Quickjack provides an easy-to-use (ridiculous to use) GUI to generate the clickjacking code. Quickjacks’s clickjacking method consists on the classic iframe overlay.

This is the original expanded Quickjack-generated relevant JavaScript code (comments by me):

Basically, it listens to the mousemove event and sets the top and left CSS proprierties to match the cursor’s X and Y positions.

Going further

Problem to my use was that, by design, Samy’s approach jacks EVERY click, even if not on an anchor. The cursor staying on pointer (the little hand) all the time was telling out the felony.

In order to make a more subtle approach, I’ve hacked up Samy’s code a little to add hover element (event target) detection to apply the overlay only when hovering a objects.

NOTE: Not tested on elements within the anchor tag.
NOTE: Tested on IE7+ and decent browsers (FFox, Chrome).
NOTE: On Chrome, window.status was successfully spoofed. Bonus!
NOTE: Both codes (Samy and mine) works. Each one has its own objectives and fulfill them well.

Talk is cheap, show me the code!

Pretty bigger than the original huh? But, fear not! Compressed they are much all the same.

Original Compressed (relevant snippet)

My Hack, Compressed (relevant snippet)

Code is cheap, show me the DEMO!

Check out the demo here. The link on this page SHOULD take you to Google, but it won’t. (:

How bad is Clickjacking?

Browsers’ JavaScript support evolved past the years. Nowadays, a human-initiated click must take place before some JavaScript can run so if you want to run something that you might not get the user to click by his free will, clickjacking might be the answer.

Most adult industry sites use this kind of technique (in many ways different than this) to trigger pop-up advertisements.

Ok, Clickjacking will make me (or my users) click some ads, so what?

Well, there are many ways that a legitimate click can be used, but I’ll let this open for discussion.

Deploying the plague

This can be acomplished in many ways, the one’s that come first off my mind are: XSS and physical document infection by appending code after server compromise.

Any further ideas?

I still wondering if it would be useful if the true link actually gets followed after click has been hijacked. If so, it’s very easy to implement with a click observer on the iframe to take window.location to the real href beneath it. Maybe when I get another extra time I’ll play on that.

[]s

Symantec released an in-depth analysis of W32.Stuxnet, reviewed through IDA-PRO. The analysis shows off the staged infection process, the unusual injection of legitimate services instead of issuing LoadLibrary calls, core encryption and exported functions.

Tofino Security (specialized on SCADA security) has released an excellent white paper on the case (requires [free] registration). If you are a Malware Researcher / Reverse Engineer or just curious, I totally recommend it.

There’s code, great explanation, images, graphs and such explaining it all the process from infection, rooting and the propper malware code.