31–40 of 60 posts
You should check out how many services have their entire git repo of their service openly accessible (this allows getting the data out of the git objects, as well as the history). Quite often you can go to domain.tld/.git/ and find the files if you know their names. Even major sites - The Hill only fixed it in the past few days.
that yields just 7 pages (10 items each) so it's probably pretty irrelevant. but of course you are welcome to share your run of the mill anecdotes about some intern once accidentally publishing passwords - etc. :)
Can someone explain why the inurl:server is used? Wouldn't this also work without that (and reveal more results where the keyfile has been renamed)
Of course you can remove it. Just means more results to wade through.
One of the more amusing patterns I spotted in the URLs is where an alarming amount of the filesystem appears to be exposed, e.g.: www.dulceswilly.com/mysql/BHP_sym/root/usr/local/etc/apache22/server.key If I was on a non-company IP, I'd be tempted to poke around and see what else is visible...
mysql root password: http://www.dulceswilly.com/mysql/BHP_sym/root/root/.my.cnf
Front page reads:
PELITABANGSA .CA [ INDONESIA CYBER ATTACK AND MALWARE ANALYST ]
Hmmm my idea would be "Hello from github, We detected that you uploaded credentials to NAME_OF_REPO. We strongly advise against this as it allows attackers to easily gain unauthorized access to your software and infrastructure. Have a look at this blog where we discuss alternatives" EDIT: Just to be clear, I'm not suggesting a ban at all, just a friendly email in response to commits that introduce credentials to publ…
You should check out how many services have their entire git repo of their service openly accessible (this allows getting the data out of the git objects, as well as the history). Quite often you can go to domain.tld/.git/ and find the files if you know their names. Even major sites - The Hill only fixed it in the past few days.
Hmmm my idea would be "Hello from github, We detected that you uploaded credentials to NAME_OF_REPO. We strongly advise against this as it allows attackers to easily gain unauthorized access to your software and infrastructure. Have a look at this blog where we discuss alternatives" EDIT: Just to be clear, I'm not suggesting a ban at all, just a friendly email in response to commits that introduce credentials to publ…
Is there a disadvantage to banning private keys in public repos?
First link goes to someone's github named Jimbo, a portly PHP guy from Austin, TX. I apologize for saying this, but... so far, this is violating no stereotypes
the key is still in google cacke...
I was a little surprised to see an Apple domain in there, but I can't really tell what the private key was for (could have been a test or an example). It looks like it's either an outdated result or an Apple engineer quickly saw this and fixed it because the page 404s now.
https://opensource.apple.com/source/tcl/tcl-87/tcl_ext/tclli...
You should check out how many services have their entire git repo of their service openly accessible (this allows getting the data out of the git objects, as well as the history). Quite often you can go to domain.tld/.git/ and find the files if you know their names. Even major sites - The Hill only fixed it in the past few days.
I've also fallen into this trap, thinking that Apache wouldn't serve up any dotfiles. Wouldn't that be a saner default?
# block .files
location ~ /\. {
deny all;
}
# allow Lets encrypt
location ~ /.well-known {
root YOUR LE DIRECTORY
allow all;
}