One of the single most annoying things about CSRF and router hacking etc… is that you get the annoying popups on Basic and Digest authentication pages, asking you to log in. More and more devices are moving away from these popup style alerts and moving more towards form based authentication, which is better from a hacking perspective. But still, I would say the vast majority of firewall/switch/router devices out there use Basic or Digest based authentication. The problem with that from an attacker’s perspective is that it creates a noisy popup if it fails (if the user isn’t authenticated) that the user is bound to notice and question. Well, now we have an answer - at least in Internet Explorer:

<DIV STYLE="background-image: url(http://router/path.to.hack)">blah</DIV>

I know there are others tags that work, but probably not as well as this method from what I’ve seen so far. I haven’t found a reliable way in other browsers to allow this to happen, but I’ve only barely scratched the surface of the vast number of CSRFable tags out there. But anyway, yes, this doesn’t cause the Basic or Digest auth dialog to fire so it will be more stealthy upon performing a CSRF that fails. Of course for POST based CSRF you’re still out of luck…

cloudprotection.pandasecurity.com XSS

To infinity and beyond

SophosLabs has discovered a technique in anti-virus marketing, which we detect as Spin/BigNumber-P. Typical behaviour involves phrases such as “Product detects X viruses!”, where X is a large, rather exact-sounding number. Some variants involve high-tech numerical displays updated in real-time with ever growing numbers. This technique has been spotted in the wild.

Never one to be left out, SophosLabs would now like to publish the number of malicious files we detect:

Yes, that’s right: We currently detect an infinite number of malicious files. While that shouldn’t surprise those familiar with SophosLabs, let me explain.

Talking about a specific number in relation to total malicious file detections reveals a misunderstanding of how malware and malware detection operate. The vast majority of threats we see are polymorphic, meaning we see many variations of each threat. Some are modified by the malware authors, others are generated by server-side programs and others modify themselves as they spread. And then there are file infecting viruses, which potentially modify any clean file on a system into a malicious one. An infinite number of threats.

When a quick response is required, our analysts and automated systems can block a specific file. But the bulk of our protection comes from generic detection which looks for characteristics of known malware, rather than an exact match. Just one such identity might detect hundreds, thousands, or an infinite number of variants.

Let me be clear: There are no practical limits on the number of different files we can detect, nor the number of identities our product can handle. If we were relying solely on exact files matches using checksums, we might quickly run into performance issues and memory limits, or restrict detection to only the most active threats (a practice followed by some other vendors). Instead, we maintain a multi-layered detection framework based on static characteristics and/or run-time behaviours.

Even with such an impressive detection number, we’re not about to rest on our laurels. In fact, by this tomorrow, our detection number will be an even larger infinity. If that seems paradoxical to you, you probably didn’t take Pure Mathematics in University. But I did, so let me offer an example: The set containing all positive, even numbers (2, 4, 6…) is infinite. So is the set of all positive numbers (1, 2, 3, 4, 5, 6…), but it is larger because it contains everything in the first set plus infinitely more.

Too theoretical? Consider Troj/VB-EUH which, when run, creates about 100 variations of itself on the host system. Running any of these variants on a new system will create 100 more variations. It’s easy to see an automated system left running could quickly create hundreds of thousands of new, malicious files which would all be detected at Troj/VB-EUH.

Hmmm, maybe it is time to get our own real-time counter.

profound misunderstandability in your employee's psyche

MITM, SSL and Session Fixation

23 posts left…

It’s been known for a long time that HTTP can set cookies that can be read in HTTPS space because cookies don’t follow the same origin policy in the way that JavaScript does. More importantly, HTTP cookies can overwrite HTTPS cookies, even if the cookies are marked as secure. I started thinking of a form of session fixation during our research that uses this to the attacker’s advantage. Let’s assume the attacker wants to get access to a user’s account that’s over SSL/TLS. Now let’s assume the website sets a session cookie prior to authentication and after authentication the site marks the cookie as valid for whatever username/password combo it receives.

First, the attacker goes to the website before the victim gets there so he can get a session cookie. Then, if the victim is still in HTTP for the same domain the attacker can set a cookie that will replay to the HTTPS website. So the attacker sets the same cookie that he just received into the victim’s browser. Once the victim authenticates, the cookie that the attacker gave the victim (and knows) is now valid for the victim’s account. Now if the victim was already authenticated or had already gotten a session token, no big deal. The attacker overwrites the cookie, which at worst logs the user out. Once the victim re-authenticates, voila - session fixation. Now all the attacker has to do is replay the same cookie in his own browser and he’s in the user’s account.