enterprise shit

disclaimer: this was ages ago

as large as certain corps grow they start to screw up on a lot of access control related stuff. this should serve as a pretty decent case study. for privacy reasons i will name the corp in question as Xcorp.

initial

doing a basic recon search on netlas/shodan/censys we can find that they have an “old” zendesk:

this is interesting, because from what Xcorp does most of their zendesk/support related stuff are mostly through more private channels other than zendesk. notably though they did denote this as xcorp-deprec.zendesk.com so we can safely assume that this is prob an old zendesk that they abandoned. either way lets check it out. checkign the website and signing in shows this:

naturally, lets make an account.

i simply used emailhook and signed up. obviously, i wont get any tickets and clearly zendesk isnt a shit site so anything trivial is out of the window. lets see what we can do. checking zendesk docs and searching a bit we eventually land on this interesting docpage: https://support.zendesk.com/hc/en-us/articles/4408887218330-Using-placeholders

essentially zendesk lets you use template/‘placeholders’ to embed ticket information/references etc dynamically. obviously this means we can try injecting these and see if it shows something:

submitting the ticket, we see:

nice. clearly we can inject placeholders. the next step is to obviously try and leak user information. the only decent way to do this is to CC someone who is a support agent, then using {{ ticket.ccs[0].custom_fields }} to try and leak something actionable. doing a bit of elementary osint on CS people in the company, i was able to find a john doe (wont name them). doing some basic recon again on the corporation we find support.xcorp.org. looking at their email address format i tested doe.john@support.xcorp.com, doe.j@support.xcorp.com and j.doe@support.xcorp.com. notably it is a pretty common name so it proved to be quite screwy. in the end j.doe1@support.xcorp.com seems to have worked:

writing a quick script we can build a small database by putting in a list of cs agents:

{
  "user": {
    "id": 4764782512964,
    "name": "[REDACTED]",
    "email": "[REDACTED]@support.[REDACTED]",
    "role": "agent",
  }
}

as it turns out john doe actually helps with gitlab issues. nice. interesting, in an agent note we leaked from the placeholder vuln the domain gitlab.mgmt.[redacted] was mentioned. searching this up on shodan/censys/netlas didnt result in anything; this is likely their internal gl.

gitlab

the next natural step is to obviously check their gitlab. finding their gitlab was trivial as i just had to search their company name and “gitlab”. i landed on https://gitlab.mgmt.[redacted]/users/sign_in. out of curiosity i changed /users/sign_in to /users/sign_up, which lands me on this:

nice. logging in i obviously have 0 access to any recent repository, but i do have access to old repositories (i presume are abandoned/useless) . searching up some of the strings/endpoints reveals that theyre running some of these live. naturally i downloaded the repository, which had some terraform files and menial telemetry code. interestingly though .gitignore did not have a .env. checking git log:

root@bc19c3d2c0cc92ca0d3d4d4f13:~/dmp# git log
commit 66a88ac7c1c3c427dd4628fee4e196cc1a21bbd7 (HEAD -> master, origin/master, origin/HEAD)
Author: jaya <REDACTED@dso.redacted.com>
Date:   Wed March 2 17:10:48 2022 +0530

    update

...

with terraform also came some good information we could put to use:

region = "us-east-1"
environment = "dev"

tags = {
  Name          = "REDACTED-RBAC-LAMBDA"
  Environment   = "US-EAST-DEV-US-BRE-REDACTED"
  GBL           = "195[REDACTED]"
  ApplicationID = "[REDACTED]"
  Market        = "US"
  Owner         = "BRE_AOT_AWS_REDACTED@redacted.com"
  Workload      = "DEV"
  "cpm backup"	= "redacted_eastus_weekly_non_prod_02"
	"Patch Group"	= "USA-DEV-UAT-3"
}

there were a lot of changes being made to this old repo from 2022. one of them interestingly (f9b15c2035487d45d1c901aba2a20378c63eed33) removed the .env file. in it interestingly is a jfrog token, api keys, etc. maneee im deadddddd

the jfrog part is probably the dumbest shit one can push notably

reporting

contacting them with my findings i was compensated with some cold hard cash. huge