<![CDATA[Dobin Github]]>https://dobin.github.ioRSS for NodeSun, 13 Nov 2016 13:05:42 GMT60<![CDATA[BurpSentinel improvements outlook]]>

Based on the feedback of BurpSentinel users, i’ll continue to improve the capabilities and UI of BurpSentinel. I’ve realized that people dont use it completely as i’ve intended it to. It seems that users perform a scan of a request, and look for indicators of BurpSentinel concerning indentified vulnerabilities. But originally, i’ve intended to show all necessary information so that the pentester is able to figure out on his own if there is a vulnerability or not (e.g. based on the response size, number of tags in the response etc.). This takes a lot of time and know-how, and seems not be be the primary need of a pentester. Therefore in the last few commits, I reworked the output of BurpSentinel so that it shows vulnerabilities more clearly, and also greatly enhanced the capability to realiably identify vulnerabilities in an automatic fashion.

This resulted in a muss less cluttered interface. I try to show only necessary information. Also I removed several features which were not as useful as I thought, notably Authentication attacks (with Session) and the Categorizer (which will be back in a later stage). The "Interesting" column is also gone. Also the default SQL injection scanner (the idempotent SQL injection scanner is now standard). I hope that people are not anymore overwhelmed by the UI as before.

There were also some new features by Burp/Powerswigger itself. Particulary interesting is the response diffing feature (as described in http://releases.portswigger.net/2016/11/1710.html). BurpSentinel already had a similar feature, but the analyzeResponseVariations() is more powerful and consistent. BurpSentinel now uses this API, and therefore requires at least Burp 1.7.10. The other development is the Backslash Powered scanner, as described in http://blog.portswigger.net/2016/11/backslash-powered-scanning-hunting.html. This is a very novel and interesting approach to find vulenrabilities. Additionally, the Burp Active Scan was also constantly improved by Burp.

With the new changes to BurpSentinel as mentioned above, it comes closer and closer to fully automated scanners integrated in Burp. I’m in the process on comparing BurpSentinel with both ActiveScan and Backslash powered scanning (BPS). So far i can conclude that ActiveScan got very powerful, especially together with BPS. Nevertheless BurpSentinel still finds vulnerabilities which are not detected by ActiveScan and BPS. I will release a detailed comparison in the future.

So, where will BurpSentinel go from here? In my opinion it still fits his niche. The main issue for me as pentester is: What if ActiveScan does not find vulnerabilities? Is the application secure, or is the scanner bad? With BurpSentinel, I also see failed tests, and am able to identify why the tests failed, and which tests. I can improve my manual hacking by looking at the output of these failed test, like: - How are parameters encoded? Where do they appear? - How does the page behave? - Is the request I tested realiably test worthy, or produces erratic results? - What other tests can or should I perform?

Additionally, BurpSentinel may be a good alternative to Burp Professional. People which use the free version of Burp dont have ActiveScan or BPS, so BurpSentinel is usefull here.

Lets discuss the individual scans of BurpSentinel.

XSS Scanner

This one works pretty good for reflected XSS, and quite OK for stored XSS. It should now produce less false positives. Pretty straight-forward, no need for great improvements.

SQL Scanner

Still working pretty well, and is probably the main feature of BurpSentinel. The idempotent SQL injection detection is doing good work, but still has trouble in highly dynamic websites. I will put some work into it, to provide less false-negatives, but still keeping false-positives low. Topic of research and hands on tests.

Command injection

Before it was in Attack "other". Changed it into a dedicated attack. Not as powerfull as other tools, but can still find some command injections. Work in progress.

Template injection

A new attack. Very similar to XSS scanner. Will be based on the research of Portswigger: http://blog.portswigger.net/2015/08/server-side-template-injection.html.

]]>https://dobin.github.io/2016/11/13/Burp-Sentinel-improvements-outlook.htmlhttps://dobin.github.io/2016/11/13/Burp-Sentinel-improvements-outlook.htmlSun, 13 Nov 2016 00:00:00 GMT<![CDATA[BurpSentinel More XSS Updates (Analyzer)]]>

I once had a feature in Sentinel, which beautified the HTML source code of HTTP responses (using jtidy). This can be very useful for the user, as it can be hard to navigate and read machine-generated HTML code (or just think of stripped newlines). Sadly it had an un-nice behaviour: it stripped ("beautified") partial XSS, like surplus single or double quotes in tags. I never thought about it much again.

As described in the last post, the OWASP AppSecEU 15 presentation with the title of "Finding Bad Needles on a Worldwide Scale" http://www.slideshare.net/dimisec/badneedles discussed finding XSS vulnerabilities on a large scale. The author explained a techniq where he just let a HTTP parser parse the HTTP response. If a syntax error occured, the attack payload was breaking the context, which is a good indicator for a successful XSS attack.

When i’ve seen that jtidy has a log message listener (http://sourceforge.net/p/jtidy/code/HEAD/tree/trunk/jtidy/src/main/java/org/w3c/tidy/TidyMessageListener.java), i realized i already have all the things i need to implement this feature too.

Testing onmouseover

Original: changeme4

<H2>Update Your Preferences</H2><p>
<FORM>
Homepage: <input value="changeme4" name="in" size="40"><BR>
<input type="submit" value="Change"></FORM>

Jtidy logs:

23 - trimming empty <p>
110 - InputStream: Doctype given is ""
111 - InputStream: Document content looks like HTML 3.2

With the input vector of: changeme4Xssaa"+= (the + is whitespace, url encoded)

<H2>Update Your Preferences</H2><p>
<FORM>
Homepage: <input value="changeme4Xssaa" =" name="in" size="40"><BR>
<input type="submit" value="Change"></FORM>

jtidy logs:

23 - trimming empty <p>
69 - <input> unexpected =, expected attribute name
59 - <input> unexpected or duplicate quote mark
110 - InputStream: Doctype given is ""
111 - InputStream: Document content looks like HTML 3.2

So jtidy was unhappy, and reported two additional errors (error code 69 and 59).

Sample output

sentinel newxss.png

Implementation

Commit: https://github.com/dobin/BurpSentinel/commit/51b91926f7bd5d10ba95b0d6278369c8a4d2a9de The code is ugly as fuck atm.

Also, there’s just a HTML parser, but no JavaScript parser.

]]>https://dobin.github.io/2015/05/24/Burp-Sentinel-More-XSS-Updates-Analyzer.htmlhttps://dobin.github.io/2015/05/24/Burp-Sentinel-More-XSS-Updates-Analyzer.htmlSun, 24 May 2015 00:00:00 GMT<![CDATA[BurpSentinel XSS Updates]]>

