Slashdot Mirror


Security Company Says NASDAQ Waited Two Weeks To Fix XSS Flaw

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."

18 of 61 comments (clear)

  1. Very difficult. by d33tah · · Score: 4, Funny

    What are you laughing at, it's clearly very difficult to fix one XSS vulnerability.

    1. Re:Very difficult. by cbhacking · · 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.

      --
      There's no place I could be, since I've found Serenity...
    2. Re:Very difficult. by sjames · · Score: 2

      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.

  2. Sounds like a fast response... by CajunArson · · Score: 4, 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.

    --
    AntiFA: An abbreviation for Anti First Amendment.
    1. Re:Sounds like a fast response... by cbhacking · · 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).

      --
      There's no place I could be, since I've found Serenity...
    2. Re:Sounds like a fast response... by CodeReign · · Score: 2

      as a software developer I will refer you to the dictionary for the word `overhead` and dilbert for a business case example.

    3. Re:Sounds like a fast response... by QilessQi · · Score: 4, 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.

    4. Re:Sounds like a fast response... by h4rr4r · · Score: 3, 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.

    5. Re:Sounds like a fast response... by Em+Adespoton · · 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 triaged in this case, so the entire change schedule started late.

  3. How about the real story today? by the+eric+conspiracy · · Score: 4, 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

    These guys seriously need to improve their reliability.

  4. OH NO. Two whole weeks?!?!!11ONE!! by Lieutenant_Dan · · 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 review so they can appease their various stakeholders?

    Hopefully they learned from this, and will at least run an automated vulnerability tool against the app for future releases.

    --
    Wearing pants should always be optional.
  5. Who cares? by Gizzmonic · · 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.

    --
    (-1, Raw and Uncut is the only way to read)
    1. Re:Who cares? by Princeofcups · · Score: 2

      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."

      --
      The only thing worse than a Democrat is a Republican.
  6. NASDAQ web site != NASDAQ trading system by JoeyRox · · Score: 5, Informative

    nasdaq.com is a simple front-end fluff site for viewing quotes and doing basic company research. No critical systems or customer data.

    1. Re:NASDAQ web site != NASDAQ trading system by MXPS · · Score: 3, Insightful

      Seriously. With all the actual issues they have been having with trading system I'm sure the vulnerability on the website was the least of their worries. It is like saying FBI.gov or NSA.gov has a vulnerability so all our countries secrets will be exposed.

  7. good process is not trivial by Anonymous Coward · · 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 checks first does a check to see the vulnerability, then tests that code is really fixed, also validating that Geek's script isn't broken. Then does regression test to make sure that code isn't broken.

    QA schedules time with operations to meet and discuss deployment plan.

    Code is deployed to stage environment and tested some more.

    Operations then deploys the fixed code.

    1. Re:good process is not trivial by NatasRevol · · Score: 4, Funny

      In reality,

      Dev gets email, updates code, posts to live website.

      He's just 3 weeks behind on email.

      --
      There are two types of people in the world: Those who crave closure
  8. Think about it by Tetetrasaurus · · 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.