Major flaw in State of Pennsylvania online voter registration puts user data at risk

Major flaw in State of Pennsylvania online voter registration puts user data at risk

Summary: Update: Microsoft is NOT at fault for this! There seems to be some confusion within the talkbacks on this subject about this being Microsoft's fault, and also some strange claims that development shops who do only .

SHARE:
TOPICS: Security, Google
87

Update: Microsoft is NOT at fault for this! There seems to be some confusion within the talkbacks on this subject about this being Microsoft's fault, and also some strange claims that development shops who do only .NET programming are more likely to program insecurely. This is just, in fact, completely without basis.

This particular issue is an issue created by poor development practices, and that is all. This same flaw could exist in ANY web application programming language, and in fact, no application programming language gives a developer a significant advantage to NOT create an issue like this.This issue is around lack of authorization control, and since these voter registrations can be accessed by index with no authorization check, I can view anyone's information. That is it. There is no flawed feature in a Microsoft product, no Visual Studio use that causes this to happen, etc., so let's get over the vendor bashing at this point.

There's even been some strange comments that say things like, .NET makes it more likely that these parameters will get sent in the URL, thus creating the vulnerability. The fact is, it wouldn't matter if these were sent in the query string, a Post request, within the cookies, I could still catch it as it leaves my browser, modify it and access someone else's data. Not to mention that most applications simply wrap their doGet method within their doPost method, so you can actually send a GET request (i.e. where the browser sends data in the query string of the URL) INSTEAD OF a POST request.

The fact is, I've performed hundreds of application security assessments and I've seen no basis to say that a Java language/framework is more secure than .NET.

Original post begin:

Ok security people, we've been talking about it for awhile now, and here it is! Do you remember when you first heard about online voting? Do you remember thinking, geez, that sounds like a really bad idea? Well, your fears are confirmed.

The state of Pennsylvania online voter registration page has a major flaw that was discovered and mentioned on digg, the text of which is posted below:

Online voter registration PDFs are left unsecured on the server for anyone to access. Simply change the request ID at the end of the URL. Valid IDs appear to be working from 50000 and up to 58500+ This was discovered after filling out a registration myself. Being a security conscious programmer, I decided to test. Very bad PA...very very bad!

The entire application has since been replaced with a message that says the site is temporarily offline, but the basis of the flaw was that an attacker could force the application to retrieve arbitrary PDF voter registration files of other voters by simply modifying a request parameter sent in a request to the PrintVoterApplication.aspx page.

This reminds me a lot of the work that Billy Rios has helped Google out with, as referenced here, here, and here. In these examples arbitrary user's documents could be stolen from the Google Docs application.

This particular example; however, seems to be quite a bit easier to exploit than the Google example, as you simply can increment or decrement the application id parameter, whereas Google had some form of randomness to the value. There's another thing to consider here, the Google issue was not so straightforward, and was therefore discovered, reported, and then Google's Security Team took care of it real fast cause they're a strong team. In this case, the State of Pennsylvania's site was up and running with the vulnerability fully reported on Digg... who knows how many user records could've been viewed during this time. Additionally, I'm not sure the issue has been addressed in terms of a fix, basically it just looks like the applications functionality has been turned off.

The details are very unclear (i.e. no screenshots that are currently posted), but it seems straightforward to exploit if the server was still accpeting requests. The request looks something like the following:

https://www.pavoterservices.state.pa.us/Pages/PrintVoterApplication.aspx?LanguageCode=en-US&ApplicationID=50001

