Security Company Says NASDAQ Waited Two Weeks To Fix XSS Flaw 61
alphadogg writes "A Swiss security company said the NASDAQ website had a serious cross-site scripting vulnerability for two weeks before being fixed on Monday, despite earlier warnings. Ilia Kolochenko, CEO of the Geneva-based penetration testing company High-Tech Bridge, said he repeatedly emailed NASDAQ and warned of the XSS flaw. 'I can basically say I have spammed them,' Kolochenko said in an interview. A NASDAQ spokesman did not have immediate comment. NASDAQ.com lets users create accounts and build a profile to monitor stocks and news."
Very difficult. (Score:4, Funny)
Re: (Score:1)
-- "Your car is broken"
-- "Yeah we know, but it's really difficult to fix it"...
WTF???
Re: (Score:1)
-- "Your car is broken"
-- "Yeah we know, but it's really difficult to fix it"...
WTF???
You'd be shocked at how many people regularly drive around with check-engine lights on, bald tires, burned-out taillamps, broken window motors/tracks...
Re: (Score:2)
Re: (Score:2)
I've never owned a car that doesn't have a TPMS light on, regardless of the state of the tires.
Re: (Score:2)
I was following a Mercedes SUV the other day, I'd guess at least a $100k vehicle. One of its rear tires was so worn that the steel belts were showing through the rubber of the tread. Keep in mind, this wasn't an up close inspection. This was what I could see from the driver's seat of my vehicle while I was behind them. I'd guess the belts were showing for between a quarter and a third of the circumference of the tire. The other side wasn't showing belts, but it was obviously pretty much bald, too.
Re:Very difficult. (Score:5, Insightful)
For the unaware: this is serious sarcasm. Fixing XSS is usually pretty trivial; just apply output encoding (usually HTML entity encoding, but there are other valid approaches) to the user-supplied data before reflecting it into the page. Even in weird edge cases, like where the user is explicitly allowed to insert their own HTML (Slashdot, for example) you can get around the problem by whitelisting certain elements and parameters, and rejecting (or removing, though this must be done carefully) anything which doesn't conform. It's A long-ago solved problem that some people still have incredible difficulty with.
Doing security work myself, I've seen XSS fix times ranging from "within the hour" to "three weeks or so", and the median is probably about two days. I always wonder what the hell is up with the companies on the long end of that scale.
Re: (Score:3)
Perhaps it is a serious problem. Without actually seeing the vulnerability, it's hard to say.
WAY too many security scanners panic the instant they get any fragment of text to display on the page, even if it is sufficiently munged that no script could ever be made to run. They'll still cry wolf when you entity code it.
They're like elementary school kids the first time they get the calculator to say hell or boobs.
Re: (Score:1)
Perhaps it is a serious problem. Without actually seeing the vulnerability, it's hard to say.
WAY too many security scanners panic the instant they get any fragment of text to display on the page, even if it is sufficiently munged that any script could ever be easily made to run in contexts not conceived of by the site builders. They'll still cry wolf when you completely misunderstand the problem and fail to fix it, repeatedly
They're like elementary school kids the first time they get the shit kicked out of them, and try to warn the other kids before they get the shit kicked out of them.
Fixed that for you so you don't look like an imbecile. You're welcome.
Re: (Score:2)
With a post like that, I can see why you went the AC route. Good call!
good process is not trivial (Score:2, Insightful)
Its called process.
Product Owner is sent notice of vulnerability.
Operation or QA tries to reproduce the issue.
Upon confirming the vulnerability, Product Owner tells business analyst and dev. manager about issue: change request is created.
Dev team picks up ticket, and does more analysis.
Geek reproduces issue locally.
Geek writes failing, automated test that reproduces the error.
Geek fixes error, automated test is passing.
Geek has code reviewed by team members, and probably infosec.
Geek hands code off to QA.
QA
Re:good process is not trivial (Score:5, Funny)
In reality,
Dev gets email, updates code, posts to live website.
He's just 3 weeks behind on email.
Re: (Score:2)
You must work for an outfit with a rather fast and loose approach to both infosec and quality assurance.
Re: (Score:2)
Sounds like a fast response... (Score:5, Interesting)
Despite the twitch mindset that many people on this website have about security vulnerabilities, fixing a bug like that and deploying the fix in only 2-weeks is excellent for any project (open/closed/otherwise) and is especially good for a large commercial service like Nasdaq.
Re:Sounds like a fast response... (Score:5, Interesting)
Um... no. Fixing XSS is trivial. I work in this field myself; only a small percentage of our clients take more than a week to fix a reported issue, and many manage it same-day. This includes quite large and well-known software companies and websites, including in the financial sector (although I'll admit that the financial sector tends to be on the slower end of things).
Re: (Score:2)
Um... no. Fixing XSS is trivial. I work in this field myself; only a small percentage of our clients take more than a week to fix a reported issue, and many manage it same-day. This includes quite large and well-known software companies and websites, including in the financial sector (although I'll admit that the financial sector tends to be on the slower end of things).
Actually fixing the XSS is trivial; it's QAing and publishing the fix that takes the time.
Just think of Microsoft and their recent security patches; you can really make a mess of things while applying a trivial fix. The testing is needed to verify that applying the fix doesn't do something bad (doesn't matter what quality the fix is or how long it takes to write).
That said, it really shouldn't take longer than a week, assuming it's been properly flagged as critical. My guess is that it was incorrectly tri
Re: (Score:2)
Uh no, getting 10 minutes worth of work done in two weeks is a bad sign for an organization.
Re: (Score:2)
as a software developer I will refer you to the dictionary for the word `overhead` and dilbert for a business case example.
Re:Sounds like a fast response... (Score:5, Insightful)
No, taking the time to
(1) evaluate the problem,
(2) determine the best approach for a fix,
(3) weight the time commitment against any other critical activities going on,
(4) assign the best person to code it,
(5) review the code,
(6) rebuild and deploy it up through various testing environments,
(7) test the hell out of it in each environment, and
(8) deploy it into production
in a mere 10 work days is excellent, given the importance of the system. That's what Enterprise System timelines are often like.
If a major financial system like NASDAQ had managers run into the developer area and shouting "ZOMG someone fix this and slam it into Production now now now!", then I'd be more concerned.
Re:Sounds like a fast response... (Score:4, Insightful)
There is such a thing as too much process, this would be an example.
Besides all those steps should take a couple days tops.
Re: (Score:2)
Yup. A simple fast track for simple security problems.
1) work out solution
2) Implement & deploy solution as a hotfix same day
3) Spend 2 week massaging and validating the solution
4) Update the codebase with the validated solution (which may be identical).
How about the real story today? (Score:5, Interesting)
The NASDAQ today had it's 3rd significant pricing problem in the past few weeks.
http://www.nasdaq.com/article/options-exchanges-halt-trading-20130916-00868 [nasdaq.com]
These guys seriously need to improve their reliability.
Re: (Score:2, Funny)
Just remember, NASDAQ runs on Windows on days when things go wrong (it runs Linux during the rest of the week).
Re: (Score:1)
OPRA is not really an independent company. Yes, it is a company separate from the NASDAQ, however is is controlled by the exchanges that are members of it's plan. NASDAQ is one of these.
http://www.opradata.com/overview/opra_over.jsp [opradata.com]
Re: (Score:2)
So basically, it's a separate company in the same way that Chevrolet is a separate company from General Motors?
Reliability? (Score:2)
OH NO. Two whole weeks?!?!!11ONE!! (Score:2)
That's not too bad all things considering. Maybe they have a proper structured development shop (not too structured, since it obviously doesn't include code reviews or vuln scanning)? Maybe they had maintenance windows which they are contractually bound to (and more expensive to make an exception then to do deal with a flaw)? Maybe once they were made aware of the problem they were scanning the database system for odd entries or suspicious activity? Maybe they needed to get an independent audtor to revi
Re: (Score:2)
Two weeks is a long time for a few minutes worth of work. It is symptomatic of the kind of disease you find in all large organizations.
They could have implemented the fix before checking the DB or doing other auditing. Those things are not dependent on each other.
Re: (Score:1)
Agreed. Chances are there are a bunch of PMPs and ITIL processes in place. Could be internal politics.
Coding a few minutes is a one thing. Testing it, getting someone to approve to move something to prod, and herding people to actually do work is a bunch of other things. Legal and PR may get involved too.
In some corps I worked, the finger-pointing usually takes days and involves a bunch of crappy meetings. It can be days before someone engages InfoSec or the developers to confirm a problem.
Two weeks is
Who cares? (Score:5, Insightful)
So, it's the NASDAQ website. Who goes the NASDAQ website? You can't trade stocks there. Financial information was not leaked, so BFD. This is fairly common on any website. Sounds to me like a single security research got butthurt because they didn't acknowledge his finding quickly enough.
Re: (Score:2)
Re: (Score:3)
So, it's the NASDAQ website. Who goes the NASDAQ website? You can't trade stocks there. Financial information was not leaked, so BFD. This is fairly common on any website. Sounds to me like a single security research got butthurt because they didn't acknowledge his finding quickly enough.
Agreed. So they emailed NASDAQ. Who at NASDAQ? Who picks up and reads that email? Was it just the web site tech support number? That might get read only once a week if you are lucky. Unless they actually spoke to a manager/director at NASDAQ who is responsible for security, then they were not really talking to "NASDAQ."
Spam (Score:1)
I can basically say I've spammed them
Well, there's your answer.
NASDAQ web site != NASDAQ trading system (Score:5, Informative)
Re: (Score:2)
Re: (Score:3, Insightful)
the IT probably needs some slack (Score:1)
If, at NASDAQ, you create even a moment of downtime,
your ass is chewed, spit out, and handed back to you.
Fast enough. (Score:1)
I love how apparently everyone complaining about this must have mastered all unintended consequences.
Sometimes fixing a bug just isn't that important, even a security bug. Sometimes the stuff you break can be worse than what you fixed. This is why it may take 30 minutes or 2 days to fix the issue, but much longer to make sure you actually want to push it to production.
If they had private medical data or insider information that could be hacked by exploiting the issue I imagine they would have fixed it wit
So, bad Website design but what was the exposure (Score:2)
I realize it takes a few minutes to fix an individual XSS problem, but what was the vulnerability here?
NASDAQ says this from the article:
Nasdaq.com lets users create accounts and build a profile to monitor stocks and news. Nasdaq said it did not believe the flaw was used by an attacker, and no personal data was compromised.
"We responded to his concerns immediately," Nasdaq said in an email statement. "We take all information security matters seriously. We work with leading security vendors and have a trained and professional team that evaluates all credible threats across our digital assets."
So they took the information seriously, evaluated it and said that it didn't create a big gaping hole.
while they guy who notified them of the problem reportedly said:
Kolochenko said the flaw could have been used by an attacker in several ways, including stealing users' browser histories and their cookies. It could also have been used to inject HTML into a Web page and ask for people's personal details, a request that would appear to come from Nasdaq.
In another kind of attack, Kolochenko said the XSS flaw could be used to plant a link within the Nasdaq site to a malicious website.
Kolochenko said XSS flaws are common, and he has found ones in websites belonging to the BBC, Bloomberg and the Financial Times. Those organizations acknowledged the issues, but it was often a month or so before the websites were fixed, he said.
Yes, so XSS vulnerabilities are bad and it's up to the website owner to ascertain how bad it could be for their website on a case by case basis. It sounds like this guy spends his days however just digging up
Think about it (Score:2)
Of course NASDAQ could have fixed it immediately, but what very valuable information did they gather during the two-week window from first report to fixing it?
Why, all the info on all the zero-day crackers giving it a go during that period -- a massive sort of honeypot operation.
Think about it. Easy to plan the protocol for. Like flies to honey.