An Internal Code Repo Used By New York State's IT Office Was Exposed Online (techcrunch.com) 15
A code repository used by the New York state government's IT department was left exposed on the internet, allowing anyone to access the projects inside, some of which contained secret keys and passwords associated with state government systems. From a report: The exposed GitLab server was discovered on Saturday by Dubai-based SpiderSilk, a cybersecurity company credited with discovering data spills at Samsung, Clearview AI and MoviePass. Organizations use GitLab to collaboratively develop and store their source code -- as well as the secret keys, tokens and passwords needed for the projects to work -- on servers that they control. But the exposed server was accessible from the internet and configured so that anyone from outside the organization could create a user account and log in unimpeded, SpiderSilk's chief security officer Mossab Hussin told TechCrunch. When TechCrunch visited the GitLab server, the login page showed it was accepting new user accounts. It's not known exactly how long the GitLab server was accessible in this way, but historic records from Shodan, a search engine for exposed devices and databases, shows the GitLab was first detected on the internet on March 18.
Porn has less exposure than this server. (Score:2)
Someone doesn't know what an internal network should be.
Re: (Score:3)
Even then, it's not a great idea to store secrets in git. Even if it's a private repository. Better to have a separate process set up for secrets.
Re: (Score:2)
This, ever so much this. There is no reason -- other than amateurish coding practices -- to store passwords or keys in source code. There are plenty of good (and even free) tools for this. It's not that hard.
Back when I was still working in IT (devops, toward the end), on the rare occasions when someone accidentally left a secret hardcoded (always a dev password, never testing or production), it was immediately scrubbed, changed, and the responsible party given, er, a polite talking-to. (Nobody ever did
Re: (Score:2)
Nobody said anything about an internal *network*. This is an internal *code repository* that was set up on a server with misconfigured security.
Re: (Score:2)
Which should be on a...follow me with this. Common-sense shouldn't need to be spelled out.
Re: (Score:2)
It should be on a server accessible to the developers who need to use it. Now you could do that by putting the server on an internal network and giving vendors access to that network, but that's not necessarily a good idea.
Re: (Score:2)
There are many Youtube channels that prove that assumption wrong, see Fail Army [youtube.com] for example.
Re:Porn has less exposure than this server. (Score:5, Informative)
Internal networks being considered an effective defense mechanism is a bad habit.
Historically, it's used to justify lazy administration where people use 'password' as the password and are similarly lax because "hey, the network is protected, we don't need to worry". This is mitigated by being unroutable, but a lot of systems have been bitten when the 'trusted' internal network suddenly has a malicious footprint in it, and they plow through all sorts of insecure internal systems with weak passwords.
The same measures that you would use to protect an internet exposed host should also be used to protect an 'internal' host, and the same standards around whether it's a good idea to share a private key or stored password in a git origin should apply.
It may be nice to have an internal network for various reasons, but may do more harm than good when it comes to security, on the one hand it does mitigate random incursion, but on the other hand it enables bad security practices and when the dam ultimately breaks, it's generally catastrophic.
We're surprised? (Score:5, Insightful)
Bad practices are still abundant because nobody wants to dedicate the time to do it right. Developers under time constraints will always do the quickest thing. It doesn't surprise me that this was exposed on an Internet-facing server, nor does it surprise me that credentials/embedded secrets were in the code.
Re:We're surprised? (Score:4, Insightful)
Part of it is that a lot of the security tools aren't optimized for user friendliness, even when being more usable would not produce a conflict with the goal of security.
E.g. sloppy key and certificate management is often because the tooling to 'do it right' aren't really caring to make it easy.
For example, you want to do passwordless ssh, great, making a key is no big deal and is better than a password, if stored with keyphrase protection. However, the user has to sort out some sort of ssh-agent setup, make sure it's shared among sessions to avoid maddening retyping of the passphrase, and ideally hooking it up to some 'keyring' facility at the desktop session. This is awkward enough to get to this point, and a whole new territory when you want to use an HSM solution for ssh. Then you have intermediate hosts, which is accommodated ideally by ProxyJump so your local agent extends through the network, but the 'lazy' way is to ssh in, get aggravated that you would need to ssh in again, so you generate a new ssh private key without password on a shared system and keep going. So 99% of the time with a peer, I see ssh keys with no password protection, proliferating endlessly.
The tools generally get to 'possible', but once they show it possible, interest to get the rest of the way to usable fizzles out. So there's generally a dichotomy in professional life:
-Lazy and insecure
-Internally audited, forced into painful security practices, and when people get an ounce of context to be lazy, they are still wildly insecure and just think security is necessarily a pain and not worth doing.
The 'happy and secure' ideal is generally out of reach for the organizations.
Re: (Score:3)
Bad practices are still abundant because nobody wants to dedicate the time to do it right.
Doing it well (there's no such thing as 'right') usually doesn't take more time than doing it wrong (there is such thing as 'wrong').
It's a lack of skill/experience, not a lack of time.
Re: (Score:2)
If the tooling were better, I'd agree.
However, with the tooling as it is:
ssh-keygen
Is less secure than:
-ssh-keygen
-enter passphrase
-set up ssh-agent
-make sure to ssh-add
-To make it easy day-to-day, make sure you auto-start an agent, and also make sure that askpass is hooked into something that integrates with your keyring solution
-To avoid missing the point entirely, make sure you always ProxyJump to hosts that aren't direct routes, again, taking time to craft ssh_config to make it easier day to day
This pat
Re: (Score:2)
Amen. Once learned, it really isn't that difficult.
For the unaware, the following provides a pretty good overview of available tools for this: https://geekflare.com/secret-m... [geekflare.com]
I'm most familiar with Hashicorp's Vault (we were an early adopter), and I've played with (ie, for evaluation) some of the others.
Of course, there are probably still ways to do it wrong with any of the above, if you're not taking it seriously.
The People's Code (Score:2)
Credentials, passwords, certificates, etc, should never, ever, ever be in code. There are widely available tools and services to enable passwords to be stored separately from code in a secured manner, and retrieved by code at