Hacking Vulnerable Websites to Bypass Firewalls
4 likes8,957 views
The document discusses the vulnerabilities associated with running insecure code in local networks and the risks of various web standards and protocols, detailing exploits such as CSRF, DNS rebinding, and SQL injection. It emphasizes the need for strong security measures, such as CSRF tokens and same-site cookies, while cautioning that even private environments can be vulnerable to attacks. Ultimately, the document highlights that developers must be conscious of these vulnerabilities and adopt best practices to ensure their applications are secure.
Hacking Vulnerable Websites to Bypass Firewalls
- 1. "Running vulnerable code in local networks" || "how to get pwned by any website" 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1
- 2. The web is broken! Insecure standards, protocols and plugins ● WebRTC ● Leaks real IP behind VPN ● Can scan the local network ● SVG ● Not always blocked in picture uploads ● Leads to stored XSS, various filter bypasses, could be used to bypass CSP nonces ● Flash ● Unofficial competition between Flash and Firefox who gets most CVEs for code execution ● Exploit kit coder's choice
- 3. SOP is too permissive ● Cross Site History Manipulation (XSHM) ● Load images and scripts from any domain ● Frame all the web sites ● But X-Frame-options?! ■ Still leaks page loading times ■ In some cases window.open() also does the job ● Does NOT prevent making requests ONLY prevents receiving responses ● Cookies are sent by default
- 4. Are authenticated cross-origin requests necessary? ● Sending cookies when including remote images? ● Sending cookies when submitting forms to another website? ● Necessary? Sometimes. ● Should it be the default behaviour? Please no! ● Sending cookies with GET requests? ● There's not really a way around it ● Would annoy users
- 5. The Problem ● Users don't want to trade too much comfort for security ● It's up to developers to implement counter measures for those shortcomings ■ CSRF Tokens ■ Same-Site Cookies ■ Checks for Origin header (web sockets) ● Developers don't want to trade too much comfort for security ● SOP is the enemy ■ crossdomain.xml ■ postMessage ■ CORS ■ JSONP
- 6. That's nothing new ● We know we should use strong passwords and 2FA ● We should implement every possible counter measure for permissive SOP and other browser "features" ● We should not run insecure code in production ● We need to update our software
- 7. We all follow those guidelines Except when we don't well...
- 8. Let me explain At what point do you consider your code as publicly accessible? ● While coding ● In your private repository ● In your testing environment ● In production ✔ ✔ X
- 9. Wait what? ● My web server binds to 127.0.0.1! ● Other servers used for testing are behind a firewall! ● I am the only one who has access to my code! ● Windows Defender is up and running, so I don't even know why I watch this presentation!11
- 10. You forget about your biggest attack surface To hack your local application attackers can use ● CSRF ● DNS rebinding ● XSHM and similar attacks ● Timing side channels
- 11. Security guidelines Now tell me again, at every stage of your web app development: ● Use strong passwords / 2FA / authentication? ● Exploitable through DNS rebinding, XSHM, CSRF ● Protect against CSRF? ● Exploitable through - well - CSRF ■ Also XSHM ■ Doesn't matter for DNS rebinding anyway if it's unauthenticated / passwords are guessable ● Only run secure code? ● As hacker or security researcher? ■ Get another job. ● As a developer? ■ I have some small doubts here
- 12. Hacking the dev? Why not the server? ● Developers are the more valuable target when ● They have a copy of production data or access to backups ● They have access to other internal systems ● Production server is secured ● Their private movie collection is big enough (Critical mass > 500 GB) ● There might be multiple sites the developer is responsible for ● The application is announced but not online yet (startups, new features in existing sites) ● There's a higher chance * to find buggy code in a development environment ● * Except if you develop the facebook messenger for android, chances should be equal then
- 13. But I'm not a developer Good point. No testing environment, no vulnerable applications, right? ● Applications that run web apps on your computer ● Management interfaces ● websockets to exchange data between website and client ● Other devices in your network ● Your internet connected fidget spinner (or whatever monstrosity kickstarter creates next) ● NAS management interface ● One web interface almost every consumer has in the network ● Vulnerable home Router
- 14. DEMO TIME
- 15. Well, this is bad "That was a lucky guess with the default password. And stuff like an SQL injection can't be abused just with CSRF while you are cross-domain." ● Completely right ● You can't read the response of a request ● You can't add data if it's a SELECT query ● OOB exfiltration is not possible without proper privileges ■ Conclusion: My data is safe! XXX WRONG ● Oh come on, this is starting to get annoying ● Just because it is annoying. If you assume anything regarding SOP it's most likely wrong ● What's the matter now? How can an attacker possibly abuse an SQL injection through the victim's browser even though there's SOP in place?
- 16. We've talked about them before: iframes! Iframes can be used to extract data from an SQL injection ● Well, not only iframes, but also <img>, xhr and even the websocket API ● The problem? Leaking page loading times ● So what? ● SQL injection + delayed page loading time = ? ● Right. We can abuse blind SQL injections cross-domain! ● Seems like it's...
- 17. DEMO TIME
- 18. Well, this is bad too But what are the alternatives? ● Running your code in a VM ● Separation, but not that practical ● Can still lead to compromise of host machine or other machines in the network ● Code can be modified ● Don't visit the internet while you code ● ● Your code might require an active internet connection
- 19. Is there any way to be safe? DNS Rebinding ● Side Effect: ● New host header ■ Shared hosting not vulnerable (only the default host) ■ We can whitelist the original host header ● Is it preventable? ● Yes. Either on application or server level (preferred). ● If the host header doesn't match a whitelisted value -> 403. ● Works for apache, IIS, nginx
- 20. Is there any way to be safe? CSRF ● Problem: ● There might be no authentication yet ■ Critical functions might be exposed for everyone ■ No CSRF protection added yet ● You audit vulnerable code without CSRF protection at all ● There is not an easy solution for this ● Using frameworks ● Starting with ■ CSRF protection ■ Authentication MEH
- 21. Is there any way to be safe? (Experimental) Universal CSRF Protection in your environment? Conveniently possible for PHP apps ● First: Create a file with the following content:
- 22. Is there any way to be safe? Halfway done ● Next: Add the file to the PHP.ini directive auto_prepend_file ● This will automatically include the file whenever any PHP file is parsed. This works in a similar fashion as PHP's require(). ● This means, whenever a web page is opened it will ● Load the PHP file ● Check if a cookie with the name "access" is set ■ If it's not, it will just throw an error, set the cookie and stop execution ■ If it is, the file does nothing and doesn't interfere with your code ● Since it's a same site cookie requests can only be made from the same domain
- 23. Conclusion Don't rely on SOP doing the right thing ● Everything we talked about is preventable, countermeasures are just not always well known ● Developers and Security Researchers should keep in mind that their testing environments are publicly accessible to a certain degree ● Even the average user is at risk. Passwords for routers should be strong and unique like every other password ● SOP alone is not going to save you