At OWASP AppSecEU 15, there’s a presentation with the title of "Finding Bad Needles on a Worldwide Scale" http://www.slideshare.net/dimisec/badneedles. Yahoo is trying automated XSS discovery with various tools. Anyway, Dmitry Savintsev created a test website similar to SentinelTestBed, with the name "WebSecLab" https://github.com/yahoo/webseclab. I tested Sentinel against all the testcases of WebSecLab, and found several testcases which get neither detected, nor tested correctly by Sentinel. Upon further research, i decided to change the XSS payloads of Sentinel completely. The full list is now:

 1  <p>"
 2  %3Cp%3E%22

 3  <p "=>
 4  %3Cp%20%22%3D%3E

 5  ' =
 6  %27%20%3D

 7  " =
 8  %20%22%3D

 9  ;alert(1)
10  %3Balert(1)

11  \'\"
12  %5C%5C%27%5C%5C%22

13  \u0022a
14  %253Ca%2527%2522%253E

This should give the penetration tester now all the tools he needs to reliably identify XSS. Sadly, 14 testcases are a lot to go trough. Maybe it is possible to shorten it in upcoming releases. Also in future releases, i want to implement more reliable automated XSS detection. Atm if the payloads are appearing decoded in the HTTP response, it will generate an INFO. But to realiably identify if it is exploitable, a lot more work is needed (which is part of the presentation mentioned above). I will release version 0.8 of Sentinel soon.

The log of the tests:

_fp: false positives: broken
-> not part of sentinel

doubq1: double encoding: broken
-> fixed

rs1: response splitting: broken
-> wontfix (too specific to be useful)

inredirect1_fp: accidently ok ;-)
-> leave it like it is

onmouseover: broken!
-> fixed, added intagcheck again

onmouseover_unquoted: broken
-> wont fix (too specific, who does this?!)

onmouseover_div_unquoted: broken
-> wont fix (too specific, who does this?!)

onclick1: broken
-> wontfix (too complex to reliably identify. open your eyes)

referer1: broken
-> not fixed yet

js3: broken
-> wontfix (too complex to reliably identify. open your eyes)

js4_dq: broken
-> implemented

js6_sq: broken
-> fixed, added ' to tag testcase

enc2: broken
-> implemented

backslash1: broken
-> implemented
]]>https://dobin.github.io/2015/05/23/Burp-Sentinel-XSS-Updates.htmlhttps://dobin.github.io/2015/05/23/Burp-Sentinel-XSS-Updates.htmlSat, 23 May 2015 00:00:00 GMT<![CDATA[BurpSentinel Payloads]]>

Based on my presentation on BSidesVienna 2014: http://www.slideshare.net/nibod/bsides-viennasentinel-v04 A short description of the payloads used by BurpSentinel. The payloads are developed to be as efficient as possible. There should be no unecessary payloads.

XSS

If the web app returns <p>", it is vulnerable to XSS.

For tag based injection:

%3Cp%3E%22
<p>"

Both of the above will be sent like written above. The 2nd, unencoded version will be not exploitable in real life if the parameter is in GET (HTTP URL).

For tag value based injection:

%22%3D
"=

Both of the above will be sent like written above. The 2nd, unencoded version will be not exploitable in real life if the parameter is in GET (HTTP URL).

SQL

The SQL tests are positive-based. The BREAK request should return another response than the original request. If not, we will not perform any additional scans. If one of the follow up request is identical to the original request, the webapp is most likely vulnerable to SQLi.

SQLu

The old SQL tests:

'BREAK"

OR 41=41
' OR '41'='41
" OR "41"="41

/**/

) OR (41=41
') OR ('41'='41
") OR ("41"="41"

If the attack vector is in POST (HTTP body), try each of the above with and without URL encoding. For GET (HTTP URL), just use URL encoding.

SQLs

The new SQL tests:

'BREAK"

ORIG+1-1
ORIG'+0+'0

ORIG[0]' || 'ORIG[1-END]
ORIG[0]' + 'ORIG[1-END]
ORIG[0]' 'ORIG[1-END]
/**/ORIG

If the attack vector is in POST (HTTP body), try each of the above with and without URL encoding. For GET (HTTP URL), just use URL encoding.

Other

The tests include command execution tests, and also shellshock. Additionally it will test null bytes (%00) and tries file inclusion positive test.

.\
./
() { :;}; sleep 10
%00
;sleep 10
\" ;sleep 10
';sleep 10
|sleep 10
& ping -c 10 127.0.0.1
\" & ping -c 10 127.0.0.1
' & ping -c 10 127.0.0.1
]]>https://dobin.github.io/2015/05/09/BurpSentinel-Payloads.htmlhttps://dobin.github.io/2015/05/09/BurpSentinel-Payloads.htmlSat, 09 May 2015 00:00:00 GMT