Recent
[Interview] The Jester
It’s not often I interview people for the blog however when some one catches my eye and raises my interest I like to find out more about them and share it with my readers. This time I interviewed ‘The Jester’. The Jester has been in the media spotlight recently for taking down Jihadist terrorist web sites via use of a targeted DoS attacks.
* Can you tell us a little bit about yourself and what you do?
Ryan, I would like to give you and your readers a little more about me but it’s kind of difficult to do that, given the nature of my targets, all I can give you sir is what’s already ‘out there’ – I am ex-mil – and slightly pissed at the surge in Jihadist online activities.
Now with regard to what I do: I aim to cause disruption to the online efforts of Jihadists on the internet. They have realized that they can recruit, train and coordinate home-grown terrorists completely via the internet, without ever having to meet. This cuts out much of the risk associated with any face-to-face contact for the recruiters. Web recruitment targets young, tech-savvy, vulnerable Muslims, the iPod generation if you like. By making these sites unreliable, the potential recruit numbers start to dwindle. I limit my hits to defined time-slots (rather than killing them completely) because I am well aware that official Counter Terrorist Agencies use some of these sites for intelligence gathering. I have been asked why I DON’T hit certain sites, well it’s simple. By NOT hitting certain sites (and hitting others hard) I am ‘herding’, people give up easily when a site is constantly up and down, and move on to a more reliable one. So it creates a funnel-effect, funneling terrorists and potential terrorists away from peripheral sites and into a smaller space that is easier to monitor.
Why Johnny Can’t Pentest
A white paper released recently (not dated) by the University of California titled ‘Why Johnny Can’t Pentest: An Analysis of Black-box Web Vulnerability Scanners’ evaluates eleven commercial and open-source black-box web vulnerability scanners.
The three authors of the paper (Adoupe, Marco, Vigna) test the black-box scanners against their custom vulnerable web application they called WackoPicko. Their custom web application contained a number of different technical and business logic vulnerabilities, both authenticated and un-authenticated.
They tested each scanner against WackoPicko in three different modes. Initial (point-and-click), Config (login credentials/mechanism provided) and Manual (local proxy use). The eleven scanners tested were Acunetix, Appscan, Burp, Grendel-Scan, Hailstorm, Milescan, N-Stalker, NTOSpider, Paros, w3af and Webinspect.
Web server zombies
Every now and then I like to visit black-hat community forums for a number of legitimate reasons. I like to see what the other side are up to, what they are buying/selling, at what price, who they are targeting, the skill level of the attackers, what exploitation techniques they use, etc. Visiting these underground community forums passively can be a great learning experience.
I had read stories about servers or web servers more specifically being targeted over personal computers for their use in DDoS attacks. Using a server rather than a client as a zombie means that the attackers have higher bandwidth, RAM, CPU and other resources at their disposal. Servers are generally more secure than clients as you would expect the people who set them up and manage them have a greater awareness of the risks involved. Although servers are generally more difficult to compromise, compromising 100 servers may be worth more than 1000 clients.
While browsing a particular black-hat community forum I came across a post by a user who wanted to purchase compromised web servers and made a particular request that the servers should have his supplied PHP script pre-uploaded.
The PHP script was named ’shell.php’ and contained the following lines;
$rand = rand(1,65000);
$fp = fsockopen('udp://'.$host, $rand, $err, $errstr, 5);
Weponising Web bugs
Back in March 2009 I wrote a blog post about using web bugs in information gathering, found here. For those unfamiliar with web bugs;
“A web bug is an object that is embedded in a web page or e-mail and is usually invisible to the user but allows checking that a user has viewed the page or e-mail. One common use is in e-mail tracking. Alternative names are web beacon, tracking bug, tracking pixel, pixel tag, 1×1 gif, and clear gif.” http://en.wikipedia.org/wiki/Web_bug
At the time I thought I had stumbled across something unique and that no one had really understood the implications of allowing the posting of remote images in web applications. The idea originally came to me when playing around with Adrian Crenshaw’s (IronGeek) logo. I wasn’t aware of the term ‘web bug’ so I explained to Adrian my concept, he knew what a web bug was and seemed to be well aware of their consequences.
DevBUG – Keeping track so you don’t have to
DevBUG is an idea that came to me while conducting a Vulnerability Assessment for University a few months back. We did a service scan on a web server and found that way too many ports and services were running! But that wasn’t the problem, well, not for us anyway. The problem was, is that we had 20 different software services and versions to google and write about.
So what is the process? We needed to find the software package’s homepage, find what the latest version of the package is for the development tree that was used, find out how old the version the web server was running was and then try to find any known vulnerabilities associated with that version. This is not too much hassle when you have to do it one to three times however when you have to do it twenty to fifty times it starts to become time consuming.
So in comes DevBUG. DevBUG is a web application which will be free for any one to use, no subscriptions or anything. It will be a search engine for software packages and their versions. Three times a day (every 8 hours) starting at 8AM GMT a backed spider will visit every software package’s homepage looking for new versions, if it finds a new version this will be added to a database. So the idea is, to keep a record of software, their released versions, release dates and any vulnerabilities which may affect each version. So this is great to solve our original problem! We have a one stop shop for all the information we need! But what other uses does it have?
