My tryst with sourcecode review

A presentation at c0c0n 2014 in August 2014 in Kochi, Kerala, India by Anant Shrivastava

Slide 1

Slide 1

My tryst with Source Code Review Anant Shrivastava Information Security Consultant

Slide 2

Slide 2

$whoami $ $ $ $ Name : Anant Shrivastava Work : Information Security Consultant Work on : Web, Mobile, Linux Project Leader : * Android Tamer * Codevigilant $ Past life : * System and server Administrator * Developer (wp-filemanager >1L downloads)

Slide 3

Slide 3

Agenda • My journey so far in world of bug finding via code review. • And Yes I bluffed its not just about code review its also about associated automation and simple yet relevant techniques we used to identify all of that. • Simplest form : idea is to showcase what and how I have done stuff and how others can also do it.

Slide 4

Slide 4

What not to expect • • • • Tools Release Highly Sophisticated Code Artificial Intelligence Discussion about SAST (Static Application Security Testing)

Slide 5

Slide 5

Disclaimer • No commercials Source code review tools were harmed during the exercise.

Slide 6

Slide 6

Lets Read With enough eyes all bugs are shallow - Linus Torvalds Let me re-write it With enough expert eyes all bugs are shallow

Slide 7

Slide 7

WHY • Remember Last slide. Become “Expert Eye” • Wanted to Learn and Experiment new stuff. 1yr back (2013) : Security Researcher mainly Blackbox penetration tester and tool’s author.

Slide 8

Slide 8

Why not Bug Bounties • Invested time on Latest fad : Bugbounties • Realized : mostly its about alert(‘XSS’) and X-FRAME-OPTIONS or httpOnly for most of them. • Very few actually do something good. • Surface area is pretty small and its blackbox most of the time. • Personal opinion and people may have different opinion and its perfectly fine.

Slide 9

Slide 9

Bug Bounty efforts

Slide 10

Slide 10

What Next • Lets try Code review • But I don’t know code review • So lets learn code review • And off it goes into the ice box called pending things to learn.

Slide 11

Slide 11

Parallel efforts • I am not the only person thinking this, met another fellow researcher “Prajal Kulkarni” who was also planning on something similar and was looking for collaboration • We touched bases during #nullblr meet and off we-started with the project.

Slide 12

Slide 12

Slide 13

Slide 13

What is codevigilant • A community collaboration effort to make opensource software’s secure. • Finding bugs and responsibly disclosing them to respective author and preferable getting software updated. • Responsible disclosure on website after sufficient interval

Slide 14

Slide 14

Target A EcoSystem • We Picked WordPress Ecosystem which meant – WordPress Plugins (current focus) – WordPress Themes (current Focus) – WordPress Core (future check) • Pick an ecosystem which you think is near and dear to you and the language which you can easily understand.

Slide 15

Slide 15

Lets Roll • This is where things started to act funny. • We started with – Lets download top 10 and analyze one by one. – Ended up getting frustrated in couple of days – Mind you we were just two pentesters fiddling around with source code. Whitebox was not exactly our forte.

Slide 16

Slide 16

Lets Re-Roll • Lets automate and improvise – Download all plugins and Themes – Focus on vulnerability type and not on individual plugin • Seems like a good plan : so lets roll

Slide 17

Slide 17

Lets count

Slide 18

Slide 18

Automate Please • Quick WordPress information extractor and downloader. • Simple python script with grep / cut friendly output.

Slide 19

Slide 19

Slide 20

Slide 20

Lazy Me • Lets start with some easy stuff • How about looking at direct / unauthorized Access

Slide 21

Slide 21

Any tool available • Inspathx works just fine but I never got it to work for me. • So wrote a simple python script.

Slide 22

Slide 22

Tool release • Well I Lied let me release some tools for you • Error_finder release https://github.com/Codevigilant/error_finder

Slide 23

Slide 23

Output • Massive amount of Full Path Disclosure • Few direct access issues

Slide 24

Slide 24

Full Path Disclosure • WordPress stand of FPD is clear so no point reporting it.

Slide 25

Slide 25

WordPress Ecosystem • Lets step back and understand ecosystem a bit more – WordPress is a CMS – Various User Roles • • • • • • Super Administrator Administrator Editor Author Contributor Subscriber

Slide 26

Slide 26

WordPress ecosystem • Various plugin bind to various roles • Issues without authentication are prime concern. • Issues affecting subscriber and contributor hot 2nd. • Editor and Admins have unescaped HTML access

Slide 27

Slide 27

What Next • With this understanding in place we wanted to focus on unauthenticated issues first. • Lets start with A3-Cross Site Scripting

Slide 28

Slide 28

XSS • We thought its as simple as getting a <script>alert(‘XSS’)</script> back • Alas that should have been the case. • How to find it via Source code review. – Echo $_GET[‘input’]; • Grep “echo $_GET” should work