Where the ApplicationID parameter (which I've bolded and italicized) can be modified from your own application id to that of another user.

Perhaps it's only reasonable in my perfect, Utopian vision of how the world should be, but I'd love to think that the government of the country that I love is doing a bit more to enforce security of its citizen's data. One would think that this would've come up in an application security review if the reviewers had any skill at all.

-Nate

Topics: Security, Google

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

87 comments
Log in or register to join the discussion
  • Common

    This is a common phenomenon, happens to MS-only shops.

    You get a 'developer' who only knows Microsoft technology. (aka: Softie).

    Since Microsoft stresses ease of use (they don't do complexity well), you get the point and click 'developer' with a point and click solution.

    ASPX is ASP .NET - Couple that with the fact they failed to catch this on before it went live and you can almost assuredly conclude that this is a Microsoft-only shop.

    Reminds me of the story where a router failure stranded 20,000 travelers for 10 hours.
    http://blogs.zdnet.com/projectfailures/?p=346

    -Mike
    SpikeyMike
    • What a joke

      Your post, not the issue mentioned in the article.

      Could be they hired a "I'm a Linux network GURU!" kind of guy and he was out of his league?
      GuidingLight
      • Well then...

        Seeing as the form in question is .aspx, then it's far more likely the op is right about it being a windows coding issue than you are that they hired a "linux network guru" to code for a windows-based system.

        Joke? Well, your response wasn't well thought out, or humourous.
        zkiwi
      • The Joke is..

        That you somehow perceive .NET to be in a better 'league' than what a Linux developer would use.

        .NET is the joke, as is everything that is 'Windows Only' - kinda like you.

        -Mike
        SpikeyMike
        • you are the joke, actually

          you are just here to bash ms regardless of if its warranted.

          wake up already moron. microsoft made the tools, the buffoons who developed the software with them are at fault. you can create a secure system with .net, but they didnt bother to. so you blame ms? good grief you are dense.

          the blame lays squarely on the developers, not ms.

          are you also one of those fools that blames every shooting death on the gun makers?

          your burning hatred of ms is evident, and your self appointed title of enlightenment is a hoax because of your blind rage causing you to blame everything on them.
          JamesDoyle
      • Clinton paranoia at genuine free vote

        causes thermite deposits on computer vote validation machine.
        fr0thy1
      • Or a Windows twat pretending to know Linux

        like you.
        fr0thy1
    • Blame the coder, not the tool

      Anybody, including a "Softie," could implement the same exact thing in PHP. Microsoft, Visual Studio, and ASP.NET did not cause this problem.
      eljay001
      • Well, I'd prefer to

        Apply electrodes to particularly sensitive parts of the anatomy o the system designers, managers and testers before amusing myself with the coder(s) in question. After all, most coders are not encouraged with treats or shiny toys etc to question what they are told to code and the requirements for the code.
        zkiwi
      • Yep, which is exactly what the previous poster did.

        He blamed the coders.

        He also concluded that the coding was done by a Microsoft-only shop. My experience is that any organization which uses ONE AND ONLY ONE TECHNOLOGY is going to be less experienced and more trusting than one which has experience with diverse environments and platforms, and since it's clear this is a Microsoft-based system, his conclusion has some merit.

        Of course, he's making the assumption that this was done by some sort of coding shop, and not by some in-house admin/developer/gopher. Personally I think that's a more likely explanation.

        GuidingBlight's stupid brainless remark about Linux admins somehow being to blame is rightfully dismissed as utter crap, since it's 100% clear we're talking dotNET here.
        bmerc
        • It's a Team Effort...

          There are a lot of pieces and personnel involved in the development life cycle. Can't just blame one person/area. I've done my share of coding, testing, PM, and while I am no longer in the field, I still realize there are plenty of reasons this could have happened. One big one might be timeframe and associated pitfalls with cutting something short. If I had a nickel for every time we had to scramble to develop something because the product had been sold by the marketeers before it was even mentioned to development...What happened in PA can happen anywhere, and to anyone. Just my two cents.
          EugeneTheJEEP
      • Blame The Coder?

        Funny, but "the coder" has to make due with the tools at hand, and MS tools are notorious for being less than secure... URL's that access applications requiring information to be parsed expose way too much of that information to those who know what they're looking at, and for... This isn't a coder's fault, this leans heavily on the software used to write the app itself.
        EnKrptyed
        • RE: Think about it

          This issue is entirely at the hands of the developer. No technology can implement authorization FOR YOU. You have to code the application in a way that requires authentication and authorization to view sensitive documents so that a user can only view his own... this is not a fault of the technology.

          -Nate
          nmcfeters
          • Are you sure?

            "No technology can implement authorization FOR YOU."

            So you haven't worked with Rails yet, I see.
            erikmidtskogen
      • The "tool" makes non-coders - umm, "coders"

        there's a saying - "You pay peanuts, you get monkeys"

        In the IT world it should be "You pay monkeys then wonder why they produce peanuts"
        fr0thy1
    • blah-blah-blah

      If that were the case, the Apple would be the worst OS in the history of computing! Your logic doesn't hold when examined by someone with an iota of intelligence.
      The most likely scenario is probably a lack of a qualified QA department, poorly documented resources and feature creep. Couple this with the lack of urgency all government employees are ingrained with (no government employee posesses the ability to "hussle" when needed) and the "just get it done, I don't care how" attitude of untrained middle level managers and you have the makings of a perfect storm.
      You can most likely chalk this entire problem to budget cuts and offshoring.
      Ed
      web/gadget guru
      tech_ed9
    • RE: Common

      I can't believe that anyone would make the claim that this is a Windows only issue. Wake up and get over your platform biases... this could've happend in any web application programming language, and in fact, the usage of .NET in this case makes you no more vulnerable to this issue than if you were using Java, PHP, ColdFusion, Ruby on Rails, anyother damn thing.

      It drives me crazy when people take real talks and digress them into vendor wars for no reason.

      -Nate
      nmcfeters
      • Everybody's equal, but some ARE more equal than others

        You're right, it could have happened in just about eny environment. However, two relevant facts can't be simply spun away:
        1) While there are numerous experienced and conscientious Microsoft developers, the 'click and drool' bottom-of-the-barrel is far more prevalent, encouraged by management cost-cutting and by the general inflexibility of the Microsoft interface.
        2) A lot of the Microsoft tools (and several non-MS tools, too) will default to putting all parameters in the URL. In many places, that's noticed and worked around, but my experience in a lot of Microsoft-only shops is that management treats it as a "don't-care" and won't allocate time/budget to do things The Right Way.

        In other words, it's a management and skills issue masquerading as a technology/vendor issue. The fact that the vendor's technology goes out of its way to not only enable this, but encourage it, is why people who care about security tend to become ABMers pretty quickly.
        Jeff Dickey
      • Yes, but...

        What you say is true, in theory. It is perfectly possible to do great stuff with Windows technologies, and you can also do horrible stuff with the alternatives.

        But in the real world, technologies that are more flexible and powerful, and which have a higher barrier to learning tend to be used by people who come from a more serious IT background. If the only barrier to entry is the ability "drag and drool" some forms together and do a little "code-behind" using whatever homespun techniques pop into the mind of the "computer guy" doing his first web app (pass-through SQL queries, anyone?) then you can be sure you'll see some results that suffer from security vulnerabilities and many, many other gross defects.

        On the other hand, anyone who has sufficient expertise to configure an ORM framework such as Hibernate and code to the Spring IOC framework is almost certainly not a green developer who would be likely to make silly mistakes like the one outlined in this article.
        erikmidtskogen
        • RE: Don't agree

          I just don't get the baseless bashing of .NET. The same "drag and drool" technology is also possible in several Java based platforms, such as MyEclipse. Please don't tell me that you are going to say PHP or ColdFusion are more secure than .NET, if you say that I'll just say you've never done a web application pentest on one of those systems (i.e. see variable scoping issues in ColdFusion and blatant command injection issues in PHP).

          I've coded web applications in both .NET and Java and I've found it no more difficult to code in a secure fashion in .NET.

          Your point on using Hibernate or any other ORM-based query is well taken, but you just as easily could use PreparedStatement or parameterized queries in Java and .NET respectively. Also, FYI, ORM-injection is also a posibility if a coder doesn't have his wits about him/her (go search it on OWASP). Even with secure database access models like Hibernate, PreparedStatement, parameterized queries, etc. it's possible to totally screw things up and leave yourself vulnerable to SQL Injection.

          Although, that's not even what we are talking about here. Please name me any technology in Java, PHP, ColdFusion, or any other web application language that would've made you by default secure to the issue in the State of Pennsylvania site. There's not a one that exists to my awareness. SO, again, this is NOT a Microsoft issue, so we should save the Microsoft bashing for another day. May as well bash the milk man and say it's his fault, it makes about as much sense.

          -Nate
          nmcfeters