Posts by pmeunier
More JavaScript Browser Attacks… Meanwhile (ISC)2 Requires JavaScript, and All Is Well
Hear, see and speak no Evil—but pretend JavaScript is safe and force your customers to turn on JavaScript in their browsers to make your site sparkle. It’s not your problem, is it? It’s the developers of browsers that should fix their code!
Meanwhile the parade of JavaScript-based attacks continues. When even the organization responsible for CISSPs, (ISC)2, makes it impossible to update your CISSP credits without JavaScript turned on, what hope is there for shopping, banking, credit card security sites (e.g., verified by VISA) and investment sites (e.g., Fidelity) to adopt careful and responsible stances? I didn’t even get a reply from the (ISC)2 web site developers when I pointed out JavaScript issues. It’s a slick click interface party! Woohoo! Ooh, shiny!
It’s a party for attackers, that is. JavaScript is not the only problem, when any browser extension can take down the browser (or take control of it...). When will we see browsers architectured like operating systems, so that a plug-in can crash without taking the browser with it? When will plugins have configurable security policies and limited privileges, so that a bug in a plugin doesn’t compromise our computer’s security? It seems that browser architecture isn’t more advanced than Windows 95 and is about as secure, yet we poke puddles of pus with them and then prepare food, and don’t even worry about getting infected. Basic browser hygiene is provided by the NoScript Firefox extension, but when every site forces you to enable JavaScript, what’s the use? One thing is sure—I don’t see many people taking this seriously.
“Verified by VISA” Issues
The premise of the “Verified by VISA” program seems fine: request a password to allow the use of a credit card online, to lower credit card fraud (besides the problem of having to manage yet another password). However, there were several problems with how I was introduced to the program:
- I was unexpectedly requested to register my card after doing some shopping online on a site that allowed customer comments, and had forced me to turn on JavaScript.
- I knew nothing about this program, and the request was presented in an authoritative manner, implying that I *had* to register or else my purchase would be denied. (Bull! Even though I closed my browser without completing the registration, my purchase went through)
- I was asked for the last 4 digits of my SSN as proof of identity (!), along with information I had just provided to the online merchant (CC number, phone number, etc...)
- There was no explanation or link to an explanation of what was going on, why VISA would want me to register my card and what was this program.
That appeared to me more like a phishing attempt, exploiting a XSS vulnerability, than anything else. After contacting my bank, I was assured that the program was legitimate. Visa actually has a web site where you can register your card for the program:
https://usa.visa.com/personal/security/vbv/index.html
On that site, you will find that most links to explanations are broken. I get a “Sorry! The page you’ve requested cannot be found.” when clicking almost all of them (I found out later that it works if you activate JavaScript). Another issue is that you need to activate JavaScript in order to provide that sensitive information, therefore exposing your browser to exploits against the browser and to any XSS exploits (I’m not worried as much about the VISA site, which doesn’t have user-submitted content, as much as the shopping sites). If you are not using NoScript or forget to disable JavaScript afterwards, then you expose yourself to exploits from all the future sites you will visit. It’s irresponsible and unnecessary: there was nothing in the JavaScript-activated forms (or in the explanations) that couldn’t have been done with regular HTML. It’s all in the name of security…
A fundamental issue I have with this process is that commands (the registration) to reach a higher level of security are issued in-band, using the very medium and means (browser) that are semi-trusted and part of the problem we’re trying to solve (I realize that this program addresses other threats, such as the vulnerability of CC numbers stored by merchants). Moreover, doing this exposes more sensitive credentials. It is almost like hiring a thief as a courier for the new keys to the building, while giving him as well the key to the safe where all the keys are stored.
The Visa program also enables a new kind of attack against credit cards. If criminals get their hands on your last 4 SSN digits (or if they guess it, it’s only 9999 brute force attempts) and your credit card number, they could register it themselves, denying you its use! The motivation for this attack wouldn’t necessarily be financial gain, but causing you grief. I also bet that you will have a harder time proving that fraud occurred, and may get stuck with any charges made by the criminals.
The correct way of registering for this program would be by using a trusted channel, such as showing up at your bank in person to choose a password for your credit card, or through registered mail with signatures. However, these are not available options for me (I wonder if some banks offer this service, and if so, whether they are not simply using the above web site). There should also be a way to decline participation in the program, and block the future registration of the card.
In conclusion, this poorly executed program had a reverse effect on me: I now distrust my Visa card, and Visa itself, a little bit more.
Update: There doesn’t seem to be a limit on the number of times you can try to register a card, enabling the brute force finding of someone’s last 4 SSN digits (I tried 20 times. At the end I entered the correct number and it worked, proving that it still accepted attempts after 20 times). An attacker can then use the last 4 digits of your SSN elsewhere! Let’s say, your retirement accounts with Fidelity and others that accept SSNs as user IDs.
For more fun, I attempted to register my credit card again. I received a message stating that the card was already registered, but I was offered the chance to re-register it anyway and erase my previously entered password simply by entering my name, the complete SSN and phone number. Isn’t that great, now attackers could validate my entire SSN!
It gets worse. I entered an incorrect SSN, and the system accepted it. I was then prompted to enter new passwords. The system accepted the new passwords without blinking… Not only is the design flawed, but the implementation fails to properly perform the checks!
Insecure when run on Vista, thanks to symbolic links
I was surprised to learn a few weeks ago that Vista added symlink support to Windows. Whereas I found people rejoicing at the new feature, I anticipate with dread a number of vulnerability announcements in products that worked fine under XP but are now insecure in the presence of symlinks in the file system. This should continue for some time still, as Windows programmers may take time to become familiar with the security issues that symlinks pose. For example, in the CreateFile function call, “If FILE_FLAG_REPARSE_POINT is not specified and:
* If an existing file is opened and it is a symbolic link, the handle returned is a handle to the target.
* If CREATE_ALWAYS, TRUNCATE_EXISTING, or FILE_FLAG_DELETE_ON_CLOSE are specified, the file affected is the target.”
(reference: MSDN, Symbolic link effects on File system functions, at: http://msdn2.microsoft.com/en-au/library/aa365682.aspx)
So, unless developers update their code to use that flag, their applications may suddenly operate on unintended files. Granted, the intent of symbolic links is to be transparent to applications, and being aware of symbolic links is not something every application needs. However, secure Windows applications (such as software installers and administrative tools) will now need to be ever more careful about race conditions that could enable an attacker to unexpectedly create symlinks. They will also need to be more careful about relinquishing elevated privileges as often as possible.
In addition, it is easy to imagine security problems due to traps planted for administrators and special users, to trick them into overwriting unintended files. UNIX administrators will be familiar with these issues, but now Windows administrators may learn painful lessons as well.
Hopefully, this will be just a temporary problem that will mostly disappear as developers and administrators adjust to this new attack vector. The questions are how quickly and how many vulnerabilities and incidents will happen in the meantime. One thing seems certain to me: MITRE’s CWE will have to add a category for that under “Windows Path Link problems”, ID 63.
The Vulnerability Protection Racket
TippingPoint’s Zero Day Initiative (ZDI) gives interesting data. TippingPoint’s ZDI has made public its “disclosure pipeline” on August 28, 2006. As of today, it has 49 vulnerabilities from independent researchers, which have been waiting on average 114 days for a fix. There are also 12 vulnerabilities from TippingPoint’s researchers as well. With those included, the average waiting time for a fix is 122 days, or about 4 months! Moreover, 56 out of 61 are high severity vulnerabilities. These are from high profile vendors: Microsoft, HP, Novell, Apple, IBM Tivoli, Symantec, Computer Associates, Oracle… Some high severity issues have been languishing for more than 9 months.
Hum. ZDI is supposed to be a “best-of-breed model for rewarding security researchers for responsibly disclosing discovered vulnerabilities. “ How is it responsible to take 9 months to fix a known but secret high severity vulnerability? It’s not directly ZDI’s fault that the vendors are taking so long, but then it’s not providing much incentive either to the vendors. This suggests that programs like ZDI’s have a pernicious effect. They buy the information from researchers, who are then forbidden from disclosing the vulnerabilities. More vulnerabilities are found due to the monetary incentive, but only people paying for protection services have any peace of mind. The software vendors don’t care much, as the vulnerabilities remain secret. The rest of us are worse off than before because more vulnerabilities remain secret for an unreasonable length of time.
Interestingly, this is what was predicted several years ago in “Market for Software Vulnerabilities? Think Again” (2005) Kannan K and Telang R, Management Science 51, pp. 726-740. The model predicted worse social consequences from these programs than no vulnerability handling at all due to races with crackers, increased vulnerability volume, and unequal protection of targets. This makes another conclusion of the paper interesting and likely valid: CERT/CC offering rewards to vulnerability discoverers should provide the best outcomes, because information would be shared systematically and equally. I would add that CERT/CC is also in a good position to find out if a vulnerability is being exploited in the wild, in which case it can release an advisory and make vulnerability information public sooner. A vendor like TippingPoint has a conflict of interest in doing so, because it decreases the value of their protection services.
I tip my hat to TippingPoint for making their pipeline information public. However, because they provide no deadlines to vendors or incentives for responsibly patching the vulnerabilities, the very existence of their services and similar ones from other vendors are hurting those who don’t subscribe. That’s what makes vulnerability protection services a racket.
2007: The year of the 9,999 vulnerabilities?
A look at the National Vulnerability Database statistics will reveal that the number of vulnerabilities found yearly has greatly increased since 2003:
| Year | Vulnerabilities | %Increase |
|---|---|---|
| 2002 | 1959 | N/A |
| 2003 | 1281 | -35% |
| 2004 | 2367 | 85% |
| 2005 | 4876 | 106% |
| 2006 | 6605 | 35% |
Average yearly increase (including the 2002-2003 decline): 48%
6605*1.48= 9775
So, that’s not quite 9999, but fairly close. There’s enough variance that hitting 9999 in 2007 seems a plausible event. If not in 2007, then it seems likely that we’ll hit 9999 in 2008. So, what does it matter?
MITRE’s CVE effort uses a numbering scheme for vulnerabilities that can accomodate only 9999 vulnerabilities: CVE-YEAR-XXXX. Many products and vulnerability databases that are CVE-compatible (e.g., my own Cassandra service, CIRDB, etc...) use a field of fixed size just big enough for that format. We’re facing a problem similar, although much smaller in scope, to the year-2000 overflow. When the board of editors of the CVE was formed, the total number of vulnerabilities known, not those found yearly, was in the hundreds. A yearly number of 9999 seemed astronomical; I’m sure that anyone who would have brought up that as a concern back then would have been laughed at. I felt at the time that it would take a security apocalypse to reach that. Yet there we are, and a fair warning to everyone using or developing CVE-compatible products.
Kudos to the National Vulnerability Database and the MITRE CVE teams for keeping up under the onslaught. I’m impressed.
Vulnerability disclosure grace period needs to be short, too short for patches
One of the most convincing arguments for full disclosure is that while the polite security researcher is waiting for the vendor to issue a patch, that vulnerability MAY have been sold and used to exploit systems, so all individuals in charge of administering a system have a right to know ALL the details so that they can protect themselves, and that right trumps all other rights.
That argument rests upon the premise that if one person found the vulnerability, it is possible for others to find it as well. The key word here is “possible”, not “likely”, or so I thought when I started writing this post. After all, vulnerabilities can be hard to find, which is a reason why products are released with vulnerabilities. How likely is it that two security researchers will find the same vulnerability?
Mathematically speaking, the chance that two successful security researchers (malicious or not) will find the same flaw is similar to the birthday problem. Let’s assume that there are X security researchers, each finding a vulnerability out of N vulnerabilities to be found. In 2006, 6560 vulnerabilities were found, and 4876 in 2005 (according to the national vulnerability database). Let’s assume that the number of vulnerabilities available to be found in a year is about 10 000; this is most surely an underestimation. I’ll assume that all of these are equally likely to be found. An additional twist on the birthday problem is that people are entering and leaving the room; not all X are present at the same time. This is because we worry about two vulnerabilities being found within the grace period given to a vendor.
If there are more successful researchers in the room than vulnerabilities, then necessarily there has been a collision. Let’s say that the grace period given to a vendor is one month, so Y = X/12. Then, there would need to be 120,000 successful security researchers for collisions to be guaranteed. For fewer researchers, the likelihood of two vulnerabilities being the same is then 1- exp(-(Y(Y-1))/2N) (c.f. Wikipedia). Let’s assume that there are 5000 successful researchers in a given year, to match the average number of vulnerabilities reported in 2005 and 2006. The probability that two researchers can find the same vulnerability over a given time period is:
| Grace Period | Probability |
|---|---|
| 1 month | 0.9998 |
| 1 week | 0.37 |
| 1 day | 0.01 |
In other words, nowadays the grace period given to a vendor should be on the order of one or two days, if we only take this risk into account. Has it always been like this?
Let’s assume that in any given year, there are twice as many vulnerabilities to be found than there are reported vulnerabilities. If we make N = 2X and fix the grace period to one week, what was the probability of collision in different years? The formula becomes 1- exp(-(X/52(X/52-1))/4X), where we take the ceiling of X/52.
| Year | Vulnerabilities Reported | Probability |
|---|---|---|
| 1988-1996 | 0 | |
| 1997 | 252 | 0.02 |
| 1998 | 246 | 0.02 |
| 1999 | 918 | 0.08 |
| 2000 | 1018 | 0.09 |
| 2001 | 1672 | 0.15 |
| 2002 | 1959 | 0.16 |
| 2003 | 1281 | 0.11 |
| 2004 | 2363 | 0.20 |
| 2005 | 4876 | 0.36 |
| 2006 | 6560 | 0.46 |
So, according to this table, a grace period of one week would have seemed an acceptable policy before 2000, perhaps fair in 2000-2003, but is now unacceptably long. These calculations are of course very approximative, but they should be useful enough to serve as guidelines. They show, much to my chagrin, that people arguing for the full and immediate disclosure of vulnerabilities may have a point.
In any case, we can’t afford, as a matter of national and international cyber-security, to let vendors idly waste time before producing patches; vendors need to take responsibility, even if the vulnerability is not publicly known. This exercise also illustrates why a patch-it-later attitude could have seemed almost excusable years ago, but not now. These figures are a serious problem for managing security with patches, as opposed to secure coding from the start: I believe that it is not feasible anymore for traditional software development processes to issue patches before the threat of malicious disclosure and exploits becomes significant. Finally, the grace period that we can afford to give vendors may be too short for them to issue patches, but that doesn’t mean it should be zero.
Note: the astute reader will remark that the above statistics is for any two vulnerabilities to match, whereas for patching we are talking about a specific vulnerability being discovered independently. The odds of that specific ocurrence are much smaller. However, we need to consider all vulnerabilities in a systematic management by patches, which reverts to the above calculations.
Security Vigilantes Becoming Small-Time Terrorists
Vulnerability disclosure is such a painful issue. However, some people are trying to make it as painful as possible. They slap and kick people with the release of 0-day vulnerabilities, and tell them it’s for their own good. In their fantasies, sometime in the future, we’ll be thanking them. In reality, they make me feel sympathy for the vendors.
They cite disillusionment with the “responsible disclosure” process. They believe that this process forces them somehow to wait indefinitely on the pleasure of the vendor. Whereas it is true that many vendors won’t and don’t fix known issues unless they are known publicly or are threatened with a public disclosure, it bemuses me that these people are unwilling to give the vendor a chance and wait a few weeks. They use the excuse of a few bad vendors, or a few occurrences of delays in fixes, even “user smugness”, to systematically treat vendors and their clients badly. This shows recklessness, impatience, intransigence, bad judgment and lack of discernment.
I agree that reporting vulnerabilities correctly is a thankless task. Besides my previous adventure with a web application, when reporting a few vulnerabilities to CERT/CC, I received no replies ever, not even an automated receipt. It was like sending messages into a black hole. Some vendors can become defensive and unpleasant instead. However, that doesn’t provide a justification for not being gallant, and first giving an opportunity for the opposite side to behave badly. If you don’t do at least that, then you are part of the problem. As in many real life problems, the first one to use his fists is the loser.
What these security vigilantes are really doing is using as hostages the vendor’s clients, just to make an ideological point. That is, they use the threat of security exploits to coerce or intimidate vendors and society for the sake of their objectives. They believe that the ends justify the means. Blackmail is done for personal gain, so what they are doing doesn’t fit the blackmail category, and it’s more than simple bullying. Whereas the word “terrorism” has been overused and brandished too often as a scarecrow, compare the above to the definition of terrorism. I realize that using this word, even correctly, can raise a lot of objections. If you accept that a weaker form of terrorism is the replacement of physical violence with other threats, then it would be correct to call these people “small-time terrorists” (0-day pun intended). Whatever you want to call them, in my opinion they are no longer just vigilantes, and certainly not heroes. The only thing that can be said for them is, at least they didn’t try to profit directly from the disclosures.
Finally, let me make clear that I want to be informed, and I want disclosures to happen. However, I’m certain that uncivil 0-day disclosures aren’t part of the answer. There is an interesting coverage of this and related issues at C/NET.
VMworld 2006: How virtualization changes the security equation
This session was very well attented (roughly 280 people), which is encouraging. In the following, I will mix all the panel responses together without differentiating the sources.
It was said that virtualization can make security more acceptable, by contrast to past security solutions and suggested practices that used to be hard to deploy or adopt. Virtual appliances can help security by introducing more boundaries between various data center functions, so if one is compromised the entire data center hasn’t been compromised. One panel member argued that virtual appliances (VA) can leverage the expertise of other people. So, presumably if you get a professional VA it may be installed better and more securely than an average system admin could, and you could pass liability on to them (interestingly, someone else told me outside this session that liability issues were what stopped them from publishing or selling virtual appliances).
I think you may also inherit problems due to the vendor philosophy of delivering functional systems over secure systems. As always, the source of the virtual appliances, the processes used to create them, the requirements that they were designed to meet, should be considered in evaluating the trust that can be put into them. Getting virtual appliances doesn’t necessarily solve the hardening problem. Except, now instead of having one OS to harden, you have to repeat the process N times, where N is the number of virtual appliances you deploy.
As a member of the panel argued, virtualization doesn’t make things better or worse, it still all depends on the practices, processes, procedures, and policies used in managing the data center and the various data security and recovery plans. Another pointed out that people shouldn’t assume that virtual appliances or virtualization provide security out-of-the-box. Out of all malicious software, currently 4-5% check if they are running inside a virtual machine; this may become more common.
It was said that security is not the reason why people are deploying virtualization now. Virtualization is not as strong as using several different physical, specialized machines, due to the shared resources and shared communication channels. Virtualization would be much more useful on the client side than on the data center for improving security. Nothing else of interest was said.
Unfortunately, there was no time for me to ask what the panel thought of the idea of opening VMware to plugins that could perform various security functions (taint tracking and various attack protection schemes, IDS, auditing, etc...). After the session one of the panel members mentioned that this was being looked at, and that it raised many problems, but would not elaborate. In my opinion, it could trump the issue of Microsoft (supposedly) closing Windows to security vendors, but they thought of everything! Microsoft’s EULA forbids running certain versions of Windows on virtual machines. I wonder about the wisdom of this, as restricting the choices of security solutions can only hurt Microsoft and their users. Is this motivated by the fear of people cracking the DRM mechanism(s)? Surely just the EULA can’t prevent that—crackers will do what they want. As Windows could simply check to see if it is running inside a VM, DRMed content could be protected by refusing to be performed under those conditions, without making all of Windows unavailable. The fact that the most expensive version of Windows allows running inside a virtual machine (even though performing DRMed content is still forbidden) hints that it’s mostly due to marketing greed, but on the whole I am puzzled by those policies. It certainly won’t help security research and forensic investigations (are forensic examinators exempt from the licensing/EULA restrictions? I wonder).
VMworld 2006: Teaching (security) using virtual labs
This talk by Marcus MacNeill (Surgient) discussed the Surgient Virtual Training Lab used by CERT-US to train military personnel in security best practices, etc… I was disappointed because the talk didn’t discuss the challenges of teaching security, and the lessons learned by CERT doing so, but instead focused on how the product could be used in a teaching environment. Not surprisingly, the Surgient product resembles both VMware’s lab manager and ReAssure. However, the Surgient product doesn’t support the sharing of images, and stopping and restarting work, e.g. development work by users (from what I saw—if it does it wasn’t mentioned). They mentioned that they had patented technologies involved, which is disturbing (raise your hand if you like software patents). ReAssure meets (or will soon, thanks to the VIX API) all of the requirements he discussed for teaching, except for student shadowing (seeing what a student is attempting to do). So, I would be very interested in seeing teaching labs using ReAssure as a support infrastructure. There are of course other teaching labs using virtualization that have been developed at other universities and colleges; the challenge is of course to be able to design courses and exercises that are portable and reusable. We can all gain by sharing these, but for that we need a common infrastructure where all these exercises would be valid.
VMworld 2006: ReAssure (CERIAS), VIX and Lab Manager (VMware)
The conference is surprisingly huge (6000 people). Virtualization is obviously important to IT now. I am looking forward to the security-related talks (I’ll post about them later). Here are a few notes from the sessions I attended:
- Saturday a VMware team shot a video of yours truly talking about ReAssure (of course I became tongue-tied when the camera was turned on!). It will be presented at the general session Wednesday morning. I hope it generates interest in ReAssure!
- The VIX API on Tuesday morning was a very interesting session. It will enable the remaining automation functionality of ReAssure. It allows to automate the powering on and off of virtual machines, the taking of snapshots, transfering files (e.g., results) between the host and guest OS, and even starting programs in the guest OS! It was introduced with VMWare server 1.0 last summer, but I hadn’t noticed. It is still work in progress though; there’s support only for C, Perl and COM (no Python, although I was told that there was a source forge project for that).
- The VMware lab manager (introduced last summer) is very much like ReAssure. Except, ReAssure doesn’t have IP conflicts, and in ReAssure all experiments ("deployed configurations") are independent and their traffic is isolated with VLANs. In some respects, VMware lab manager is more sophisticated, and in others it is more primitive. For example, all networks in Lab Manager are flat (and even, all experiments share the same network, apparently), whereas ReAssure supports complex networks. To resolve IP conflicts, Lab Manager uses “fenced networks” which is a NAT hack. Lab Manager is also limited to fibre channel NAS, and is tied to VMware ESX while disabling most of what makes ESX flexible and interesting (ReAssure uses the VMware server freeware). I’m excited about the VIX API (see above) because will bring ReAssure beyond lab manager, by allowing snapshots, suspend and resume functionality, etc...I wonder what I need to do to make ReAssure more well-known and adopted. I haven’t found any bugs in it for a while, so I think I’ll officially release the first final (not beta) version very soon (e.g., Friday or next week).
