Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security Medicine Privacy

'Incompetent Developers' Blamed For NZ Patient Privacy Breach of COVID-19 Vaccine Booking Systems (stuff.co.nz) 54

An anonymous reader writes: The New Zealand Ministry of Health has launched a "sweeping review" of the nation's COVID vaccine-booking system, after a data breach led to exposure of personal information for more than 700 patients. A whistleblower reported over the weekend that they could access information about other patients, which was "readily accessible within the public-facing code of the website" -- apparently hard coded.

As a response, the Ministry of Health has ordered a review of all systems made by the developer, Valentia Technologies, which also makes software used by the Ambulance service, many GP practices, and the managed isolation and quarantine system.
"It is not a coding error. It is incompetence. The developer who developed this is incompetent ... This is basic stuff," said the man who spotted the booking system problem.

"The source code of the website, flagged a few concerning features, including someone's name, and an NHI number hard coded into the website, for what reason? I don't know," he said. "We could see everyone's details. We skimmed through, we didn't look at names, but their names, dates of birth, NHI numbers for those who entered them, contact details, where they were getting their vaccinations, what time they were vaccinated."

He said it appeared that Canterbury DHB had used a modified internal system to create the booking system. "You can tell by the source code, this was never meant to be a public facing website. This was only for people to use on like iPads, in doctors' surgeries, it was not supposed to be for this."
This discussion has been archived. No new comments can be posted.

'Incompetent Developers' Blamed For NZ Patient Privacy Breach of COVID-19 Vaccine Booking Systems

