2 minutes read

GE Aviation exposed internal configs via open Jenkins instance

By
Bob Diachenko

Bob Diachenko

GE Aviation exposed internal configs via open Jenkins instance

Back in June I decided to check how many open Jenkins instances are available for search and did additional parsing of Shodan search results html pages for better understanding.

Jenkins is a service instance used by developers for integration and deployment. It is accessed via browser and can keep very sensitive information. Apart from source code itself, which is IP (Intellectual Property), it’s possible to dig out config files, API tokens, database credentials and lot more. 

As of July 7, 2019. there are 5,495 open and publicly available Jenkins instances as indexed by Shodan.

It took me only a couple of clicks to stumble upon a Jenkins server which appeared to be part GE Aviation internal commercial infrastructure.

This Readme file found inside of the repository explains all the details about the nature and sensitivity of the files there. Server contained source code, plaintext passwords, configuration details, private keys from a variety of GE Aviation internal infrastructure:

Immediately upon discovery I have sent several notifications to the GE team and on their Twitter and was contacted by security team within a couple of hours after the alert made. Jenkins instance was pulled offline the same day, however, it is unknown for how long it has been open for public access.

GE Aviation team explained that there was a DNS misconfiguration which caused the impacted server to become exposed to the open internet. 

Despite the number and sensitivity of the exposed credentials, GE team classifed this as a medium-risk vulnerability.  GE Aviation explained:

“Plaintext usernames and passwords were exposed on this server, but these credentials mapped to applications only accessible from our internal network, and no customer data, nor any significant GE data, was impacted. Furthermore, even if a malicious actor were to have acquired these credentials, they would also need access to our internal environment to exploit them.

“We have not seen any evidence that other parties have accessed the data on this server. That said, as a precautionary measure, we reset all credentials exposed on the server”,

“Our recommendation to other companies is to perform regular auditing of their static DNS mappings to ensure that mappings that no longer need to exist are deleted to avoid a similar situation.