OnPoint: MSD's Leaky Servers
629 Responses
First ←Older Page 1 … 10 11 12 13 14 … 26 Newer→ Last
-
Karen Adams, in reply to
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.
-
duke, in reply to
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.
-
Matthew Poole, in reply to
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.
-
duke, in reply to
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.
-
nzlemming, in reply to
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.
-
duke, in reply to
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.
-
nzlemming, in reply to
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.
-
Hebe, in reply to
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.
-
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
-
Martin Lindberg, in reply to
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.
-
duke, in reply to
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.
-
duke, in reply to
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!
-
TracyMac, in reply to
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.
-
Martin Lindberg, in reply to
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.
-
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.
-
duke, in reply to
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..
-
TracyMac, in reply to
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?)
-
Matthew Poole, in reply to
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. -
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.
-
nzlemming, in reply to
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.
-
rodgerd, in reply to
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...
-
James George, in reply to
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. -
duke, in reply to
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.
-
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.
-
duke, in reply to
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.
Post your response…
This topic is closed.