OnPoint by Keith Ng

Read Post

OnPoint: MSD's Leaky Servers

629 Responses

First ←Older Page 1 10 11 12 13 14 26 Newer→ Last

  • Karen Adams, in reply to Tom Beard,

    It takes ages to get through and I phoned around 10am. When I said to her that I had a secure file and was concerned her tone of voice was apathetic. She told me my privacy hadn't been breached to which I replied, "as far as you know". She just repeated that my privacy hadn't been breached and that they had been told that no Work and Income client files were involved.

    FYI they give unsubstantiated advice all the time so you end up getting told one thing from the 0800 line, then in the branch you are told the opposite. This happens often and is generally accepted as being just the way it is.

    Under your bed • Since Oct 2012 • 16 posts Report

  • duke, in reply to Martin Lindberg,

    No problem. Just drop a file with the same name into the open file dialogue box. Microsoft has effectively turned that dialogue box into a slim file-manager.

    It's been a while however I'm sure open/save dialog boxes call explorer.exe (Windows Explorer probably best known as via the 'My Computer' / 'My Documents/Pictures/Music' icons to noobs). Calling means uses; Windows apps (all? excluding java apps at least) call the file explorer to complete the save/open process. Copy/Cut/Paste are all valid either via right click or keyboard shortcut if not menu drop down.

    All very obvious as Keith clearly used this facility to transfer the files to his USB stick.

    As has already been pointed out this is an incredible display of either complete incompetence by the system implementer or top down endorsed mad fail.

    Since Jul 2009 • 24 posts Report

  • Matthew Poole, in reply to Hebe,

    Would that compromised security reach outside MSD and its files into other areas of government?

    It could potentially do so, yes. The reason I stepped up from WINZ to MSD is that there's quite possibly a trust relationship that extends to domain administrators, and even if there's not that level of trust there's probably sufficient trust to allow cross-domain sharing of files which could then extend a compromise. That's the nature of that particular operational relationship. If there are trust relationships further into other agencies, it could similarly be escalated. At some point this scenario becomes implausible, and I'm not willing to even start speculating on other agencies that might have the necessary relationships to expose this vulnerability, but I imagine there are some very worried InfoSec officers.

    Auckland • Since Mar 2007 • 4097 posts Report

  • duke, in reply to Tom Beard,

    Has anyone weighed in on whether this was due to kiosks with Admin privileges, or an MSD-wide problem where any employee could look anywhere on the network?

    +1

    I'm guessing the former. Someone made a big mistake on the template Kiosk image.

    Since Jul 2009 • 24 posts Report

  • nzlemming, in reply to Karen Adams,

    Keith's investigation did not touch case files. What he found was (what should be) mundane administration material, plus the odd security no-no - okay, lots of security no-no's.

    I want to reassure you, but I can't. If invoices contained identifying material for an individual, then there is some risk.

    Waikanae • Since Nov 2006 • 2937 posts Report

  • duke, in reply to Matthew Poole,

    If you can edit the file (that is, open it and then save changes), you can probably overwrite it with a file of the same name

    Yup. In case you weren't aware saving = write to disk. Hence read/write privilege.

    Since Jul 2009 • 24 posts Report

  • nzlemming, in reply to duke,

    I'm guessing the former. Someone made a big mistake on the template Kiosk image.

    That's my guess as well. Plus they were probably connected to the network to make bulk updating easier for the admins.

    Waikanae • Since Nov 2006 • 2937 posts Report

  • Hebe, in reply to Matthew Poole,

    Would that compromised security reach outside MSD and its files into other areas of government?
    It could potentially do so, yes. The reason I stepped up from WINZ to MSD is that there's quite possibly a trust relationship that extends to domain administrators, and even if there's not that level of trust there's probably sufficient trust to allow cross-domain sharing of files which could then extend a compromise. That's the nature of that particular operational relationship. If there are trust relationships further into other agencies, it could similarly be escalated. At some point this scenario becomes implausible, and I'm not willing to even start speculating on other agencies that might have the necessary relationships to expose this vulnerability, but I imagine there are some very worried InfoSec officers.

    Your answer means I shall upgrade my comment to Fucking Hell. Bad sleeps all round in Welly.

    Christchurch • Since May 2011 • 2899 posts Report

  • Keir Leslie,

    Mind you if I was in charge of infosec at a gov't department, I wouldn't be worried about possible secondhand spill over from WINZ; I'd be paranoid about everything in my own area

    Since Jul 2008 • 1452 posts Report

  • Martin Lindberg, in reply to duke,

    Yup. In case you weren't aware saving = write to disk. Hence read/write privilege.

    Yes, but I can't see that Keith tried to write/edit/save anything.

    Stockholm • Since Jul 2009 • 802 posts Report

  • duke, in reply to Matthew Poole,

    Bingo bango bongo, we have ourselves a winner. I believe that the entire WINZ network, and probably the entire MSD network, should be considered to be fully compromised.

    Let's not get carried away. I'll also bet the core CRM app is not directly affected by this issue (we hope).

    Though arguably if Admin passwords were compromised a skilled hacker could go nutts; he'd still need physical access to the network and a machine and a fair bit of quite private nerd time.

    Since Jul 2009 • 24 posts Report

  • duke, in reply to Martin Lindberg,

    Yes, but I can’t see that Keith tried to write/edit/save anything.

    Write = save = paste (kinda); which he had to do to put the files on the USB!

    Since Jul 2009 • 24 posts Report

  • TracyMac, in reply to nzlemming,

    I can't see how it would be anything to do with the kiosk image. I mean, sure, the fact the USB was unlocked is a concern from a workstation security point of view (viruses, anyone?), but may have been a requirement for other reasons.

    The hole will be related to what account is used to run the kiosk, whether that was baked in at installation time or (mis)configured later.

    ETA: if they used a domain admin-type account or something over-elevated to join the computer to the domain or similar, which wasn't subsequently changed, that's where the kiosk installation could be relevant. Still an account issue.

    Canberra, West Island • Since Nov 2006 • 701 posts Report

  • Martin Lindberg, in reply to duke,

    Write = save = paste (kinda); which he had to do to put the files on the USB!

    I was referring to the files on the network.

    Stockholm • Since Jul 2009 • 802 posts Report

  • Kyle Matthews,

    F**k. Me. That sounds like a serious amount of work. How long would it take to implement?

    Thousands of hours. There's some IT guys in Wellington who are having the worst day of their life so far, and it's not looking any better ahead of them.

    Since Nov 2006 • 6243 posts Report

  • duke, in reply to Hebe,

    It’s that bad? Would that compromised security reach outside MSD and its files into other areas of government?

    Potentially yes. However one would sincerely hope that this level of incompetence is not commonplace across our govt depts.

    Highly unlikely the breach has compromised systems outside of the MSD network. But without knowing the network topology and policies..

    Since Jul 2009 • 24 posts Report

  • TracyMac, in reply to Kyle Matthews,

    Regarding any remedial works, well, who knows if they'd go the full range of reimaging anything that could have been touched by that account.

    Definitely a full password reset regime for any admin/service accounts, and end-users asap. Full server scans for any malware/viruses, full file audit of any file store accessible from the problem account(s) with particular focus on anything potentially executable.

    That doesn't solve any backdoors, VM image SAM hacks or other exploits that may have found their way onto the boxes. How much money will they spend? Nuke from orbit, or do the basic remedial actions and cross fingers no nasty surprises will raise their heads later (high-9s likelihood this will be sufficient. Is that enough?)

    Canberra, West Island • Since Nov 2006 • 701 posts Report

  • Matthew Poole, in reply to Russell Clarke,

    they’ll have a case management system that has its own database, and probably does have some level of access logging going on. So while they’re probably dissembling about security in general, they might be more assured about the case records in the system.

    At this point I'm going to start scaring some people: if the database is backed by Microsoft SQL Server, what I said about a domain administrator being God still applies. And even if it wasn't MSSQL, if access credentials to whatever is the database platform were stored on the network and could be found...
    I'll caveat this by saying breaking in MSSQL will leave traces, but their being noticed relies on observant administrators.

    Auckland • Since Mar 2007 • 4097 posts Report

  • duke,

    Good ole RadioNZ just reported that the Kiosk system was previosuly audited by a private contractor (missed the name) whom obviously failed to detect the completely fucked implementation.

    Massive fail on top of massive fail.

    Since Jul 2009 • 24 posts Report

  • nzlemming, in reply to TracyMac,

    I can't see how it would be anything to do with the kiosk image. I mean, sure, the fact the USB was unlocked is a concern from a workstation security point of view (viruses, anyone?), but may have been a requirement for other reasons.

    If it was an actual built-for-purpose kiosk, you'd be correct. What it is, though, is an instance of Windows which has been customised by having certain options "removed". But you can't actually remove Windows Explorer - it's integral to the operation of the OS and applications rely on it. So they've just removed immediate desktop access to Explorer (not to be confused with Internet Explorer)

    These are not simple terminals from which you can browse an intranet, or the jobs listings. They are workstations that have been installed with a full OS. It will have been set up once by an administrator, copied to a disk image and deployed by sending that image to each of the physical workstations, which will then be rebooted.

    The hole will be related to what account is used to run the kiosk, whether that was baked in at installation time or (mis)configured later.

    If the sysadmin set the original machine up using her own account, her privileges may well have been inherited by the 'kiosk' image.

    ETA: if they used a domain admin-type account or something over-elevated to join the computer to the domain or similar, which wasn't subsequently changed, that's where the kiosk installation could be relevant. Still an account issue.

    It always was an account issue, due to it being about access to machines and files. The question is whether the kiosks are operating of an admin account, or whether all accounts that aren't personally allocated to staff have this sort of access.

    Waikanae • Since Nov 2006 • 2937 posts Report

  • rodgerd, in reply to Matthew Poole,

    As far as cross-domain trusts go... the moves to consolidate all IT for the government into one, centrally-managed "internal cloud" would likely only make it more likely that people will have credentials with God mode across many departments.

    As an aside on the whole fraud bit: I work in banking IT, and the general wisdom in the banking sector is that internal fraud is a large proportion of the fraud we have to worry about (e.g. the National Australia Bank branch member who nicked $5 million by making up a bunch of phony clients and signing off on their mortgages for non-existant properties as a classic one that made the Aussie papers). Most banks have a policy of requiring staff to take blocks of leave (1 - 2 weeks); the thinking is that most frauds require enough manual intervention that time spent away from work makes it likely your stand-in will notice something funny (as happened in the aforementioned NAB case - the fraudster went on leave and their replacement noticed a lot of letters going to the same PO Box every month for dozens of different customers, bit odd that...).

    The other thing that goes hand-in-hand with that is to have several people doing that same job, so that you would have to have multiple corrupt people, not just one.

    Of course, this requires you have enough "spare" staff that you have people able to take 2 weeks of leave in one block and do one anothers' jobs. If you've got hung up over "efficiency" and fired all the "dead wood" to save a bit of money, well...

    Wellington • Since Nov 2006 • 512 posts Report

  • James George, in reply to Matthew Poole,

    Well the chances of the national client database being implemented in M$ sql are slim to none. Much more likely that MSD would have hired contractors to design and build their own system and the contractors hired someone who had been involved in the design and build of a similar system in oz or england.
    A domain admin level logon could cause problems but whoever used it would not only need the physical access to the network someone else has already referred to they would also need to be be pretty familiar with MSD protocols and systems if they intended doing much more than the usual 'anonymous was here' stuff without detection.

    Since Sep 2007 • 96 posts Report

  • duke, in reply to TracyMac,

    I can’t see how it would be anything to do with the kiosk image. I mean, sure, the fact the USB was unlocked is a concern from a workstation security point of view (viruses, anyone?), but may have been a requirement for other reasons.

    The hole will be related to what account is used to run the kiosk, whether that was baked in at installation time or (

    Quite; this is def an AD (Active Directory to the curious non nerds) mis config. Apologies it seems multi tasking is not conducive to my root cause skills.

    However one would think the Kiosk image should have been locked down a wee bit more than it appears to be.

    Since Jul 2009 • 24 posts Report

  • Matthew Poole,

    Just got off the phone with RadioLive, who wanted comment and got some fleshed-out explanations in what was, I hope, lay speak. This is going to add an interesting complexion to things.

    Auckland • Since Mar 2007 • 4097 posts Report

  • duke, in reply to nzlemming,

    If the sysadmin set the original machine up using her own account, her privileges may well have been inherited by the ‘kiosk’ image.

    Nostalgic lol.

    S.W.I.M had great fun way back in school days achieving admin privileges by copying a local copy of the Admin profile on top of another non-admin login. Win95; those were the days.

    Since Jul 2009 • 24 posts Report

First ←Older Page 1 10 11 12 13 14 26 Newer→ Last

Post your response…

This topic is closed.