[FD] Finding secrets in mirrored Git repositories

2022-02-13 Thread Nightwatch Cybersecurity Research
(Full blog post here:
https://wwws.nightwatchcybersecurity.com/2022/02/11/gitbleed/)

SUMMARY

Due to a discrepancy in Git behavior, the full contents of a source
code repository are not visible when making copies via the “git clone”
command. The entire contents only become visible when using the
“–mirror” option. This can lead to secrets being exposed via git
repositories when not removed properly, and a false sense of security
when repositories are scanned for secrets against a cloned,
non-mirrored copy.

Attackers and bug bounty hunters can use this discrepancy in Git
behavior to find hidden secrets and other sensitive data in public
repositories.

Organizations can mitigate this by analyzing their entire repositories
using the “–mirror” option and remove sensitive data using tools like
BFG or git-filter-repo (which do a more thorough job).

DETAILS

Git is a popular open source tool used for version control of source
code. When users make a copy of a local or remote git repository, they
use the “git clone” command. However, this command doesn’t copy all of
the data in the originating repository such as deleted branches and
commits. On the other hand, there is a “–mirror” option which copies
the entire repository including all deleted content. The discrepancy
between the two behaviors can lead to secrets and other sensitive data
lingering in the original repository. Additionally, existing tools for
secrets detection often operate on cloned repositories and do not
detect secrets in the mirror portion of the repository unless cloned
via the “–mirror” command.

We also tested forking in GitHub and GitLab, and in both systems
forking uses the regular “git clone” behind the scenes and not the
“–mirror” version. That means that repositories containing secrets in
the mirrored portion will not propagate those secrets to their forks.

We provide two examples of repositories containing hidden secrets that
are only visible when cloning with the “–mirror” option. These can be
found here:
- https://github.com/nightwatchcybersecurity/gb_testrepo_delete
- https://github.com/nightwatchcybersecurity/gb_testrepo_reset

TOOLING

There are plenty of existing tools out there that can manipulate git
repositories, scan them for secrets and remove specific commits.
During our research, we used git for checking out repositories,
git-filter-repo for figuring out the delta between cloned and mirrored
copies of the same repository, and gitleaks to scan for secrets.

For examples on how to use these tools, please see sample scripts that
we have published to GitHub:
- https://github.com/nightwatchcybersecurity/gitbleed_tools

MITIGATIONS

Organizations can mitigate this by analyzing their entire repositories
using the “–mirror” option and remove sensitive data using tools like
BFG or git-filter-repo. Garbage collection and pruning in git is also
recommended.

Organizations should not analyze regular cloned copies (without the
“–mirror” option) since that may provide a false sense of security,
and should not rely on methods of removing secrets such as deleting a
branch or rewinding history via the “git reset” command.

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Facebook DNS misconfiguration

2022-02-13 Thread Joey Kelly
On Wednesday, February 9, 2022 12:18:59 PM CST Carlo Di Dato via 
Fulldisclosure wrote:
> Hi everyone,
> I submittet to Facebook a DNS misconfiguration issue. Specifically, the
> following URLs will be resoved as private IP addresses.

nathan:~$ dig dev.facebook.com +short
intern-regional.vvv.facebook.com.
10.110.159.20


It's definitely a leak. They need to learn about BIND views, or the 
equivalent.

--Joey

> 
> dev.facebook.com : A [10.110.151.5]
> hr.facebook.com : A [10.110.199.9]
> prof.facebook.com : A [10.18.4.109]
> tps.facebook.com : A [10.110.159.18]
> interim.facebook.com : A [10.110.151.5]
> nexus.facebook.com : A [192.168.62.201]
> alf.facebook.com : A [192.168.16.27]
> 
> It's something similar to Same Site Scripting, except the resolved URL
> is not 127.0.0.1 but a private IP address.
> You could use them in case of red team activies, for example.
> Imagine this scenario:
> 
> #1 - there's a public, unprotected wi-fi network
> #2 - you are connected to this wi-fi network and your IP is
> 192.168.16.11
> #3 - you could change you IP from 192.168.16.11 to 192.168.16.27
> #4 - you could start a web server with a fake Facebook login page or
> with some malicious file
> #5 - you could invite someone, within the same network, to visit
> "http://alf.facebook.com"; or to download an update from
> "http://alf.facebook.com/update.exe";
> 
> Of course, another scenario would be the one in which you create a
> rogue, free wi-fi access point configured to assing 192.168.16.1/24 IPs
> 
> Do you consider this a MITM attack? I'm not 100% sure but Facebook
> stated it is.
> See you!
> 
> Cheers,
> Carlo Di Dato (aka shinnai)
> 
> ___
> Sent through the Full Disclosure mailing list
> https://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/


-- 
Joey Kelly
Minister of the Gospel and Linux Consultant
http://joeykelly.net
504-239-6550



___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/