
NASA Has Been Hacked - kevinguay
https://www.forbes.com/sites/daveywinder/2019/06/20/confirmed-nasa-has-been-hacked/#7dbe7dc0dc62
======
SamuelAdams
I highly recommend reading the actual audit[1]. There's a lot of good details
in there, similar to the Senate report on the Equifax breach a few days ago.
There were several problems: the inventory tracking issue was particularly
enlightening:

>system administrators did not consistently update the inventory system when
they added devices to the network. Specifically, we found that 8 of 11 system
administrators responsible for managing the 13 systems in our sample maintain
a separate inventory spreadsheet of their systems from which they periodically
update the information manually in the ITSDB. One system administrator told us
he does not regularly enter new devices into the ITSDB as required because the
database’s updating function sometimes does not work and he later forgets to
enter the asset information.

Other good notes

Lack of training:

> NIST requires that organizations provide security-related technical training
> specifically tailored for their assigned duties... As of April 2019, JPL did
> not have a role-based training program, provide additional IT security
> training for system administrators, nor fund their IT security
> certifications.

Refusing to let Department of Homeland Security (DHS) complete a thorough
post-intrusion assessment:

>However, according to NASA SOC personnel, JPL was concerned with inadvertent
access to its corporate network and feared disruption of mission operations.
In addition, JPL was unfamiliar with DHS’s standard engagement procedures.
Collectively, resolution of these issues resulted in DHS being unable to
perform scans of the entire network until 4 months after the incident was
detected.

