A couple of clicks?
Possibly a little more than that :)
GE Aviation managed to expose a pile of its private keys on a misconfigured Jenkins instance that was exposed to the public internet, according to a security researcher who found it through Shodan. "It took me only a couple of clicks to stumble upon a Jenkins server which appeared to be part GE Aviation internal commercial …
Quite possibly. Was that a NIS thing? The memories of YP/NIS/NIS+ have mercifully faded...
That was the one big fail in *nix land, and the thing MS did a pretty good job of. Active Directory is a pretty effective tool for this centralised management of stuff, so much so that *nixes haven't even bothered to reinvent it, using Samba instead.
The DNS in question would be the internal one for the company, for example instructing the actual public systems that the hostname could be found on a given internal system, and thus allowing a tunnel into the network to be created when that wasn't really desired. The other option is that some DHCP or static routing misconfiguration reassigned the server to a public IP and nobody noticed because DNS still resolved the hostname properly.
I have to say, though this isn't exactly on topic, that this is pretty much the only thing I'll miss when IPV6 takes over. It's nice to have specific IP ranges that won't be available publicly. Yes, I know that I can run an IPV4 network and NAT out to an IPV6 one, and that I should be firewalling anyway, but private space is nice because I know that, should the firewall be misconfigured, unsolicited traffic still won't be able to reach the server because the address can't be routed to.
Good point. I stated that point badly. I should have phrased it more like this:
I like the basic security provided by the use of NAT that is standard in IPV4 networks due to the small number of available addresses. While this can be done in IPV6, it is not done as standard or recommended by many IPV6 advocates. I am worried that this security will be lost during the switch to IPV6 for the vast majority of people who stick with the default configuration and may therefore be left without either the security of a properly administered firewall or the somewhat unintended but nonetheless available security of private addressing.
Have an upvote for helping me clarify that.
The only thing I can thing of that would cause something that was hidden to be unhidden by a DNS change would be an SNI hosted server where access was allowed to a webserver but unless you used the correct DNS name you couldn't get in. If you are using this to protect information rather than just test, it's a terrible security practice....
If the host was purely internal and on RFC1918 address space, then DNS wouldn't matter. If it was on a publicly routable address range already, and firewall rules permitted access, it would be discovered by the myriad crawlers that scan the world looking for scraps of information so it's unlikely the DNS entry would have mattered unless it only mattered for the good guys finding the site and informing GE while the bad guys already had access...
Possible scenario with DNS
Firewall DNAT
<REAL IP> -> internal-server-by-name
... Retire internal server
.. Things reboot, No access, old name not removed
...New Server same old internal IP, Hostname * or someone added * because the server is using many names
... Things reboot sometime later firewall picks up nat, or nat -> now matching name.
Sloppy as hell no matter how you slice it.
They were using it with chef. ie not treating it as a code repository in the programming sense, but as a centralised distribution system for config files.
Still not wise to have credentials stored like that, but what is wise is often very different to what is done &/or needed.
DNS is a name-to-address lookup system. Even without DNS, you can contact servers by IP. Therefore this must have been on the public Internet as well.
I like the idea of the "accidental NAT re-use" but that does not implicate DNS either.
However I suspect, as it was a code repo, that this was in the public cloud and the instance had a public IP and DNS name assigned in error. Even then, the solution is not to remove the DNS entry, but remove the public IP.
Any dissenting opinions...?
Please read and understand the "shared responsibility" model of the public cloud - and "firewalling" is not enough. L4-7 inspection (including HTTPS) is the mandatory baseline...
I can't roll my eyes enough at this stupidity. "This repository is private" yeah and accident waiting to happen. Never, never commit sensitive information into a repository as any repository could inadvertently make its way into the public domain - either through incorrect configuration or simply because somebody pushed a checkout into a github repository for 'convenience'...