Tuesday, June 24, 2014

Kali (formerly Backtrack) Linux & BeEF

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!

Wednesday, March 19, 2014

Exploiting with BeEF Bind shellcode

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?

Friday, July 5, 2013

A funny issue on BeEF keylogger spotted by Mario


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.

Wednesday, June 26, 2013

The Internet of Things

We've heard a lot of people buzzing about this Internet of Things. So, we thought we'd offer you this without further comment:


Tuesday, June 18, 2013

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

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.

Thursday, April 4, 2013

The Evolution of Chrome Extensions Detection

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?

Wednesday, March 20, 2013

Exploiting m0n0wall 1.33 with BeEF

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.