back to article 'This repository is private' – so what's it doing on the public internet, GE Aviation?

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 …

  1. Alan Sharkey

    A couple of clicks?

    Possibly a little more than that :)

  2. IgorS

    DNS problem only?

    How can a DNS misconfiguration lead to this kind of problem?

    Was the information on a public IP address? Were they relying on security-through-obscurity only?

    1. Kevin McMurtrie Silver badge

      Re: DNS problem only?

      Isn't that a Solaris management thing? I recall machines in the 90s looking up their configuration by their own hostname.

      1. Anonymous Coward
        Anonymous Coward

        Re: DNS problem only?

        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.

        1. Dan 55 Silver badge

          Re: DNS problem only?

          Er, Active Directory is Kerberos and LDAP too y'know... and SMB was originally an IBM thing.

    2. doublelayer Silver badge

      Re: DNS problem only?

      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.

      1. Kevin McMurtrie Silver badge

        Re: DNS problem only?

        IPv6 has LAN addresses too.

        https://en.wikipedia.org/wiki/Private_network#IPv6

        1. doublelayer Silver badge

          Re: DNS problem only?

          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.

      2. Anonymous Coward
        Anonymous Coward

        Re: DNS problem only?

        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...

  3. KSM-AZ

    Likely a static nat map mon a firewall

    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.

    1. Anonymous Coward
      Anonymous Coward

      Re: Likely a static nat map mon a firewall

      The reality is that any publicly exposed server (i.e. an old firewall rule) will be being scanned 100's of times a day for common ports (SSH, RDP, HTTP, HTTPS) and doesn't require DNS to allow access.

  4. Phil A.
    Facepalm

    Sensitive config in a repo?

    If the config was "security sensitive" it had no place in a code repository in the first place.

    Its a fundamentally bad idea to store passwords in a code repo for precisely this reason...

    1. Anonymous Coward Silver badge
      Boffin

      Re: Sensitive config in a repo?

      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.

  5. Anonymous Coward
    Anonymous Coward

    DNS problem...? Really...?

    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...

  6. Gonzo wizard
    WTF?

    My head is spinning...

    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'...

  7. Velv
    Headmaster

    "would need access to the company's internal environment to exploit them"

    Isn't it the case that something like 85% of all hacks come from internal actors. So actually quite a high danger it could have been exploited.

    1. Alan Brown Silver badge

      "Isn't it the case that something like 85% of all hacks come from internal actors."

      And the vast majority of them aren't deliberate.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon