Brent Huston, CEO and Founder of MicroSolved, Inc., discusses with Chris Lay, Account Executive, the new trends with spear phishing. In this audio blog post, you’ll learn:
Grab a drink and take a listen. As always, let us know what you think!
Cybercriminals continue to seek new opportunities to steal credit card data, highlighted recently in the largest credit card theft seen in two years — a 1.5 million loss from Global Payments, a third-party processor of transactions for Visa and Mastercard.
What can companies do? Also, what can you do to protect your credit card data?
I sat down with Brent Huston, CEO and Security Evangelist with MicroSolved, Inc. to discuss such questions. In this audio blog post, you’ll hear:
And more!
Take a listen to this informative 15-minute interview and learn how you can protect your organization from data theft!
Resources:
Microsoft today released details and a patch for the MS12-020 vulnerability. This is a remotely exploitable vulnerability in most current Windows platforms that are running Terminal Server/RDP. Many organizations use this service remotely across the Internet, via a VPN, or locally for internal tasks. It is a common, prevalent technology, and thus the target pool for attacks is likely to make this a significant issue in the near future.
If you’re the “average Web user” using unmodified versions of the most popular browsers can do relatively little to prevent cross-site request forgery.
Logging out of sites and avoiding their “remember me” features can help mitigate CSRF risk, in addition — not displaying external images or not clicking links in spam or untrusted e-mails may also help. Browser extensions such as RequestPolicy (for Mozilla Firefox) can prevent CSRF by providing a default-deny policy for cross-site requests. However, this can significantly interfere with the normal operation of many websites.
The CsFire extension (also for Firefox) can mitigate the impact of CSRF with less impact on normal browsing, by removing authentication information from cross-site requests.
Web developers, however have a better fighting chance to protect their users by implementing counter-measures such as:
One simple method to mitigate this vector is to use a CSRF filter such as OWASP’s CSRFGuard. The filter intercepts responses, detects if it is an html document, and inserts a token into the forms and optionally inserts script-to-insert tokens in ajax functions. The filter also intercepts requests to check that the token is present. One evolution of this approach is to double submit cookies for users who use JavaScript. If an authentication cookie is read using JavaScript before the post is made, JavaScript’s stricter (and more correct) cross-domain rules will be applied. If the server requires requests to contain the value of the authentication cookie in the body of POST requests or the URL of dangerous GET requests, then the request must have come from a trusted domain, since other domains are unable to read cookies from the trusting domain.
Checking the HTTP Referer header to see if the request is coming from an “authorized” page is a common tactic employed by embedded network devices due to the low memory requirements. However, a request that omits the Referer header must be treated as unauthorized because an attacker can suppress the Referer header by issuing requests from FTP or HTTPS URLs. This strict Referer validation may cause issues with browsers or proxies that omit the Referer header for privacy reasons. Also, old versions of Flash (before 9.0.18) allow malicious Flash to generate GET or POST requests with arbitrary http request headers using CRLF Injection. Similar CRLF injection vulnerabilities in a client can be used to spoof the referrer of an http request. To prevent forgery of login requests, sites can use these CSRF countermeasures in the login process, even before the user is logged in. Another consideration, for sites with especially strict security needs, like banks, often log users off after (for example) 15 minutes of inactivity.
Using the HTTP specified usage for GET and POST, in which GET requests never have a permanent effect, while good practice is not sufficient to prevent CSRF. Attackers can write JavaScript or ActionScript that invisibly submits a POST form to the target domain. However, filtering out unexpected GETs prevents some particular attacks, such as cross-site attacks using malicious image URLs or link addresses and cross-site information leakage through <script> elements (JavaScript hijacking); it also prevents (non-security-related) problems with some web crawlers as well as link prefetching.
I hope this helps when dealing with this malicious exploit. Let me know how it works out for you. Meanwhile, stay safe out there!
Cross-site request forgery, also known as a “one-click attack”, “session riding”, or “confused deputy attack”, and abbreviated as CSRF (sometimes pronounced “sea-surf”) or XSRF, is a type of a website malicious exploit where unauthorized commands are transmitted from a user that the website trusts.
Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user’s browser. Because it is carried out in the browser (from the user’s IP address), this attack method becomes quite difficult to log. A successful CSRF attack is carried out when an attacker entices a user to “click the dancing gnome” which does some dirty gnom-ish v00d00 magic (no offence to any gnomes in the readership) on another site where the user is, or has recently been, authenticated.
As we’ll see in our video example, by tricking a user into clicking on a link in, we are able to create a new administrator user which allows us to log in at will and further our attack.
According to the United States Department of Homeland Security the most dangerous CSRF vulnerability ranks as the 909th most dangerous software bug ever found, making this vulnerability more dangerous than most buffer overflows. Other severity metrics have been issued for CSRF vulnerabilities that result in remote code execution with root privileges as well as a vulnerability that can compromise a root certificate; which will completely undermine a public key infrastructure.
If that’s not enough, while typically described as a static-type of attack, CSRF can also be dynamically constructed as part of a payload for a cross-site scripting attack, a method seen used by the Samy worm. These attacks can also be constructed on the fly from session information leaked via offsite content and sent to a target as a malicious URL or leveraged via session fixation or other vulnerabilities, just to name a few of the creative ways to launch this attack.
Some other extremely useful and creative approaches to this attack have evolved in recent history. In 2009 Nathan Hamiel and Shawn Moyer discussed “Dynamic CSRF”, or using a per-client payload for session-specific forgery at the BlackHat Briefings, and in January 2012 Oren Ofer presented A new vector called “AJAX Hammer” for composing dynamic CSRF attacks at a local OWASP chapter meeting.
So we know this type of attack is alive and well. What can you do about it? Stay tuned — I’ll give you the solutions tomorrow in Part Two!
I had an interesting conversation this week over email with a security admin still fighting Conficker.
If you haven’t recalled Conficker in a while, take a moment and read the wikipedia entry here: (http://en.wikipedia.org/wiki/Conficker). Back in 2008, this nasty bugger spread across the net like wild fire. It was and is, quite persistent.
Brent Huston, CEO and Security Evangelist of MicroSolved, Inc., delivered a fascinating presentation on social media security. In this talk, Brent discusses:
To download the slide deck and audio, click here for the zip file.
And as always, stay safe out there!
Wondering how Apple’s iOS5 and the iCloud will affect your life? Check our recent slide deck that tackles some potential challenges as Apple gets ready to roll out their newest creation. In this deck, you’ll learn:
As always, we’re here for discussion. Follow Brent Huston on Twitter to engage even more!
We recently presented the attached slide deck at an OWASP meeting and it was well-received. In it, you’ll learn:
Feel free to contact us with questions. Follow Brent Huston on Twitter and engage him. He’s more than happy to talk security!