Comments Filter:
  • I this is the norm (Score:5, Insightful)

    by AlexHilbertRyan ( 7255798 ) on Monday March 29, 2021 @07:56PM (#61215482)
    I think if most people tried or had a look at the source of most systems they would be shocked how terrible they are. I use varous sytems in my life, bank websites , online shopping and its just amazing how bad they are, and how many things they get wrong. If they cant get basic public stuff working correctly guess what they are also probably bad doing the important stuff like security and privacy.
    • Agreed (Score:5, Insightful)

      by raymorris ( 2726007 ) on Monday March 29, 2021 @08:24PM (#61215574) Journal

      Part of what I do is training devs to do code review, and I do some security reviews myself. Code sucks. Most code is pretty much crap.

      A couple of weeks ago I attended a sales demo of an expensive system that's supposed to look for security problems in source code (static analysis). It's one of the most-used commercial static analysis tools. I looked at the remediation suggestions (fixes) for three of the problems they demoed. Of the three, one was half wrong and the other two were fully wrong. So even the tool that's supposed to teach programmers the right way to do things itself scored 17%.

      It doesn't have to be this way. When building things other than software systems, we have a process that works for specifying a design that is correct, a design that will meet the requirements. That process is called "engineering". The process of engineering is notable by its use of well-established principles, such as formulas for calculating load-bearing strength, in order to specify a design that will meet requirements. There is no reason software systems can't be engineered, just like other constructions are.

      • by G00F ( 241765 )

        but agile and devops!

        and who cares about the whole test cycle and stuff anyways, we fix things to fast to care. And who cares about long term stability we want impressive features and stuff management can brag to upper management about.

        • Agile does help, but lets face it, most people write terrible code and a good demostration of this are their tests or lack of them. Just look at any random github project a very large number dont have any tests, and at least 80% dont have even a single line or two describing what the project is about or any kind of detail. Everything is too hard to do, people are too lazy etc.
      • by MobyDisk ( 75490 )

        May I ask the name of the the tool? There are good ones out there but they are pricey and require quite a time investment. Coverity is amazing, and SonarQube is less powerful but super easy to integrate into a CI system. I dismissed Fortify on Demand when it flagged every use of the word "key" as possible security problem. With Coverity, it is fun to watch a skeptical developer start with "Oh, that's not really a problem because the tool doesn't know that..." then 5 minutes later go "Oh we need to fix t

        • From my own experience lgtm. Like all tools you sometimes want to have a check ignored for a method or line of code just because. THe problem is their documented way of ignoring a line half the time doesnt work. After doing the checks and making sure they are accurate surely your skip/ignore feature sholuld itself work.
        • Veracode is the one that had bad recommendations.
          Their rep said they focus most of their energy on integrations.
          It shows. It looks like they do a good job integrating with a lot of different stuff. It's just that they make it easy to integrate their poor quality product with all of your other systems. :)

          From your post, it sounds like Coverity may be the one we should look at. Personally I'd go open source but my boss tends to prefer to pay for a well-supported product.

          In our case, sast is new to our devs

      • Exactly most code reviews in the org i have been are a joke. For example if its groovy they will complain if you add the optional semi colon, but they dont care if there are zero parameter checks with meaningful messages. Who cares about an extra semicolon in source that is irrevelant i m more worried that error messages are present, accurate and actually useful.
      • There is no reason software systems can't be engineered, just like other constructions are.
        The primary reason they aren't is money, which is also the secondary reason. And the tertiary. I worked in a place that did software development that way. Gather all the requirements. Then define exactly what the software does so you can figure out what things are required that weren't written down. Then, having spent 1 or 2 years iterating this process (for anything non-trivial)to lock down all the requirements,

        • It seems to me you described a a process that developed a large system as one big monolithic thing, rather than iteratively building modules or functions (aka agile).

          That has little to do with the difference between engineering a module vs sloppily throwing something together that seems like it kinda mostly works, most of the time.

          Come to think of it, most of the software projects have been a process of build, release, release, build, release, build, release. They've also been engineered to one degree or an

      • by Zangief ( 461457 )

        Engineering has nothing to do with security.

        I can assure you the World Trade Center was perfectly engineered and all the load bearing strength calculations were right.

        But engineering could not save them against someone crashing planes into the side of the buildings. Engineering cannot save your padlock from being open by raking it, or stop you from being assaulted just outside of your perfeclty good house with an electric fence.

        • Engineering is a process that designs things to actually meet the requirements. (And not waste a lot of time and money doing things that aren't necessarily in order to meet the requirements). If reliability aka security is part of the requirements, engineering for a robust system will give you a design for a robust system.

          > Engineering cannot save your padlock from being open by raking it

          Funny you mention that; I used to be a locksmith.
          Try raking a Masterlock #3. You'll probably find that it's pretty e

          • by Zangief ( 461457 )

            googling medeco lock vulnerability says that they can be opened in 30 seconds

            they are probably very secure, but you have to keep updating your -physical- lock if you are very lucky, and your padlock provider decides to keep up with the security community

            and god help you if you put the padlock on a fence and someone jumps over the fence. all that engineering for nothing

            problem with engineering is that you have to list the requirements BEFOREHAND; if someone comes up with a new way of raking your padlock, all

        • Your example is silly because it coul dnever be predicted. However most sofware is equivalent to constructing a building and not bothering to put any doors or locks. It really is that bad. Its a bit like those old movies where some kid with an Apple IIE somehow manages to connect to a bank by guessing phone numbers and bingo they have menus for everything. Today the phone line guess is replaced by guessing urls, again with tools you can automate this boring task. Most people just dont care, they do less th
      • by fuzzyf ( 1129635 )
        This seems to be more of a company problem than a developer problem.

        It's shitty to put all the responsibility for this on developers. They can't really stop management from doing shortcuts like; "let's reuse the inhouse solution we made for another client".

        I work with security reviews, secure coding education and pen.testing. Developers are rarely the problem, they want to produce good solutions and are happy to get help doing that. But you need support from management and the organisation in order for
      • There is a key difference. It took me a long time working as a software developer to realize this difference.

        Engineering in other fields is driven by standards. 90% of engineers in other fields basically apply well known solutions. Regular engineers aren't out there building a new kind of experimental bridge for example. There are bridge standards and a few variables they might play around with.

        I'm exaggerating this for impact, so please understand I am not in any way downplaying the job of regular enginee

        • > For example, this is a basic appointment booking website. Let's be frank. This is not a new amazing design. This is a well solved problem by so many companies, both in the cloud and enterprise deployments.

          Exactly. Fairly early in my career, I was taking various jobs programming all different kinds of web sites. Stores selling various things, where you could search by different parameters, porn sites, mailing list sites ...

          I just lied to you. I said "programming all different kinds of web sites". That

          • So why aren't you rich?

            One of my former neighbors became (perhaps briefly) very wealthy by founding a company that automated building e-commerce websites for people.

            • > So why aren't you rich?

              What makes you think I'm not? :)

              I would be about 20X as rich if I had done a few things better in running my companies.

    • Hehe. I went to China a couple of years back, and when I was coming home, I was doing my damndest to check into my flight at the airport in Shanghai. I kept poking the screen to type in my confirmation code, but it would not do it. It took me a few minutes of making sure I wasn't posing my mind before I realized that while every on-screen keyboard I've ever encountered in the US allows a tap anywhere on the bounding box of the key to count, the one in China required a tap directly on the glyph inside the ke

      • Without knowing how close the keyboard keys are, i think the chinese method is better, because if the keys are too close, it will lead to bad key hits if you hit the boundary box and your finger might actually be too close and touch two keys, and the software would be confused etc.
    • The problem is that there is almost no way to know how to do build something the right way. Today's tech stack is a gospel from Google, Facebook, Amazon and if it is web-based it is mostly Google. And Google keeps changing it so that everyone is always catching-up.

      You can't read the books because by the time a book comes out the tech is already dated. You can't read it online because there is hardly any documentation anymore (again, thanks to Google).

      The current tech world is designed to make sure intellige

      • Amazon ? THey dont do much o/s and if you are using their prop s/w, well thats another story and world of pain.
    • Hey..I’m under your control. Let’s have a great time together >> https://utka.su/profile7942 [utka.su]
  • and with an NHI number I can bill the govment for fake doctor servers at least the patient get's an zero bill.

  • by Gravis Zero ( 934156 ) on Monday March 29, 2021 @08:20PM (#61215554)

    Yes, there can but shitty developers but the developer is just doing their best. The real question is who hired this person and why? Is HR actually completely clueless when it comes to hiring developers? Fire HR and find someone who can vet developers. Was it management who moved an inexperienced developer to a critical role? Fire management for being complete boobs.

    This person clearly wasn't qualified for the position so the question is, who the fuck put an unqualified developer in that position?

    • Re: (Score:2, Insightful)

      by mrpoponz ( 1997900 )
      I'm sure the person was probably told just do it anyway after explaining to their boss why it wasn't a good idea.
    • This person clearly wasn't qualified for the position so the question is, who the fuck put an unqualified developer in that position?

      (Training Instructor at the Six-Minute-Code-For-Dummies Institute) "I don't know what you're talking about. My graduates are of the highest caliber.."

    • by antdude ( 79039 )

      Also, money. They're probably too cheap to get good developers.

    • That, and project management pushing to get things done as fast as possible:

      • - Does it pass all the tests as stated in the contract?
      • - Yes but we might have cut a couple of corn--
      • - SHIP IT!
  • If you have investigated and decided that the root cause of a problem is "human error" then you haven't investigated at all.
  • by youngone ( 975102 ) on Monday March 29, 2021 @09:32PM (#61215736)
    For a bit of background, the Canterbury District Health Board has multiple, severe problems and experienced staff have been leaving in droves because of the terrible way it has been run for a couple years now.
    This is just another management failure, but I'm not confident anything will change.
    • by Xylantiel ( 177496 ) on Monday March 29, 2021 @10:03PM (#61215800)
      And notably this is not and never was the system that will be used for nationwide vaccine registration. This appears to be a local organization repurposing an internal-only system in a way that it was never intended to be used. Other organizations use the same system but the only people with access to it are employees.
  • Never every assume your quicky implementation won't become the production deployment. I've seen it happen many times.

    There's the first quicky version that worked and persuaded management to go forward with the application development.
    Then there's the real application. It doesn't work yet, it's late and the external vendors are playing hardball with the pricing.

    I've seen this happen on my own stuff. A wrote proof-of-concept code for a thing. The plan was to outsource the real thing to someone else.
    Plan A: Sign with vendor X
    Plan B: Sign with vendor Y
    Plan C: We're screwed and need to buy some servers and put the quicky code online.

    Now this was not an online tamagochi game. It was a CA - A certificate authority. It's a good thing I didn't assume I didn't need to do security due dilligence on the original code.

    • by rossz ( 67331 )

      Never every assume your quicky implementation won't become the production deployment. I've seen it happen many times.

      So true.

      Me: That concludes my demo. Keep in mind this is proof of concept. It can't stand up to load and lacks proper security.
      Manager: Let's use this. No need to expend more resources on it.

  • by AlexHilbertRyan ( 7255798 ) on Monday March 29, 2021 @10:42PM (#61215890)
    One of the top three causes of all crap code is the magic copy paste. From thet ext in the article they "copied" some project from somewhere else, and well to continue with their find tradition of laziness and general incompetance they made a complete mess of it all. If someone does too many copy pastes of code or anything its a good warning for me, i can tell they will also be lazy and make a lot of similar mistakes.
  • by OrangeTide ( 124937 ) on Monday March 29, 2021 @11:34PM (#61216006) Homepage Journal

    Who is to blame if you hired developers and no security experts to train them how to code defensively. Or to advise project managers on how to add threat modeling to your development process.

    I guess it's just unavoidable. We'll throw our hands up and let the same damn thing happen the thousandth time in a row. Can't be helped.

  • Never meant to be public? Come on, really? Unless this was meant to run on an air-gapped machine, zero-trust security approach should apply - everything outside of your own process is untrusted, sensitive data needs to be protected, configuration and calibration data needs to be authenticated and possibly encrypted, etc, etc. .

    Of course, I suspect the problem is the government official making the choice based on cost. When looking at:
    $2M - working booking system
    $30M - looks the same as the $2M option, but u

    • In-game skins == pay for "something new"

      Security patch == pay for your error (same as cars recalls... free of charge because it's a manufacturing error)

  • by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Tuesday March 30, 2021 @04:08AM (#61216404)

    Don't blame your incompetence in leadership and software project planning on your underpaid and overworked junior coding n00bs.

  • by PPH ( 736903 ) on Tuesday March 30, 2021 @10:31AM (#61217342)

    Great. Now our HR department will be looking for candidates with 5 years experience working with Incompetent.

  • Oddly enough, dumbass politicians seem to think that coding requires no intelligence or skill or education. Maybe coal miners and pipeline workers can become doctors or lawyers too.

To be awake is to be alive. -- Henry David Thoreau, in "Walden"

Working...