Password Spraying Dell SonicWALL Virtual Office December 30, 2019
Pentesting
0 Comment

Today I came across a Dell SonicWALL virtual office login page.  Typically what I will do when I see something like this is I will perform a password spray against it based on usernames I have collected from Open Source Intelligence (OSINT) during the reconnaissance phase of my pentest.  Typically I will not try to guess passwords manually through the web UI, I will use some sort of automated tool, typically Python or Burp Suite intruder. While password spraying this interface with Burp Suite Intruder I noticed something of interest:

POST /auth.cgi HTTP/1.1
Host: xx.xx.xx.xxx:xxxx
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 85
Origin: https://xx.xx.xx.xxx:xxxx
Connection: close
Referer: https://xx.xx.xx.xxx:xxxx/sslvpnLogin.html
Cookie: temp=; SessId=xxxxxxxxxxxxxxxxxxxxxxxx
Upgrade-Insecure-Requests: 1
DNT: 1

id=90&domain=DOMAIN&uName=USER&pass=PASSWORD&SslvpnLoginPage=1&digest=

Do you see it?  The “id” parameter. I never set that, yet here it is in my request.  The ID parameter is effectively acting as a CSRF token.  Every time a user visits sslvpnLogin.html or auth.html a new, unique “id” parameter is placed in a hidden field, which is sent in the POST request.  Why does this matter to us?  Well, if we do not have the right “id” parameter in our POST request to auth.cgi, we will not receive a successful authentication regardless of whether or not we supplied a valid credential pair.  Not good! (for us)

Here is what we need to do to make the attack work in Burp Suite Intruder:

Step 1: Create a Macro

  • Macros can be created under Project Options -> Sessions -> Macros.
  • Click “Add“.
  • In the Macro Recorder window, select a request to auth.html.
  • Click “Configure Item“.
  • Click “Add” next to the “Custom Parameter locations in response” window.
  • Set the parameter name to “id“.
  • Make sure the “Define start and end” checkbox is checked.
  • Select the “Start after expression” radio button.
  • Input <input type=”hidden” name=”id” value=” into the input field.
  • Select the “End at delimiter” radio button.
  • Input “ into the input field.
  • Click OK until you have left the Macro Editor.

Step 2: Create a Session Handling Rule

  • Session handling rules can be found under Project Options -> Sessions -> Session Handling Rules.
  • Click “Add“.
  • Click “Add” Under Rule Actions.
  • Select “Run A Macro” from the drop-down.
  • Select the Macro you created earlier.
  • Leave everything else default and click “OK“.
  • Set the Scope on the scope tab.

If you did the steps properly, anytime you make a request, Burp will first make a request to auth.html.  It should then parse out the value present in the hidden “id” field.  This id value will then be placed in any “id” field it finds.

Step 3: Run the Burp Suite Intruder attack

I’m going to assume you know how to perform a normal password spray in Burp Suite Intruder, so this section will just address the unique parts of this.  If you need to brush up, consider reading How to Burp Good.

  • Go to Intruder -> Options -> Grep – Extract
  • Click “Add“.
  • Make sure the “Define start and end” checkbox is checked.
  • Select the “Start after expression” radio button.
  • Input sessIdStr = “ into the input field.
  • Select the “End at delimiter” radio button.
  • Input “ into the input field.

The reason we do this is because both an invalid attempt and a valid attempt will return an HTTP 200 OK, however only successful attempts will set the “sessIdStr” variable in JavaScript.  You can then sort on the value of this field to identify successful logins.  It is also recommended to go to Request Engine and set “Number of Threads” to 1 as well as set a long delay.  This way the extracted tokens sync up properly, and you avoid locking up the application.  If you try too quickly, the application will likely start blocking you.  It looks like this:

Instead of the CRSF token being present, it is replaced with a redirect to dynLoginFull.html.  From there you will see this:

Given this constraint, this is probably something you want to run overnight with a long delay between attempts.

While these steps are specific to Dell SonicWALL Virtual Office, you can re-use this same methodology for most login portals with CSRF tokens.