Talk at TYPO3 Conference 2016 in Bologna/Italy. Basic insights into hacking websites with SqlMap and BeEF XSS and considerations to prevent that. Screencasts of SQLi and XSS at https://www.youtube.com/watch?v=VIGVlmaKqxY & https://www.youtube.com/watch?v=WBDWWv5zdUQ
2. ~whois oliver.hader
• is living in Hof, Bavaria, Germany
• is freelance software engineer
• is TYPO3 core developer since 2007
• is member of the TYPO3 security team
• is studying at University of Applied Sciences Hof
• is currently working on event-sourcing for TYPO3
• loves cross-country mountain biking
6. Let’s assume…
• you have been hacked & and you know that
• no information about severity… yet
• is information or content modified?
• is the attack continuing or repeating?
• is password or private data stolen?
• you have to handle & clean up the hack
• What to do? In which order?
7. Strategy #1
• just overwrite from backup
• update system & extensions
• clear cache & that’s it
• BUT
• What was the entry point?
• What did exactly happen?
• Will it happen again?
8. Strategy #2
• take web-server offline & redirect to static page
• analyze what happened & find first entry-point
• understand the attack & secure the whole system
• apply clean backups - compromised or clean?
• BUT
• Your customer will hate you! … and love you!
• … what? Going the secure way sounds better!
9. Strategy #2
• search for anomalies in logs and file-system
• mass-requests to different URLs from same IP
• HTTP POST requests with large (download) size
• script files (PHP, Perl, CGI) in e.g. image folders
• search for actions during non-business hours
• back-end login at 03:00 in the morning
• content changes at midnight
10. Analysis
• find modified files
find
–mtime
–1
find
–mmin
–30
• determine modification time - time of attack?
stat
some-‐file.php
• find accordant log entries
• in web-server logs
• in TYPO3 application logs
11.
12.
13.
14.
15. Results so far…
• exact time 2016-09-14T14:54:59+0200
• extension saltedpassword created - how?
• PHP script Resources/Public/test.php
• called multiple times & with HTTP POST method
• might be a web shell
eval(gzinflate(base64_decode('S03Oy
FdQ91RIzFVIVChPTSrOSM3JUbcGAA==')))
20. Results so far…
• admin user somebody logged in & logged out
• extension saltedpassword installed during session
• further PHP warnings & errors found in log
• a bunch of MySQL warnings found
• might be result of SQL injection
27. What the ”hacker” did…
• found website at http://7.6.local.typo3.org/
• found plugin that accepts parameters via HTTP
index.php?id=37
&tx_listing_listing[itemId]=1
&tx_listing_listing[action]=show
&tx_listing_listing[controller]=Item
• basically it was some penetration testing tool
28. Kali Linux
• hacker’s toolbox
• network & wireless sniffing tools
• exploitation tools & distributed execution
• like Metasploit & Armitage
• web application hacking tools
• like SqlMap & BeEF XSS
34. A pessimistic approach…
• every request is a potential attack
• submitted data are not trustworthy
• as long as the opposite is proven
• validate & filter everything on server-side
(even if browser ”did” that already)
• encode, escape or cast for target context
(HTML, database, file-system, system call, mail, …)
35. More optimistic approach…
• no necessity for fatal failures & exceptions
• provide understandable messages to user
• warn, if something unexpected happened
• notify & emit confirmation dialogs
• put anomalies to dedicated log-files
• implement alternative notifications
• e.g. mail to user if username was used for login
37. Mitigation strategies
• network-based intrusion detection - e.g. Snort
• analyses network-connections and anomalies
• host-based intrusion detection - e.g. Samhain
• file integrity checks & log file monitoring
• web application firewall - e.g. mod_security
• individual filter rules for HTTP requests
• capable of denying SQL or XSS attacks
38. Information Disclosure
• everything that is not required by the application
• debug output & fragments - use a debugger
• outdated source-code - use Git for this
• carefully select failure messages
• ”username was not found on system” versus
• ”username and password are not correct”
• hide configuration via server-rules - .htaccess
39. Session Management
• always use secure channels (HTTPS)
• enforce HTTP-only & secure cookies
• avoid custom $_SESSION & $_COOKIE games
• select reasonable session time-out values
• use CSRF tokens for actions & forms
40. Authentication Management
• lock users with old MD5 passwords
• limit amount of admin users
• limit permissions per user
• enforce strong & different passwords
• apply debriefing strategy (employee quit job)
• use backend login notification feature of TYPO3
• separation of developer, integrator, admin, editor
41. Framework & Complexity
• understand what the framework is doing
• which security precautions are available
• which are not & how to close that gap
• keep track of important/breaking changes
• this might take some time, sure
• but hackers will do that as well
• apply security updates as soon possible
42. Laziness & Copy-Paste
• using ”Page PHP Content Element“
• allows (good) backend editors to write code
• … to write untested, insecure & executable code
• allowing TypoScript for everybody
• allows (good) backend editors to write code
• … to write even more insecure code
• … since TypoScript is a facade to real PHP calls
43. • cast or escape insecure variables
(int)$item
• use the provided API calls as much as possible
• understand what the framework is really doing
44. • cast or escape insecure variables
(int)$item
• use the provided API calls as much as possible
• understand what the framework is really doing
45. • filter or encode insecure variables
• really remove debug code or
<f:comment>
• understand what the framework is really doing