Slide 29

Slide 29

Did we missed something • How could we not miss obvious stuff • Attempt 2 – Either build a lexical parser tokenize whole source code or play intelligent – Extract all GET/POST/REQUEST parameters and access url with those parameters in place.

Slide 30

Slide 30

A3 XSS cont’ed • We did found massive amount on entries and then realized we have again screwed up. • If Content type is text/html XSS works • But if content type is – Json – Xml – Javascript • XSS failed

Slide 31

Slide 31

Automated more • Wrote another set of scripts which gives proper response types also.

Slide 32

Slide 32

A9 - Known Vulnerable components • We also focused on this issues category and identified multiple issues here also. • Mainly those were concerned with outdated SWF binaries used or old library files used.

Slide 33

Slide 33

By-Product • Error messages extracted via inspathx code yielded to multiple other issues like Directory traversal

Slide 34

Slide 34

End Result • Although this was like a rookie attempts to finding I don’t know what I am finding but we ended up with 250 plus issues in various WordPress plugins • We Decided to call this Phase 1

Slide 35

Slide 35

Phase 1 Statistics

Slide 36

Slide 36

Phase 2 • So What’s next • Authenticated issues – SQL Injection – Stored/Reflected Cross Site scripting in Admin console – CSRF – And more

Slide 37

Slide 37

Phase 2 Hurdles • We realized that authenticated flaws are prioritized based on user access. • We need to map all 30K Plugins with each type of access. – Script in progress to do exactly that.

Slide 38

Slide 38

Team Expansion • Started with me and Prajal we are now 4 people strong team – Anant Shrivastava – Prajal Kulkarni – Chaitu – Madhu Akula

Slide 39

Slide 39

What Next • We are seeking for more volunteers to come forward and help us make opensource softwares a more secure plateform.

Slide 40

Slide 40

What’s in this for audience • Simple list of vulnerable functions in PHP you can look for in your own codebases User Controls $GLOBALS $_SERVER $_GET $_POST $_FILES $_COOKIE $_SESSION $_REQUEST $ENV File Tainted file() fopen() popen() file_get_contents() fread() fscanf() Database tainted mysql_fetch_array() mysql_fetch_assoc() mysql_fetch_field() Cross Site Scripting (XSS) mysql_fetch_object() echo() mysql_fetch_row() print() printf() File Inclusion include() require() require_once() include_once() Command Execution exec() shell exec() system() proc_open() SQL Injection mysql_query() pg_query()

Slide 41

Slide 41

What’s in this for audience • Appeal to use codevigilant plateform • You find flaws – Either join our team and do continuous contribution • You get an author’s page at codevigilant • If you get any bounty for the bug you keep it. – Send details as one off cases of finding • We will do co-ordination with third party • We will try to get it patched or remove it from internet if not patched. • We will publish advisory on website with yours and co-ordinator’s name in advisory.

Slide 42

Slide 42

What’s in this for audience • If you want a open source product tested contact us and we will see what we can do about it. • If you want quick test’s you can think about donating to the project.

Slide 43

Slide 43

Simple Checklist • Look for Obvious flaws in unauthenticated Code – Reflected XSS – SQL Injection – Direct access / information disclosure – Directory Traversal • Understand Application Architecture – Language specific checks – List of language specific vulnerable functions – List of User Roles with impact of confidentiality • Attack Authenticated section – Stored XSS – CSRF – XSPA – SQL Injection – Direct URL access

Slide 44

Slide 44

CodeVigilant • • • • http://www.codevigilant.com https://github.com/Codevigilant https://facebook.com/Codevigilant https://twitter.com/Codevigilant

Slide 45

Slide 45

Questions?

Slide 46

Slide 46

Why not automated scanners • They are either good at black or whitebox. • We wanted to confirm from both sides. • They have a workflow which should be followed.

Slide 47

Slide 47

Open Source automation Tools • Tested rats and couple of other tools only rips worked marginally good. • But rips workflow demanded we enter url in webview everytime and web view keeps getting hanged from time to time.

Slide 48

Slide 48

Commercial scanners • No motivation to use them (we will be processing result not learning from it) • No money to spend on them • We did got one generous offer and tried one product

Slide 49

Slide 49

Commercial scanner • I don’t play name shame game hence no names here. • Commercial product was cloud hosted app where we need to upload code for review. • Software missed simple XSS and SQLi but so did open source tools also.

Slide 50

Slide 50

Why scanners missed • WordPress or Other CMS have there own functions to handle stuff • Example – Mysql query – WordPress query • These scanners don’t know about it and failes to detect it.

Slide 51

Slide 51

Why scanners missed • Or it could have been a simple case of misconfiguration at our end. • But after sharing results with Tool Dev they kind of vanished and didn’t responded back.