Ethical Hacking - Sandro Zaccarini

Ethical Hacking from inside – Step 1: Code Review

So called “Ethical Hacking” is a very complex beast: let’s slice it and approach one step a time. During the first episod, we’ll talk about code review.
by: Sandro Zaccarini

Transcript

1. ETHICAL HACKING FROM INSIDE STEP 1: CODE REVIEW Sandro "guly" Zaccarini OPSCON 2016
2. guly@opscon 2016 whoami ▸ Sandro "guly" Zaccarini ▸ born purple ▸ happy to build ▸ hungry to break
3. guly@opscon 2016 agenda ▸ what the f...ine is ethical hacking? ▸ why would i have to pay someone to say me i'm broken?! ▸ (secure) code review, a matter of? ▸ ...playground
4. guly@opscon 2016 survey ▸ how many of you are devs? ▸ and devops? ▸ what about the others? ▸ how many of you "suffered" from a secure code review? ▸ and from a penetration test?
5. guly@opscon 2016 ethical hacking, AKA ▸ Penetration Test ▸ Intrusion Testing ▸ Vulnerability Assessment ▸ Security Assessment ▸ Red Team ▸ Cyber Attack Simulation ▸ (throw your dice)
6. guly@opscon 2016 ethical hacking, what the fine Ethical hacking refers to the act of locating weaknesses and vulnerabilities of computer and information systems by duplicating the intent and actions of malicious hackers [cit. http://wiki.cas.mcmaster.ca/index.php/Ethical_Hacking]
7. ▸ Russia hacks Hillary Clinton's private e-mail ▸ CIA plans to hack back ▸ Japanese survived to Fukushima incident ▸ but lives with nuclear plant compromised since years ▸ BigY fall in disgrace ▸ huge loads of "useless" info sold online ▸ refrigerators can't save us from rotten milk ▸ but takes down researchers' websites (and all the West Coast!) is there anybody out there?
8. ▸ 10 collect informations ▸ 20 lurk ▸ 30 knock ▸ 40 hit ▸ 50 fail (or break in) ▸ 60 GOTO 10 ethical hacking: how it's done
9. ethical hacking: not for the faint of heart
10. ethical hacking: not for the faint of heart
11. ▸ that's why it's pricy! ▸ ...start with good habits at home then ask for help ethical hacking: not for the faint of heart https://xkcd.com/327/
12. ▸ good design/policy ▸ code review ▸ vulnerability management ▸ penetration test ethical hacking: slice it down
13. ▸ is merely the most comprehensive way to find security issue in given code ▸ (not the easiest/faster) (secure) code review: the what
14. guly@opscon 2016 (s)cr: static analysis ▸ automated with tools (scheduled or on-demand) ▸ great for coverage (even for non-security issue) ▸ based on pattern ▸ reproducible ▸ misses the context and the business logic ▸ tools are *pricy* (even if you save some devs-time) ▸ huge load of false positive
15. guly@opscon 2016 (s)cr: manually ▸ read&draw like a child ▸ starts with threat modeling ▸ lateral think ▸ follow guides (ping OWASP) ▸ deep understanding of both language and application ▸ very high on time consuming
16. guly@opscon 2016 (s)cr: different security "objects" ▸ automatic finds mostly security bug: ▸ unvalidated input ▸ sql injection ▸ unserialize misuse ▸ manual is better for security flaws: ▸ change password ▸ boundaries ▸ "ashley madison"
17. guly@opscon 2016 (s)cr: the who ▸ is the execution flow correct in failure cases? ▸ are sessions handled correctly? ▸ what functionality can be accessed without authentication? ▸ are inputs from external sources validated? ▸ are there any known weaknesses in third-part security controls?
18. guly@opscon 2016 (s)cr: the when ▸ of course, when you write it (compiler/manually) ▸ at pre-commit time (SAST) ▸ or within the CI (SAST) ▸ regularly on all codebase (SAST/manually)
19. guly@opscon 2016 (s)cr: the when REQUIREMENT DESIGN DEVELOPMENT TESTING RELEASE ASSESSMENT THREAT MODELING & DESIGN REVIEW (SECURE) CODE REVIEW SECURITY ASSESSMENT FINAL REVIEW
20. guly@opscon 2016 (s)cr: the where ▸ login page ▸ password recovery ▸ file upload ▸ search form ▸ anywhere lives a user input
21. guly@opscon 2016 (s)cr: the why ▸ you are accountable for your code ▸ there are legal/compliance requirements ▸ the better/secure your code is, the better it can pay your bills
22. guly@opscon 2016 (s)cr: measure[1] SPOOFING “Identity spoofing” is a key risk for applications that have many users but provide a single execution context at the ap- plication and database level. In particular, users should not be able to become any other user or assume the attributes of another user. TAMPERING Users can potentially change data delivered to them, return it, and thereby potentially manipulate client-side valida- tion, GET and POST results, cookies, HTTP headers, and so forth. The application should also carefully check data re- ceived from the user and validate that it is sane and applicable before storing or using it. REPUDIATION Users may dispute transactions if there is insufficient auditing or recordkeeping of their activity. For example, if a user says they did not make a financial transfer, and the functionality cannot track his/her activities through the application, then it is extremely likely that the transaction will have to be written off as a loss. INFORMATION DICLOSURE Users are rightfully wary of submitting private details to a system. Is possible for an attacker to publicly reveal user data at large, whether anonymously or as an authorized user? DENIAL OF SERVICE Application designers should be aware that their applications may be subject to a denial of service attack. The use of expensive resources such as large files, complex calculations, heavy-duty searches, or long queries should be reserved for authenticated and authorized users, and not available to anonymous users. ELEVATION OF PRIVILEGE If an application provides distinct user and administrative roles, then it is vital to ensure that the user cannot elevate his/her role to a higher privilege one.
23. guly@opscon 2016 (s)cr: measure[2] DAMAGE Can an attacker completely take over and manipulate the system? 
 Can an attacker crash the system?
 Can the attacker obtain access to sensitive information such as secrets, PII?
 How many data sources and systems can be impacted REPRODUCIBILITY How easy is it to reproduce an attack to work?
 Can the exploit be automated? EXPLOITABILITY How much time, effort, and expertise is needed to exploit the threat?
 Does the attacker need to be authenticated? AFFECTED USERS If a threat were exploited, what percentage of users would be affected?
 Can an attacker gain administrative access to the system? DISCOVERABILITY How easy is it for an attacker to discover this threat?
24. guly@opscon 2016 (s)cr: the priority ▸ STRIDE, DREAD ▸ risk (likelihold * impact) ▸ mitigation level at detection time ▸ defined mitigation(or actual fix) effort
25. guly@opscon 2016 (s)cr: the bad ▸ fact1: devs aren't trained to security ▸ appendix: maybe they're even not interested ▸ fact2: devs and secs speak different languages ▸ appendix: and *know* different things ▸ appendix: secs mostly prefer to bash than to help ▸ therefore: apps works, but get hacked
26. THE LESS DEVS THAT TALK SECURITY YOU HAVE, THE MORE YOU NEED PEER REVIEW Anonymous Coward (secure) code review: catch22
27. guly@opscon 2016 (secure) code review: simple checklist ▸ data validation ▸ authentication ▸ session management ▸ authorization ▸ cryptography ▸ error handling ▸ logging
28. guly@opscon 2016 OWASP ▸ secure code review guide ▸ developer guide, with security in mind ▸ top 10 vulnerabilities in webapp, IoT, scada, mobile ▸ cheat sheet for various stuff
30. guly@opscon 2016 let's play a game
31. guly@opscon 2016 01-loggedin if ($_SESSION['loggedin'] !== true) { header('Location: /login.php'); } show_dashboard();
32. guly@opscon 2016 02-loglogin function mylog($mysqli) { $stmt = $mysqli->prepare("INSERT INTO loglogin(ip,user) VALUES (?,?)"); $stmt->bind_param("ss",$_SERVER['REMOTE_ADDR'],$_POST['user']); $stmt->execute(); return $mysqli->insert_id; } function showlogins($mysqli) { $sql = 'SELECT time,ip,user FROM loglogin'; $sql .= 'ORDER BY time DESC LIMIT 0,10'; $res = $mysqli->query($sql); while($row = $res->fetch_assoc()) { echo "time " . $row["time"]. " user " . $row["user"]; echo " from " . $row["ip"]. "<br>"; } }
33. guly@opscon 2016 03-nslookup <?php if (isset( $_POST['host'] ) ) { $host = $_POST['host']; echo '<pre>'; system("nslookup " . $host); echo '</pre>'; } ?> <form method="post"> Hostname to lookup: <input type=text name=host> <input type="submit"> </form>
34. guly@opscon 2016 04-fileupload $whitelist = array("jpg","png"); $ext = strtolower(end(explode('.', $file))); if (!(in_array($ext,$whitelist))) { echo "invalid file extension\n"; exit; } // avoid error on writing files with name longer than filesystem limits if ((strlen($file)) > 255) { $file = substr($file,0,255); } doUpload($file);
35. guly@opscon 2016 05-rememberme function doLogin() { if ($rememberme) { rememberMe($user); } doStuff(); } function rememberMe($user) { $value = hash(sha256,$user+time()); setcookie('rememberme',$value,time()+(60*60*24*365)); } function showLogin() { ?> <html><head><script src=js/loginpage.js></script></head><body> <form id=loginform><label> <input type=checkbox id=rememberme value=rememberme>Remember me </label></form></body></html> <?php } /* js/loginpage.js */ $(document).ready(function(){ $('dothings'); $('#loginform').on('submit', function(e){ $('.rememberme')[0].checked = true; this.submit(); }); });
36. guly@opscon 2016 06-loggedusers function updateLogged($user) { sanitize($user); $ip = $_SERVER['REMOTE_ADDR']; $resolver = new Net_DNS2_Resolver(); $res = $resolver->query($ip, 'PTR'); /* no need to sanitize DNS response, RFC does */ $host = $res->answer[0]->rdata; $sql = "INSERT INTO tracking (usr,ip,host) value"; $sql .= "('".$user."','".$ip."','".$host."')"; return $sql; } function showLogged($id) { /* input from database already sanitized at updateLogged */ list ($user,$ip,$host) = getRecords($id); echo "User ".$user.", last login from ".$ip."(".$host.")\n"; }
37. guly@opscon 2016 thanks! ▸ Acta est fabula, plaudite! ▸ Wait wait, any question? ▸ feedback please! ▸ guly@guly.org ▸ @theguly