NASA CIO Misses Little Things That Could Cause Big Problems
Raspberry Pi used to steal data from Nasa lab, BBC
“An audit report reveals the gadget was used to take about 500MB of data. It said two of the files that were taken dealt with the international transfer of restricted military and space technology. The attacker who used the device to hack the network went undetected for about 10 months. The malicious hacker won access to the Jet Propulsion Lab internal network via the Raspberry Pi by hijacking its user account. Although the Pi had been attached to the network by the employee, lax controls over logging meant Nasa administrators did not know it was present, said the report. This oversight left the vulnerable device unmonitored on the network, allowing the attacker to take control of it and use it to steal data.”
NASA OIG Finds Pervasive Problems With JPL Cybersecurity, earlier post
“Multiple IT security control weaknesses reduce JPL’s ability to prevent, detect, and mitigate attacks targeting its systems and networks, thereby exposing NASA systems and data to exploitation by cyber criminals.”
Report: “JPL did not have complete and accurate information about the types, location, and value of NASA system components and assets connected to its network. … The April 2018 cyberattack exploited this particular weakness when the hacker accessed the JPL network by targeting a Raspberry Pi computer that was not authorized to be attached to the JPL network.32 The device should not have been permitted on the JPL network without the JPL OCIO’s review and approval.”
NASA Needs A New Chief Information Officer, earlier post
“NASA’s CIO has been asleep at the wheel for years. Its time for a reboot.”
“Raspberry Pi computer that was not authorized to be attached to the JPL network” – I’m sure an IT person would say, this is why there are rules about connecting unauthorized devices to the corporate network. Doesn’t matter what the device is.
Probably, and it’s not a bad policy. But there is a corollary. The IT people need to provide sufficiently good support. Good enough that no one wants or needs to connect unauthorized devices. Years ago, I know of one case where a grad student hacked into the root account on a lab’s unix machines, to fix things the system administrators were too inept to fix (and too stubborn to let anyone else fix.) Stories like that aren’t uncommon and I have heard very bad things about the quality of IT support at JPL. So I’m not shocked someone would feel the need to connect a device of their own. That shouldn’t be necessary. Of course, if it was just whim or laziness by the user, that’s a different matter. But unauthorized workarounds to deal with poor IT support are pretty common.
Its probably worth remembering that Caltech is a university, and in many university engineering and science departments, what gets attached to LANs is pretty much a wild west situation. The IG’s report is right to criticize JPL management for not explaining and requiring cooperation from its employees in the implementation of NASA IT requirements. People have to see that their management buys in, and that there are clear consequences for failing to meet those requirements.
That’s not really accurate. Caltech does run JPL for NASA, but they are administratively very, very different. A fraction of the faculty have joint appointments, but not a large fraction. In terms of physical security, anyone can wander into any part of the Caltech campus. (Well, the offices and labs have locks on the doors, and you’d be asked to leave if you just wandered in at random. But a fair number doors aren’t actually locked.) At JPL, you can’t even get past the front door without a host (someone who works there) getting you on an approved list a week or more in advance. That’s for just wanting to stop by someone’s office to talk for an hour or so. And depending on who you are, you might need an escort everywhere you go (bathrooms included.) It’s been a while since I experienced their computer security, but friends who work there tell me it’s as restrictive as the physical security. Don’t think being managed by a university means university-style security practices. That’s not true of JPL. It’s also not true of the Applied Physics Lab (run by Johns Hopkins) or Lawrence Livermore or Los Alamos National Laboratories (both run by a Universities of California-led consortium.)
And, as a quasi-random shot at management, it would help if they gave up their priority when it comes to IT support. Officially or unofficially, at just about every institution I know of, IT people tend to drop everything when the boss has a problem. Even when it isn’t anything critical and the problem is clearly between the chair and the keyboard. The less senior people, like students, who may be doing something important and may have real IT problems, tend to be at the bottom of the priority list. That means, among other things, senior management tends to have an unrealistic view of the quality of their institution’s IT support. And that they are, in general, clueless about the benefits of and difficulties from any computer security practices they impose.
The story provides very little information as to what actually happened. Users cannot maintain security when IT management does not reveal what the problems really are. Obviously 500MB of administrative files were not stored on a Raspberry. How, exactly, did access to a single device provide access to user accounts on other systems? Were there weaknesses in the configuration of network servers? Was the “intruder” an employee or an outsider? Further limitations make researchers less productive. In an agency tasked with exploring the universe, computer use is so restricted ordinary users can do little beyond routine paperwork and commercial applications, but every IT security problem leads to more restrictions on all users and no explanation of how the breach actually occurred. A development network separate from the center administrative network might be an option.
Yes, the story doesn’t quite make sense based on my experiences dealing with JPL security. Even if someone is on a research network there, they’d still need TFA to get onto mission systems… likewise to access JPL at all from an external site. It seems unlikely that a Raspberry Pi would be of any help in cracking TFA. If the “hacker” were a JPL or NASA employee or external affiliate who already had mission system access that might make a little more sense. But then they could have done that from anywhere… not just from a JPL research network.
We can’t even access web-based email from offsite. Why not? I can access my [non-NASA] medical records from anywhere, in seconds, with (if needed) two factor authentication. Banks use it, airlines use it. I have difficulty understanding exactly what NASA felt the problem was. If there is really a security hole why not reveal it so it can be corrected?
“The use of Secure Sockets Layer, which ensures that all data transmitted between the web server and browser remains encrypted, prevented JPL’s network security monitoring tools from identifying the actions taken by the bad actor prior to detection.”
https://docs.google.com/vie…
Surely you jest! The only way the security system can detect “malicious activity” is if the webserver is not using https, the most basic of all security methods, and instead exposing passwords to be snooped anywhere on the network. ROTFL. We need to get beyond the idea that network security is somehow provided by cumbersome administrative controls or canned “security” software sold by slick salesmen and start explaining how the actual hacks were accomplished. Don’t worry about revealing the hacks to the hackers, they already know. The problem is that the users don’t know.