0
Buried by time, dust and BeEF
Antisnatchor – RuxCon 2013
Disclaimer

§  My views and opinions do not represent those
of my employer
§  My employer has nothing to do with anythin...
Who am I ?
§  Co-author of Browser Hacker’s Handbook
(pre-order from Amazon.com, available March 2014)

§  BeEF lead cor...
This made me LOL
And this made me ROFL (same page, scroll down)
The issue
§  If the problem is getting caught:
–  Spawn from 3 to X VPSs:
1. Each of them has SQLmap
2. Each of them dump...
The issue
The issue

§  Solving the issue without paying for multiple
VPSs/infrastructure….
Use BeEF

§  Exploit Time-Based Blind SQLi from multiple
hooked browsers
§  It’s the hooked browser that (just through
J...
Use BeEF

§ 
§ 
§ 
§ 
§ 

Install BeEF and OpenVPN on a VPS
VPN client -> TOR (or other proxies) -> VPS
Hook some bro...
Some background
§  Same-Origin Policy and XHR
§  Why Time-based Blind SQLi?
§  The beautiful features of MSSQL
§  BeEF...
Same-Origin Policy and XHR
Same-Origin Policy and XHR
§  Cross-origin XmlHttpRequest
–  You can’t read the HTTP Response (you need
Access-Control-Al...
Same-Origin Policy and XHR: implications
§  Exploit RCE cross-origin from the browser
–  See BeEF exploits on Jboss, Glas...
Same-Origin Policy and XHR: implications
§  If you can know if xhr.readyState == 4
–  You can monitor the timing
–  Just ...
Same-Origin Policy and XHR: implications
§  Firefox 24
Same-Origin Policy and XHR: implications
§  Chrome 29
Same-Origin Policy and XHR: implications
§  Internet Explorer 10
Why Time-based Blind SQLi?
§  If we can infer the timing of the response, we
can exploit Time-based blind SQLi cross-orig...
The beautiful features of MSSQL
§  http://msdn.microsoft.com/en-us/library/
ms187331.aspx
The beautiful features of MSSQL
§  http://msdn.microsoft.com/en-us/library/
ms187024.aspx
§  SQL Server 2008 R2 (<= 4 CP...
The beautiful features of MSSQL
§  MySQL and Postgres do not support this
–  Postgres example: http://www.postgresql.org/...
The beautiful features of MSSQL
§  With DBs != MSSQL you can still exploit SQLi
using Time-based Blind vectors from the
b...
The beautiful features of MSSQL
BeEF and putting all together
§  MSSQL only right now
–  PoC retrieving DB and Table names

§  Concurrent approach
–  Mu...
Concurrent approach: WebWorkers
§  Classic binary search inference
IF ASCII(SUBSTRING((...),position,1)) > bin_value
WAIT...
Concurrent approach: WebWorkers
§  If the response is delayed, the first byte of the
DB name string is > 64 (Integer valu...
Concurrent approach: WebWorkers
§  Given a pool of WebWorkers (controlled by a
state-machine in JavaScript)
§  Every WW ...
Concurrent approach: multiple browsers
§  As we can parallelize requests with
WebWorkers, we could even distribute the da...
BeEF and putting all together
§  Demo
–  Video, as last year here in RuxCon the live demo
failed (Vmware Fusion issues, b...
BeEF and putting all together
§  If you liked this talk, support BeEF buying:

§  Pre-order on Amazon available, out Mar...
Wrap-up
§  Thanks to Wade Alcorn for inspiration, research
motivation, and for being awesome!
§  Thanks to Bernardo Dame...
Upcoming SlideShare
Loading in...5
×

Buried by time, dust and BeEF

4,071

Published on

Slides of my talk at RuxCon 2013:

For those who do not listen Mayhem and black metal, the talk title
might seem a bit weird, and I can't blame you.
You know the boundaries of the Same Origin Policy, you know SQL
injection and time-delays,
you know BeEF. You also know that when sending cross-domain XHRs you
can still monitor the timing of the response: you might want to infer
on 0 or 1 bits depending if the response was delayed or not.
This means it's possible to exploit every kind of SQL injection,
blind or not blind, through an hooked browser, if you can inject a
time-delay
and monitor the response timing.
You don't need a 0day or a particular SOP bypass to do this,
and it works in every browser.
The potential of being faster than a normal single-host multi-threaded SQLi
dumper will be explored. Two experiments will be shown: WebWorkers as well
as multiple synched hooked browsers, which split the workload
communicating
partial results to a central server.
A pure JavaScript approach will be exclusively presented during this talk,
including live demos. Such approach would work for both internet facing
targets as well as
applications available in the intranet of the hooked browser.
The talk will finish discussing the implications of such an approach
in terms of Incident Response and Forensics,
showing evidence of a very small footprint.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,071
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
25
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "Buried by time, dust and BeEF"

  1. 1. Buried by time, dust and BeEF Antisnatchor – RuxCon 2013
  2. 2. Disclaimer §  My views and opinions do not represent those of my employer §  My employer has nothing to do with anything related to BeEF
  3. 3. Who am I ? §  Co-author of Browser Hacker’s Handbook (pre-order from Amazon.com, available March 2014) §  BeEF lead core developer §  Application Security researcher §  Ruby, Javascript, OpenBSD and BlackMetal fan
  4. 4. This made me LOL
  5. 5. And this made me ROFL (same page, scroll down)
  6. 6. The issue §  If the problem is getting caught: –  Spawn from 3 to X VPSs: 1. Each of them has SQLmap 2. Each of them dump a different data set 3. Each of them uses a different chain of proxies 4. When 1 data set is dumped, change the proxy chain. §  Restart from point 1 §  Downside: might not be cost-effective (depends on the data dumped :-). I don’t have enough money…
  7. 7. The issue
  8. 8. The issue §  Solving the issue without paying for multiple VPSs/infrastructure….
  9. 9. Use BeEF §  Exploit Time-Based Blind SQLi from multiple hooked browsers §  It’s the hooked browser that (just through JavaScript) send requests and dump data §  A forensic team will see a connection from multiple hooked browsers at the same time
  10. 10. Use BeEF §  §  §  §  §  Install BeEF and OpenVPN on a VPS VPN client -> TOR (or other proxies) -> VPS Hook some browsers Instruct the browsers to dump data for you When finished, terminate the VPS
  11. 11. Some background §  Same-Origin Policy and XHR §  Why Time-based Blind SQLi? §  The beautiful features of MSSQL §  BeEF and putting all together
  12. 12. Same-Origin Policy and XHR
  13. 13. Same-Origin Policy and XHR §  Cross-origin XmlHttpRequest –  You can’t read the HTTP Response (you need Access-Control-Allow-Origin, or a SOP bypass) But…. –  You can still send the request §  The request arrives to the destination –  You can check the state of the request §  xhr.readyState
  14. 14. Same-Origin Policy and XHR: implications §  Exploit RCE cross-origin from the browser –  See BeEF exploits on Jboss, GlassFish, and others –  You don’t need to read the response, just “blindly” send the attack vector §  Exploit XSRF §  Internal network attacks –  Ping sweeping, port scanning, and much more –  Inter-protocol communication and exploitation §  Wait for Browser Hacker’s Handbook :D
  15. 15. Same-Origin Policy and XHR: implications §  If you can know if xhr.readyState == 4 –  You can monitor the timing –  Just create 2 Date objects before and after sending the request, and do simple math :D
  16. 16. Same-Origin Policy and XHR: implications §  Firefox 24
  17. 17. Same-Origin Policy and XHR: implications §  Chrome 29
  18. 18. Same-Origin Policy and XHR: implications §  Internet Explorer 10
  19. 19. Why Time-based Blind SQLi? §  If we can infer the timing of the response, we can exploit Time-based blind SQLi cross-origin! §  Actually any type of SQL injection flaw can be exploited with Time-based blind vectors §  Sometimes time-based blind is the only way to exploit an instance of SQLi §  Sometimes SQLmap (great tool, kudos Bernardo!) is able to exploit SQL injections only using time-based vectors
  20. 20. The beautiful features of MSSQL §  http://msdn.microsoft.com/en-us/library/ ms187331.aspx
  21. 21. The beautiful features of MSSQL §  http://msdn.microsoft.com/en-us/library/ ms187024.aspx §  SQL Server 2008 R2 (<= 4 CPUs): §  256 thread pool (x86) §  512 thread pool (x86_64) §  I did my tests on SQL Server Express (on Windows 7) –  Connection numbers/thread pools are much more limited
  22. 22. The beautiful features of MSSQL §  MySQL and Postgres do not support this –  Postgres example: http://www.postgresql.org/docs/ 8.2/static/functions-datetime.html §  Still, you could use BENCHMARK or other similar functions –  Excessive CPU load if parallelized? Probably
  23. 23. The beautiful features of MSSQL §  With DBs != MSSQL you can still exploit SQLi using Time-based Blind vectors from the browser –  But you can’t parallelize requests §  Most ASP/.NET applications uses MSSQL §  MSSQL presence in the internet is widespread
  24. 24. The beautiful features of MSSQL
  25. 25. BeEF and putting all together §  MSSQL only right now –  PoC retrieving DB and Table names §  Concurrent approach –  Multiple WebWorkers –  Multiple hooked browsers §  3 to 4 times faster than SQLmap §  They disabled multi-threading when using time-based blind vectors, with every database, even MSSQL §  Can be re-enabled hacking the source code
  26. 26. Concurrent approach: WebWorkers §  Classic binary search inference IF ASCII(SUBSTRING((...),position,1)) > bin_value WAITFOR DELAY '00:00:02';-–  Position: byte position in the string to retrieve –  Bin_value: current mid value in the binary search §  Retrieving DB name (first request, first byte): http://172.16.37.149:8080/? book_id=1%20IF(UNICODE(SUBSTRING( (SELECT%20ISNULL(CAST(DB_NAME()%20AS %20NVARCHAR(4000)), CHAR(32))),1,1))%3E64)%20WAITFOR%20DELAY %20%270:0:2%27--
  27. 27. Concurrent approach: WebWorkers §  If the response is delayed, the first byte of the DB name string is > 64 (Integer value) §  If the response is NOT delayed, the first byte of the DB name string is <= 64 (Integer value) §  Example with first byte == 115 (“s”) §  §  §  §  §  §  §  Response delayed. Char is > 64 Response delayed. Char is > 96 Response delayed. Char is > 112 Response not delayed. Char is < 120 Response not delayed. Char is < 116 Response delayed. Char is > 114 Response not delayed. Char is == 115 -> s
  28. 28. Concurrent approach: WebWorkers §  Given a pool of WebWorkers (controlled by a state-machine in JavaScript) §  Every WW manage one byte (7 requests each) §  You can retrieve up to <pool_size> bytes at the same time §  WW communicate with the “parent” state-machine with postMessage() §  Everything is happening from and in the browser
  29. 29. Concurrent approach: multiple browsers §  As we can parallelize requests with WebWorkers, we could even distribute the data dumping process across multiple browser –  Reliability §  Minimize the impact of loosing an hooked browser –  Stealthiness (and piss-off forensic guys) §  The attack looks like coming from different sources –  Fun (and piss-off forensic guys) §  You want to target company X, which has company Y as competitor: hook some company Y browsers, and instrument them to exploit a SQLi in company X website :D §  Company X will think company Y is attacking them
  30. 30. BeEF and putting all together §  Demo –  Video, as last year here in RuxCon the live demo failed (Vmware Fusion issues, broken VM, porco dio!) –  https://vimeo.com/78055061
  31. 31. BeEF and putting all together §  If you liked this talk, support BeEF buying: §  Pre-order on Amazon available, out March 2014 §  50% of revenues will be used for the BeEF project (testing infrastructure, etc..)
  32. 32. Wrap-up §  Thanks to Wade Alcorn for inspiration, research motivation, and for being awesome! §  Thanks to Bernardo Damele (SQLmap) §  Thanks Chris and RuxCon crew §  Thanks Trustwave for paying my trip here §  BeE(F)R time now!
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×