more enterprise and contractor failure

2026-09-14

another small slew of enterprise fail(s).

typically, most ‘breaches’ carried out nowadays are done via breaching a shittier vendor/contractor/suborgs that holds a corps data, looking for these for (especially prominent companies) are relatively trivial; you can see an example of this by going to crunchbase and going to their suborgs/subdomains/acqusitions, listing for similar companies, etc. these companies (most of the time) are good; but certain contractors typically do not due a lack of due diligence and shits given, which in turn either cause them to misconfig a bunch of random stuff (e.g. a ci server out in the open, etc.) and end up getting obliterated lol

1 - pretty big intl organization

this is a fairly prominent org that does stuff internationally, which has a division for infrastructure. unfortunately, they seemed to have delegated a lot of their work to contractors (since they really really champion open source dev work). unfortunately, we are gated behind a login screen: there is no way to sign up, and judging by the subdomain this seems to be an internal portal for its staff and other contractors.

checking the source of the site alone:

checking for the public firebase config:

scrolling through this its immediately obv that the entire thing was written with genai. not an issue in of itself; but since the entire thing has comments and 30 emojis per line it may indicate that the contractors didnt give a shit. using firepwn, lets try to enumerate and see if theres any access control:

after trying the usual list of names it became pretty obviuous that this isnt going to work. lets try making an account instead:

logging in with these creds, i tried firebase again (which didnt work). however, now that we have perms, im now logged in to their ‘partner portal’. the ‘users search’ page allowed me to search for a single character, which retuerned almost every user in their crappy vibed rest api, which exposed the following information:

• DOB
• Country/Place of Birth
• Nationality
• Email
• First Name
• Last Name
• Preferred Name
• UniqId (??)
• UniqIdIssueDate

for example, this is me:

this obv meant that their user data was not in firebase, and from thjere someone could do mass se’ing, etc etc. reporting this to the org in question the portals firebase got completely nuked in the end, nice.

2 - helping some contractor for large companies do src auditing

this was a contractor that did (again) it infra and crm stuff. this was found entirely by accident because i scrolled too far on fofa and netlas. an exposed teamcity ci was very interesting; however i couldnt find a way to access it. after a bit of looking around, i went to greyhatwarfare and searched up the company, which popped this up:

lol ggs (maybe)?. the most classic way to breach stuff obviously given this, is:

$ aws s3 ls s3://[redacted] --no-sign-request

which revealed:

artif
img
backups
[redacted]
redactedsvc
local

artif gave me uselss stuff, but backups is interesting (again probably dont store important shit in exposed buckets). using trufflehog:

trufflehog s3 --bucket="[redacted]" --only-verified

didnt yield anything aside from a planetscale api key which had completely junk test data. however, accessing the zipfile in backup revealed a (pretty sizeable) php codebase:

ok cool lets read the source a bit. out of curiosity i searched "SELECT in vscode, which gave me:

wtf

more vulns

from that query alone i found around 3 sqlis, with a lot of very blatant ones: in the above, $status is influenced entirely from a “talent pool acquisition status” (whatever the fuck that means), which seems to require auth. however, AccountReset.php lets you do this:

<?php
	include('./../common/header.php');
	include('./../config.php');

	authCheck();
    // $username = urldecode($_POST['username']); // notably this is all it needs (???)
    // $resarr blah blah
    // ...
    
	if ($resarr['statuscode'] == "no_auth" || $resarr['statuscode'] == 'nadmin' || $resarr['statuscode'] == "ERROR") 
	{

			<script>
				alert("Unauthenticated.");
				history.back();
			</script>
    }
    // ...
	
    // ... reset password flow wtf
	echo json_encode($result_array); 
	
?>

so their way to stop someone from resetting someone’s pw was to essentially slap js and fall through to the reset logic anyway lol

clearly, what we can do now is to:

1. find a staff’s user
2. exploit the auth endpoint being dogshit and reset their password
3. login and sqli to dump them

reporting this they removed backups after a solid, not-so-long 12 months and never replied after