[1]:
[https://oig.nasa.gov/docs/IG-19-022.pdf](https://oig.nasa.gov/docs/IG-19-022.pdf)

~~~
jeffmould
Back in the early 90s I had a summer internship for a contractor at Goddard
Space Flight Center. My job for the entire summer was to track down and
inventory a list of 1000s of devices across the entire campus. At the time
they were building a tracking database for all the devices on the campus.

The printout I was handed on my first day had not been updated in several
years. It basically contained a tracking ID, what building/room the device was
supposedly located, and who it was assigned to.

I spent every day walking building to building, room to room, interviewing
employees, trying to track down devices. I never finished updating the list
simply because I was never able to track down over half the devices. Outside
of a few secure areas I did not have access to, I pretty much turned the
campus upside down looking for devices. I can only imagine where all those
devices ended up.

~~~
cbsks
I interned at Goddard in 2006 and my PI had a rogue wireless access point for
his interns to use. Apparently it was a long and convoluted process to get
network access for personal computers, so he didn’t even bother trying. I
remember some of my fellow interns complaining about having to work offline
for the first month of their 10 week internship.

~~~
dvtrn
_it was a long and convoluted process to get network access for personal
computers, so he didn’t even bother trying_

"When people can't work with you, they _will_ look for ways to work _around_
you". - former IT boss of mine.

Every time.

~~~
borumpilot
Cool thing is: with that argument I was able to convince management to roll
out WiFi worldwide at a large corp where the CISO hated WiFi and had halted
all projects that sought to implement it.

Needless to say, there where dozens of rogue AP's in the network, which where
a biatch to find (was a manual job actually walking around with a laptop
trying to find them). With the global rollout we made sure "rogue AP
detection" was implemented as an additional feature, which came with its own
challenges (sometimes not knowing something is easier to deal with...).

------
tetha
Reading the audit, this kind of confirms my base question when building
infrastructure: If people don't do the right thing the business needs, why is
it too hard to do? Can't we reduce the pain to do the right thing so doing the
lazy / wrong thing is harder? People not doing thing tends to be an indication
of boundaries and responsibilities being drawn in bad ways.

Something like the log reviews are a classical thing. Training a sysadmin to
know all the new hot attacks and patterns they cause in a log is hard, because
that world moves fast. It'd be much more effective to task the admin with a
well-defined, easily monitored task: <Ship logs to splunk. Make sure logs are
always shipped to splunk>. Might need some definition about format and which
logs, but all logs go to splunk. And then it's the security guys job to look
for malicious patterns in those logs, probably automatically. Ideally with
something simple, like elastic-alert, logstash, you name it, from my own
stack.

Similar, why do people have to manually enter systems into the host database?
It depends on how far you want to automate that, but firewall all systems to
access the central registry only, and widen the firewall after an authorized
registration of the system. That way, the admins just have to rack systems
with a usb stick with some credentials, and it goes or it doesn't.

If basic things are so hard people don't do them, something is structurally
wrong.

~~~
txcwpalpha
> but firewall all systems to access the central registry only, and widen the
> firewall after an authorized registration of the system. That way, the
> admins just have to rack systems with a usb stick with some credentials, and
> it goes or it doesn't.

Someone first has to build this system, and after accounting for all of the
red tape and approvals and training and new audits required and tallying up
the total man-hours required to implement, your solution that is supposed to
be "less hard" might actually be much _harder_ than the previous system.

It's pretty easy to come up with a multitude of ideas to fix issues like this,
but it's another thing entirely to actually implement them, _especially_ in a
big government org like NASA. Obviously their current/previous system isn't
working and they need to fix it, but I think you would be surprised at how
difficult it is to do something even as simple as the system you've
conceptualized.

Just to give a small anecdote: I've built asset management systems, and in one
case at a major F500 company, one that used USB sticks for something similar
to what you're describing. Just getting the approval to purchase the USB
sticks and establish a process for properly handling the USB sticks once
credentials were put on them was something that, _by itself_ , took _months_.

~~~
tetha
Yeah, size is one matter, technology focus is another one.

We've been acquired by a bigger shop with a lot less technology focus and
exactly what you're describing is already happening. Things that should take 2
month waiting for customers already takes 1 month of planning and 2 month of
scheduling the person that might be able to schedule the task of 2 month
within the next 6 month or more probably never. It's a soft spot for me atm,
because if that's the new norm, it'll be time to leave a lot of work behind.

------
chacha2
Wow. Try to opt out of their data tracking, an option they're required to add.

"This may take up to a few minutes to process"

They make you wait at this long ass loading screen while they "process" your
request not to have cookies.

Here's the outline for people who don't want to wait minutes to read an
article. [https://outline.com/TZSBv4](https://outline.com/TZSBv4)

~~~
LeonM
I discussed this recently here on HN [0], the fake spinner is a dark-UI to
'punish' you for opting out. If you just accept the popup disappears
immediately.

[0]
[https://news.ycombinator.com/item?id=20131381](https://news.ycombinator.com/item?id=20131381)

~~~
pdpi
I don't think that's actually true. Rather, it's an architectural thing —
because all these ad systems were designed without consent in mind, accepting
is a no-op, whereas refusing consent requires an outbound request to set some
sort of "do not track" flag somewhere (presumably as a cookie).

~~~
tjoff
If accepting is a no-op then you are being tracked even before you make your
decision - as the page already have been loaded.

A brutal violation of course but I absolutely expect that to be the case.

~~~
Wowfunhappy
Perhaps the purpose of the spinner is to delete the data they've already
collected?

Are you still being "tracked" if all copies of the data are destroyed?

~~~
_underfl0w_
That depends on who is doing the actual tracking/correlation and, assuming
it's a third party, how quickly the site hands that data off.

------
module0000
Hopefully, this doesn't cause fear mongering around raspberry pi devices. It's
not a stretch to imagine a bureaucrat reading articles like this, seeing _" a
raspberry pi was plugged in"_, and forming a negative opinion of the device
and people that use them.

~~~
neuralzen
Unfortunately there already is. When I interviewed for a job in Antarctica we
had discussed methods of saving on bandwidth usage and I suggested the use of
a PiHole to strip out ads to save precious KB and was told that the Raspberry
Pi was frowned upon due to previous issues, and it would likely never happen.
:(

~~~
SolarNet
Then just use a server that does the same thing. If the issue is the buzzword
then work around the buzzword.

~~~
coolspot
Yes. Small ARM-powered server. Preferably not expensive, around $35.

------
gfodor
I usually roll my eyes at meta comments on HN about ads or tracking on web
pages getting in the way, but good lord. This page first slams you with a
nearly full page ad with no dismissal, and then after you read a few
paragraphs hits you again with a modal sign up dialog.

~~~
pavel_lishin
The magic combination of adblockers has spared me from this fate, but not from
an annoying video about the top 5 richest rappers, for some reason.

------
madengr
Unfortunately this will just make it more difficult to get real work done, as
security is tightened further. Maybe they just ought to physically isolate
their networks.

Working at a large engineering organization, I have given up and now do all
engineering work on a stand alone computer, with dongle licensed software. I
feel bad about the piles of CDR I burn through to transfer files, but it’s the
only solution to getting work done.

------
olliej
IT security people need to stop thinking in terms of disallowing
“unauthorized” devices on physical (wired and WiFi) and recognize start
designing for human nature.

Assume that the physical networks are compromised, and have all privileged
resources only accept connections over VPN. Is it perfect? No, but it makes
further compromise harder. The assumption of no trust also means acknowledging
that you need gate incoming connections.

~~~
packet_nerd
Meanwhile DNS, which is a precursor to almost every connection ever, is rarely
encrypted or authenticated in practice. Standards like DNSSEC and DNS over TLS
exist but seem to have lots of vocal opposition without any serious proposals
for improvement.

A Microsoft certificate training I took recently literally put emphasis on
randomizing source port numbers as a way to mitigate attacks.... let that sink
in.

~~~
bennofs
What does encrypted/authenticated DNS gain you? If the application protocol is
encrypted and authenticated like https then faking DNS responses just results
in a connection that is closed immediately because authentication fails.
Encrypting is also useless unless you use a proxy/VPN because otherwise the
connection target leaks via the IP header anyway when you open the connection.

~~~
packet_nerd
> What does encrypted/authenticated DNS gain you?

Many things, here's three to start:

* A measure of privacy - instead of every rando with ability to sniff packets (activities you have no way to ever know about, available to many parties along the path) only the DNS server (which you choose, presumably trust, and can change) knows what names you resolve.

* Stronger foundation for TLS - LetsEncrypt and other public certificate authorities depend on DNS to issue certificates. If an attacker controls DNS, they could easily generate certificates for any site they wanted to attack.

* There have been many shady incidents with certificate authorities. I just feel that beefing up some of the other layers in the stack is a good idea.

> faking DNS responses just results in a connection that is closed immediately

On the web it's often not closed immediately, the users often get a
certificate warning that they may be conditioned to click through. Of course
HSTS helps with that, but still... why the hostility to securing the name
resolution layer?

------
tuanx5
Link to the actual audit here:
[https://oig.nasa.gov/docs/IG-19-022.pdf](https://oig.nasa.gov/docs/IG-19-022.pdf)

------
eggy
I remember back in the late 80s telnetting out of the NYU Bobst library on
their VAX 11(?) system to some pretty interesting systems. The Johnson Space
Center in Houston (running VAX 11/785s was one I particularly remember. Of
course, back then things were not battened down as much as they are now; the
spirit was an open network. A sysadmin would interrupt your session with
quesitons like "Who is this? You are unauthorized to access this system, etc."

~~~
Theodores
I used to love roving around VAX networks. In the UK the ones for science (and
defence research) were all setup the same. They didn't design the login
scripts for pests like me. So I was able to go round the different boxes
looking for interesting datasets. I only wanted super hi resolution satellite
imagery, convinced there was some sub-metre resolution stuff out there.

All was going well until I put my own backdoors in to speed up my remote
logins. Accidentally I denied access to everyone but me to a MOD computer. I
had to admit to that one! Luckily my boss handled it and was practically
pleased with his student hire. But yes, I can actually claim to have hacked
military computers. I doubt my boss has forgotten that day, the day when the
men from the ministry arrived.

Happy times, VAX computers were cool and hacking them with genuine VT DEC
terminals on those fairly open networks was living the lifestyle.

~~~
killjoywashere
I have two DEC VT510 terminals in my lab, serving mission critical functions,
right now.

~~~
eggy
Wow, that's wild. Never upgraded that system I guess. I hope mission critical
is not something that could effect things outside the scope of your workplace.
Although, security through obscurity or age here, might actually work ;)

------
jlmorton
Here's food for thought: while a proper firewall and network segmentation is a
well-established best practice, I'm not sure this is a winning battle.

There are probably a few dozen organizations out there that are properly
implementing strong information security practices, and my hats go off to
them. But they are the few, and I have never worked for one.

Despite best laid plans and policies, every place I have worked has always had
some improperly secured services somewhere on their network. And every place
that I've worked has had segmented networks that people end up relying on. And
the people working for these organizations are often aware of the improperly
secured resources, but they're only in the DMZ, and there are many other
things to worry about, so it lives on.

Especially now that we live in an IPv6 world, why not just run everything
publicly. Push security all the way down to the applications themselves, and
rely on the software development lifecycle process to catch security issues.

Every service has to be secure. And they can get an awful lot of help in this
from things like a service mesh architecture, where you're getting mutual TLS
from something like Envoy, and the applications won't accept a network
connection unless they're specifically authorized.

We need to stop relying on firewalls and network segmentation entirely, and
just run everything on the public Internet, and make sure every service is
secured.

I will say, when a zero day comes out in whatever proxy you're using to secure
your services, you are in for a world of hurt. But there are zero days in
firewalls too.

~~~
0xffff2
I work at a non-JPL NASA center. My workstation and internal server resources
are already locked down to a barely tolerable extreme. I can't imagine what
kind of restrictions would be added if we went forward with something
resembling the above proposal.

I don't want to go into much detail about our internal network architecture,
but suffice to say it's extremely difficult to run any kind of service
whatsoever even internally. It has literally taken me years to get approval to
expose a fairly simple REST API to the public internet, and I'm not even there
yet.

------
rurban
The JPL has been hacked, not just the NASA.

The JPL does much more interesting stuff than just NASA, like engines for
military and also secret SW programs for the NSA (we know that from Larry Wall
who was sysadmin there). And they are just administered by Caltech staff.
Whow.

Random hackers are only interested in confirmation of aliens, but NSA or DOD
stuff is very, very interesting to the Chinese who hacked these systems last.

------
rdruxn
Wow what a horrible website - the entire article was nearly completely covered
with popover ads

~~~
Krasnol
[https://addons.mozilla.org/en-US/firefox/addon/ublock-
origin...](https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/)

Works also on mobile (Android)

------
thereare5lights
Don't forget, CBP likely already compromised their security before.

[https://www.theatlantic.com/technology/archive/2017/02/a-nas...](https://www.theatlantic.com/technology/archive/2017/02/a-nasa-
engineer-is-required-to-unlock-his-phone-at-the-border/516489/)

------
hluska
For further context, here’s another report on NASA’s security in 2012.

[https://oig.nasa.gov/congressional/FINAL_written_statement_f...](https://oig.nasa.gov/congressional/FINAL_written_statement_for_%20IT_%20hearing_February_26_edit_v2.pdf)

Sadly, it doesn’t seem like things have changed.

~~~
0xffff2
Note that the report in the OP is a report on _JPL_ , not NASA. JPL is a
federally funded research institution that does most of its work for NASA, but
it is run by Caltech, not NASA directly. Having seen the process from the
inside, I can attest that NASA's security posture has changed _enormously_
over the last 5 years. If anything, we've swung the pendulum so far in the
direction of security that measures are being put in place that interfere with
our work for little to no real security benefit.

------
rasengan
And this is why you need to practice Defense in Depth. DO NOT assume your
system is simply hardened and cannot be penetrated. You have to assume the
opposite -- assume you will get fcked hard and apply separation among systems
such that a wound is just a wound, and not a fatal death.

------
sirbranedamuj
I was hoping there would be more info about how exactly the RPi was
compromised, and the steps that were taken from there.

------
johnrbent
Raspberry Pi is all over HN today

------
rochester6666
CAUDIT is a potential mitigation tool that is extensible for data breaches.
Ref: [https://github.com/pmcao/caudit](https://github.com/pmcao/caudit)

------
rawoke083600
Finally ! Now send me the.megadownload-link for Bigfoot and e.t photos

------
oh_sigh
Not: it is NASA, not NASA. I've only ever seen the BBC call it Nasa because of
their typographic rules.

~~~
countbackula
> it is NASA, not NASA It's LeviOHsa, not LeviosAH

------
reversengineer
YTCracker did it first!

------
peterwwillis
> All in all it reads like a security basics 101 list that has been ignored.
> System administrators lacked security certifications, no role-based security
> training was in place and JPL, unlike the main NASA security operations
> center (SOC), didn't even have a round-the-clock incident reporting
> capability.

That is not security 101, that's CYA bullshit that corporations institute once
they've been caught with their pants down. "Training" is worth jack. You have
to actually _implement_ security practices for them to be worthwhile.
Sysadmins are not always the brightest bulbs in the box, but they definitely
shouldn't be expected to be doing a security team's job of regularly auditing
security policy to make sure it's being enforced.

