In reality, it wasn't the attacker's incompetence, it was the hosting provider's fault (which is a "Serverless app platform" they use to deploy their phishing pages)
When you deploy a simple page with them it exposes .git/CONFIG and the x-access-token that grants access to the repository.
Lacking details, but people don't generally rsync a checkout of a git repo (including a .git folder) to their webspace, so you're right if the hoster did that, I find it more likely the people did that.
On the other hand just blacklisting .git/* is not great, maybe I want to publish something on that path, just like any other filename. It's prone to lead to false positives.
Exposing a .git folder is a common error that people other than threat actors make, making a public post about it at least can help ordinary developers in addition to TAs making this mistake. If you find this disclosure frustrating, take a look at what threat intel/AV/EDR/etc companies post on their blogs.
yeah look at like Krebs, he actually tries to track down the criminals and not make their job easy by posting their mistakes halfway during the operation...
Truth is that threat actors usually do. Much of the time they live in jurisdictions that don't care about cybercrime, and even if they don't actually cooperating with authorities is usually difficult.
Thanks for the kind words. We discussed whether to pull the data. We didn't for two reasons:
1. It's not trivial to process that data safely, and all the people in the server are volunteers that pitch in as much as they can. It won't be fair to burden them more.
2. The bots were posting to what appeared to be private or moderated channels. We didn't find an easy way in. Maybe there was a way in, but see item 1 above.
So we went with "nuke it from orbit"
What leads to the secret being stored in git's config file like that? None of my repositories have that, the remote URLs all just say "git@github.com:foo/bar.git".
The way Git computes diffs is by more or less storing all the source code in the .git directory as objects. At first glance it looks like a bunch of hashes, but tools can pull out source code from the objects tracked within the .git directory. Not least of which, the remote URL points to their username on GitHub and the author for commits can give you their email.
Not least of which, and even more so the URL had an auth secret in it. None of mine do, hence the question. I'm confused, because git has a credentials helper specifically designed to avoid storing secrets like that, or so I thought. So what tool is storing secrets in the git remote URL?
Yes, the git directory has all current and historical versions of the files packed into it, but that's not what the OP used to get information about the scammer.
It's one of several ways to auth to the server. I guess they didn't want to use SSH. And if you use HTTPS instead, you're prompted for your username and password every time -- unless you pass a token.
In reality, it wasn't the attacker's incompetence, it was the hosting provider's fault (which is a "Serverless app platform" they use to deploy their phishing pages)
When you deploy a simple page with them it exposes .git/CONFIG and the x-access-token that grants access to the repository.
Lacking details, but people don't generally rsync a checkout of a git repo (including a .git folder) to their webspace, so you're right if the hoster did that, I find it more likely the people did that.
On the other hand just blacklisting .git/* is not great, maybe I want to publish something on that path, just like any other filename. It's prone to lead to false positives.
Could've traced the attacker for a bit before burning all bridges.
Isn't this post basically service for attackers?
You take down C&C and phishing pages=great but maybe don't brag exactly what you did especially if the people are out to do it again but better?
Exposing a .git folder is a common error that people other than threat actors make, making a public post about it at least can help ordinary developers in addition to TAs making this mistake. If you find this disclosure frustrating, take a look at what threat intel/AV/EDR/etc companies post on their blogs.
yeah look at like Krebs, he actually tries to track down the criminals and not make their job easy by posting their mistakes halfway during the operation...
I agree with never deploying a .git folder to prod.
Part of our deployment script for sites has something like:
So no .git directory, .gitignore, and so on.Another option for that might be `git archive | tar -C /path/to/dir -xf-`
Sounds like they got off easy.
Truth is that threat actors usually do. Much of the time they live in jurisdictions that don't care about cybercrime, and even if they don't actually cooperating with authorities is usually difficult.
They probably did. But it's a volunteer effort, we all contrinbute as much each individual's time permits.
It is great that they got taken down. From my experience, these sites are usually parasites on misconfigured Wordpresseses.
We're you able to get the phishing data so that you can help the victims? Is it a good idea to try and do so?
Also, can you please share some bits of the phishing kit for easier detection?
Thank you for your efforts!
Thanks for the kind words. We discussed whether to pull the data. We didn't for two reasons: 1. It's not trivial to process that data safely, and all the people in the server are volunteers that pitch in as much as they can. It won't be fair to burden them more. 2. The bots were posting to what appeared to be private or moderated channels. We didn't find an easy way in. Maybe there was a way in, but see item 1 above. So we went with "nuke it from orbit"
Yeah, that's the problem, processing the data safely. I wouldn't want to do that either without a lawyer covering my back.
What leads to the secret being stored in git's config file like that? None of my repositories have that, the remote URLs all just say "git@github.com:foo/bar.git".
The way Git computes diffs is by more or less storing all the source code in the .git directory as objects. At first glance it looks like a bunch of hashes, but tools can pull out source code from the objects tracked within the .git directory. Not least of which, the remote URL points to their username on GitHub and the author for commits can give you their email.
Not least of which, and even more so the URL had an auth secret in it. None of mine do, hence the question. I'm confused, because git has a credentials helper specifically designed to avoid storing secrets like that, or so I thought. So what tool is storing secrets in the git remote URL?
Yes, the git directory has all current and historical versions of the files packed into it, but that's not what the OP used to get information about the scammer.
I think you misread the question.
It's one of several ways to auth to the server. I guess they didn't want to use SSH. And if you use HTTPS instead, you're prompted for your username and password every time -- unless you pass a token.
The URL you see in that fourth screenshot in the Imgur post is from using `git clone` on the the same URL, which was issued on GitHub.
How do you get Github to issue such URLs? No repository lists URLs in that format on Github for me.