47

As a security in-charge, I just noticed that one of our production web apps was attacked by some hackers. The attacker accessed the .git/objects/ files.

I already modified .htaccess to make .git and its content inaccessible.

The attacker may get some model file which includes some data queries but not with database credentials. Should I worried about it?

18
  • 47
    You have to escalate this now!
    – MechMK1
    Mar 17 at 15:17
  • 5
    I will suggest in the future using the --git-dir=/path/to/repo/.git option so the .git folder can exist outside the folder where you are putting the files.
    – Tongfa
    Mar 17 at 23:08
  • 11
    This is just another example why having code in a document root is a terrible idea, and it's sad that this is so common with Apache+PHP.
    – marcelm
    Mar 18 at 13:20
  • 3
    @marcelm It used to be common. All modern PHP frameworks use a subdirectory (such as public/) for the webserver document root, but old habits die hard. Still plenty of ancient code out there, or devs that are stuck in their ways. Mar 18 at 16:03
  • 10
    Why would you ever have a git clone on a production server (or on any server actually)? Git is not meant to be used as a deployment tool. you need to use other means to deploy your code.
    – Kryptos
    Mar 19 at 8:11
88

Should I worried about it?

Worried? No, of course not.

You should be absolutely terrified and have nightmares about this.

Having stolen .git directory means the attacker have the current and past source for the production server, all history of all code since the start of the repository. With that, they can reconstruct your infrastructure, and do a white box testing against the code.

They will be looking for remote code execution, file inclusion, and SQL Injection right now. And your developers must review every function handling user supplied data (cookies, parameters, URL queries, etc) for any possible vulnerability.

You did a good start by denying access to .git on the servers, but your work is just starting. Your code is now known to attackers, and they are inspecting the code for vulnerabilities. If any time someone hard-coded credentials on the code and commited it, the attacker have that password.

Things you should do:

  • full code review from a reputable company
  • consider using a Web Application Firewall
  • install IPD/IDS (Intrusion Prevention/Detection Systems)
  • change every single database password
  • rename the database if possible

Be prepared to fight fine-tuned targeted attacks.

3
  • 2
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Mar 19 at 12:20
  • @JanHudec most of the comments that have been moved to chat didn't look like fulfilling any criteria mentioned in the comment privilege. Fortunately, they were moved to the chat instead of getting deleted.
    – Andrew T.
    Mar 20 at 16:28
  • @JanHudec - We have been through this many times on meta.security and main meta. Comments on SE are supposed to be temporary. They detract from the key aim which is questions and answers. They are only to request clarity or updates, and are expected to be deleted. Anything that is an answer needs to go in an answer.
    – Rory Alsop
    Mar 22 at 15:24
14

Worried? Maybe. Is your source code filled with holes? Then yes. But quiet honesty, you should have been worried BEFORE your source code leaked.

People have this idea that they're safe because "nobody will discover my horrible security hole because they don't know how it works!". This is a bad way to think of security. MANY security holes are discovered without having access to source code. I'd even make a guess that MOST are discovered without having access to source code.

I once found a security hole where the "security" was hiding the interface in an iFrame, so you couldn't see the URL being passed around. Thankfully I caught this before it went out to the outside world. Having access to source code would not have helped find this. Finding this was a matter of "view source" in the browser.

In reality, having source code speeds things up, and makes it easier to attack, but the lack of it is far from making you secure.

Bugs aren't secrets concealed through source code. In some ways it's actually often easier to use attack tools than to read through source code for bugs, or run it through static analysis tools.

So if I were you, I'd relax, and start doing what you should have done in the first place. Analyze your code for security holes. Start using good security practices. Design it in from the get-go. If you're asking this question on a security forum (and then revealing your product just had its source leaked), I'm guessing you haven't done this. These are good ideas without having had your code leaked.

There's no magic bullets. Beware of security products that claim to protect your crummy code or expensive audits that claim to find all the holes in your software at one instant in time. Those things have their place, and might be useful in some way, but there's a hefty amount of snake oil being sold as well. To paraphrase the great journalist Hunter S. Thompson:

The IT security industry is uglier than most things. It is normally perceived as some kind of cruel and shallow money trench through the heart of the software world, a long plastic hallway where thieves and pimps run free and good men die like dogs, for no good reason

Now, Hunter was talking about TV, but I've long thought the same thing applies to IT Security.

3
  • ...and the knowledge of the source won't make you any more secure.
    – ThoriumBR
    Mar 18 at 23:18
  • 2
    There are two risks here: 1. if the repository contains any valid credentials, they will be found and abused (internal repositories sometimes do contain credentials; a lot is simpler that way and since the repository is private anyway…), or 2. if the repository contains data or code the company wishes to keep confidential.
    – Jan Hudec
    Mar 19 at 13:50
  • @JanHudec I agree. Leaking credentials are a big problem. Without knowing what the leak contains, you can't make terribly good guesses as to the impact. Mar 19 at 16:00
4

No, you should not be terribly worried, unless you did horrible no-nos like putting credentials in your source tree. So the party who accessed these files saw part of your source history. Big deal. That gives them a window into understanding how your application does things internally, and might assist them in searching for vulnerabilities, but it's nothing catastrophic.

It would be a very good idea to do a security review on your application, especially the parts of the code you suspect they accessed, in case there are obvious bugs they can exploit. But you don't need to panic.

1
  • 8
    While possibly true, without knowing what was in the git history, the OP should certainly take a stance more towards what ThoriumBR wrote. Risk assess first before feeling comfortable that nothing needs to be done.
    – schroeder
    Mar 18 at 22:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.