[russia] bugs -> max, time
TRANSCRIPT
![Page 1: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/1.jpg)
Bugs -> maxTime <= T
Omar Ganiev11/10/2015
![Page 2: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/2.jpg)
Hi!• I’m Beched
• I do application security assessment and penetration testing at IncSecurity
• Also I compete as RDot.Org independent team member
![Page 3: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/3.jpg)
Contents
• Intro• Technical view• Algorithmic view• Whitebox• Outro
![Page 4: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/4.jpg)
The problemCommon situations where the problem of rapid testing of web application arises:• Pentesting a huge scope full of web apps. You have a
couple of weeks to analyse and pwn them• The similar case – bug bounty. You want to collect (low)
hanging fruits faster than others• Customer asks about the costs of your work. You want to
estimate the cost by looking at web app for 5 minutes• Competition (Capture The Flag). You want to pwn the
tasks quickly to focus on others and to get extra points
![Page 5: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/5.jpg)
The solution• Prioritizing• Parallelizing• Automation• Guessing• Heuristics• ???• PROFIT• That’s it?
![Page 6: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/6.jpg)
Manual testing
• Tons of articles and books are written about testing methodology (including OWASP Testing Guide)
• Manual testing includes application logic analysis along with fuzzing
• Manual testing is more careful (no or 1=1 in DROP-queries, etc)
![Page 7: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/7.jpg)
Manual testing
• You can capture low hanging fruits in <= T time manually, but not in N applications
• Generally automated scanning surely sucks• But anyway we’ll focus on improving tools
rather than hands =)
![Page 8: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/8.jpg)
Semi-automated testing
• NMap, Burp Suite, Recon-NG, CMSMap, RAFT, etc…
• The tools are cool and save time, but still, you need to do a lot by hands, and the combination of such tools is poorly scalable
![Page 9: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/9.jpg)
Automated testing• Most of pentesters write their own specialized
tools for automated pentesting• Generally It is rather complex task with a bit of
rocket science• There’re a lot of problems like rich application
crawling or natural language processing (your program actually needs to read human language to understand the application)
![Page 10: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/10.jpg)
Automated testing
• There’re two main variables for measuring complexity (speed) of the testing methodology: time (depends on CPU & memory usage) and number of network requests
• They correlate, and time can be decreased by technical measures
• This is coverage vs requests count trade-of• Bugs -> max; time <= T; requests <= Q• We’ll mainly focus on the second parameter
![Page 11: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/11.jpg)
Automated testing
• Let’s take a look at some tips’n’tricks useful for pentesting toolkit
• We’ll observe technical and algorithmic ways to decrease testing time and number of network requests
![Page 12: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/12.jpg)
Contents
• Intro• Technical view• Algorithmic view• Whitebox• Outro
![Page 13: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/13.jpg)
Technical view• Well-known things first• HTTP speed-up: Keep-Alive & HEAD• HEAD method can be used for directory listing and
any other checks, which only need response headers (length- or time-based payloads, response splitting, etc)
• Keep-Alive is always useful, decreases number of connections and hanshakes and hence the server load
![Page 14: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/14.jpg)
Technical view• Trivial paths first• Why crawling the whole site, if there’re
sitemap.xml, robots.txt and Google dorks?• Why scanning the whole site, when you can
detect a CMS and version and check for vulns in database?
• Why fuzzing a login form a lot, when you can hit top passwords?
![Page 15: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/15.jpg)
Technical view• Scaling• Threading and horizontal scaling increase the
speed very much, hence they can provide better covering (if we limit time, but not requests)
• Recent example of distributed scanning platform is https://github.com/yahoo/gryffin/ written in Go
![Page 16: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/16.jpg)
Contents
• Intro• Technical view• Algorithmic view• Whitebox• Outro
![Page 17: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/17.jpg)
Algorithmic view
• Algorithmic view is quite interesting. How can we increase the number of fuzzed points and checked vulnerabilities without increasing requests count?
• Let’s remember the problems we face while conducting (semi-)manual testing
![Page 18: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/18.jpg)
Algorithmic view
• Ever seen such?• How do you process it manually?• URL patterns, similar pages
![Page 19: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/19.jpg)
Algorithmic view
• Already mentiond Gryffin project by Yahoo uses quite a handy algorithm – Simhash
• Take a look: http://www.wwwconference.org/www2007/papers/paper215.pdf
• If we build a Simhash-index of pages, we can skip duplicates, saving a lot of time
• Possibly it’s better to take into account not only response body, but response status, headers, parameters, etc
![Page 20: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/20.jpg)
Algorithmic view
• How to gather input points (GET, POST, Cookie, headers, …)?
• Classical way: automate browser (PhantomJS) and crawl the website, process each request
• Quick way:• Parse forms, parse links with query strings,
parse XHR parameters from JS
![Page 21: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/21.jpg)
Algorithmic view
• How to gather unknown input points?• Brute force• Quick: Iterative binary search• Collect a list of common parameter names, hit
them all in query string at once and check page for changes, then perform dichotomy
![Page 22: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/22.jpg)
Algorithmic view
• How to fuzz input points?• Long way: take a big list of fuzzing strings and
fuzz each parameter• Quick way: construct polyglot payloads and
check for a bunch of vulns at once• Take a look:
http://www.slideshare.net/MathiasKarlsson2/polyglot-payloads-in-practice-by-avlidienbrunn-at-hackpra
![Page 23: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/23.jpg)
Algorithmic view
• Polyglot payloads can be constructed because of ignored contexts (such as comments) in diferent languages
• Example of polyglot string: <tagxss>%0dresponse:splitting'"attributexss\
• Null-byte or backslash should be placed last• Time-based for (Postgre|My)SQL-injection: '/*!
+sleep(10)*/+\n1#(select 2 from (select pg_sleep(10))x)\n+'
![Page 24: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/24.jpg)
Algorithmic view
• Ok, what do we actually do, when we look at web app by eyes?
• We estimate “hackableness” of app or page and then think how can we hack it
• Why not automate thinking? %)
![Page 25: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/25.jpg)
Algorithmic view
• The thinking flow is like this:“Hm… It’s enterprise .NET site with a single login form.
Probably not that hackable…Hm… It’s default WordPress installation without plugins and
custom themes. Probably not hackable…Hm… It’s shitty custom PHP engine with a lot of forms and
input parameters. Instantly hackable! 8)“
![Page 26: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/26.jpg)
Algorithmic view
• What makes us think one or another way? Let’s point out some of features:
Platform (PHP, ASP, Ruby, …)Server (Apache, Nginx, IIS, …)Engine (WordPress, Django, RoR, …)Queries (count parameters in links on main page)Scripts (number of script tags on main page)Inputs (number of input tags on main page)SSL (if the site works with HTTPS or not)
![Page 27: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/27.jpg)
Algorithmic view
• The simpliest vulnerable-vs-secure classifier ever:
if PHP:vulnerable = True
else:vulnerable = False
• Ok, just kidding =)
![Page 28: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/28.jpg)
Algorithmic view
Machine learning FTW!
![Page 29: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/29.jpg)
Algorithmic view
![Page 30: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/30.jpg)
Algorithmic view• Today before the talk I scanned about a
thousand sites and built this decision tree on obtained data
• Actual classifier is a bit bigger than simpliest, but yet the common sense is preserved %)
• If the main page is PHP-script, there’re at least 4 GET-parameters in the links on it, and there’s at least one script tag, then site is probably vulnerable =)
![Page 31: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/31.jpg)
Algorithmic view
• Ok, this is about cost estimation, but how can this help us to scan the site?
• Ever seen this?
![Page 32: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/32.jpg)
Algorithmic view
• Let’s calculate more features for each page and build priority queue during scan
• If you do it right, /favicon.ico will be scanned last, and /admin.php will be scanned first
![Page 33: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/33.jpg)
Algorithmic view
• Which features can we calculate?• Dynamic/static page: detected platform
(dynamic language vs none), content-type (html vs static), extension
• Response status: OK vs Forbidden vs Redirect vs Not Found vs …
• A bit of NLP: if the path contains important words like admin, password, login, etc
![Page 34: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/34.jpg)
Algorithmic view
![Page 35: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/35.jpg)
Algorithmic view
• Lower priority() – higher priority:
![Page 36: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/36.jpg)
Contents
• Intro• Technical view• Algorithmic view• Whitebox• Outro
![Page 37: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/37.jpg)
Whitebox
• Static code analysis is a lot more rocket science thing, than blackbox testing
• Modern enterprise static code analysis systems are big and still not enough good (some of them still not better than grep)
• They may have nice ads with samples, but ads-samples can probably be constructed by hand ;)
![Page 38: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/38.jpg)
Whitebox
• Most pentesters have their own dirty hacks and regexps for finding the vulns
• I also use a simple grep wrapper, which allows to spot out security bottlenecks and obvious bugs in no time
• Especially useful during CTF, when the source code is not that big
• If integrated with IDE, can be rather cool semi-manual analyser
![Page 39: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/39.jpg)
Whitebox
• Collect a list of dangerous sinks for various languages
• Take a pattern for variable (like \$.* in PHP)• Take a list of securing functions• Generate regexps with negative lookahead,
which will search for patterns like this:danger_func(…not_a_securing_func(…$var
![Page 40: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/40.jpg)
Whitebox
• Get the result like this
• Parse it into any IDE and analyse traces
![Page 41: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/41.jpg)
Contents
• Intro• Technical view• Algorithmic view• Whitebox• Outro
![Page 42: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/42.jpg)
Summary• Application testing can be made faster in many
ways• Some of ways are achievable during manual
assessment, some of them are not• We can build fast and scalable web application
scanner for this• It will traverse pwning paths graph in an efficient
way and halt after hitting the requests limit
![Page 43: [Russia] Bugs -> max, time](https://reader034.vdocuments.site/reader034/viewer/2022042907/587cfa7b1a28ab1e7e8b4b1f/html5/thumbnails/43.jpg)
Results
• Some of reviewed techniques are already implemented in reps on my GitHub (libpywebhack repository not updated for years): https://github.com/beched
• It will be updated as soon as I finish debugging PoC scripts