ethical hacking from inside – step 1: code review
TRANSCRIPT
ETHICAL HACKING FROM INSIDE STEP 1: CODE REVIEW
Sandro "guly" Zaccarini
OPSCON 2016
guly@opscon 2016
whoami
▸ Sandro "guly" Zaccarini
▸ born purple
▸ happy to build
▸ hungry to break
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
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?
guly@opscon 2016
ethical hacking, AKA
▸ Penetration Test
▸ Intrusion Testing
▸ Vulnerability Assessment
▸ Security Assessment
▸ Red Team
▸ Cyber Attack Simulation
▸ (throw your dice)
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]
▸ 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?
▸ 10 collect informations
▸ 20 lurk
▸ 30 knock
▸ 40 hit
▸ 50 fail (or break in)
▸ 60 GOTO 10
ethical hacking: how it's done
ethical hacking: not for the faint of heart
ethical hacking: not for the faint of heart
▸ 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/
▸ good design/policy
▸ code review
▸ vulnerability management
▸ penetration test
ethical hacking: slice it down
▸ is merely the most comprehensive way to find security issue in given code
▸ (not the easiest/faster)
(secure) code review: the what
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
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
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"
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?
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)
guly@opscon 2016
(s)cr: the when
REQUIREMENT DESIGN DEVELOPMENT TESTING RELEASE
ASSESSMENTTHREAT
MODELING & DESIGN REVIEW
(SECURE) CODE REVIEW
SECURITY ASSESSMENT FINAL REVIEW
guly@opscon 2016
(s)cr: the where
▸ login page
▸ password recovery
▸ file upload
▸ search form
▸ anywhere lives a user input
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
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.
TAMPERINGUsers 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.
REPUDIATIONUsers 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.
guly@opscon 2016
(s)cr: measure[2]
DAMAGECan 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?
guly@opscon 2016
(s)cr: the priority
▸ STRIDE, DREAD
▸ risk (likelihold * impact)
▸ mitigation level at detection time
▸ defined mitigation(or actual fix) effort
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
THE LESS DEVS THAT TALK SECURITY YOU HAVE, THE MORE YOU NEED PEER REVIEW
Anonymous Coward
(secure) code review: catch22
guly@opscon 2016
(secure) code review: simple checklist
▸ data validation
▸ authentication
▸ session management
▸ authorization
▸ cryptography
▸ error handling
▸ logging
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
guly@opscon 2016
let's play a game
guly@opscon 2016
01-loggedin
if ($_SESSION['loggedin'] !== true) { header('Location: /login.php'); }
show_dashboard();
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>"; } }
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>
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);
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(); }); });
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"; }
guly@opscon 2016
thanks!
▸ Acta est fabula, plaudite!
▸ Wait wait, any question?
▸ feedback please!
▸ @theguly