Questions on security bulletin (repository secrets leak to PRs)

This is regarding the recent security bulletin: Security Bulletin

  • What was the total window of exposure? It’s good to know you started patching on Sept 3, but that doesn’t tell us when the vulnerability was fully made non-exploitable, nor when it was first introduced.
  • Are you aware of any attempts at exploitation, other than the reporter’s proof of concept?
  • Are there any indications of compromise that we can use? That is, does exploitation leave any trace we can detect?
3 Likes

https://twitter.com/peter_szilagyi/status/1437646118700175360 :grimacing:

2 Likes

Hmm. That says between Sept 3 and 10 it was vulnerable, but Travis says that patches started Sept 3. Need official clarification on that, but will also follow up with reporter.

1 Like

one of the reporter’s here

  • What was the total window of exposure? It’s good to know you started patching on Sept 3, but that doesn’t tell us when the vulnerability was fully made non-exploitable, nor when it was first introduced.

We’ve detected it on the 7th. Scouring various repos, we found the first instance on Sept 3 at ~6:50AM UTC. A fix was deployed and the issue stopped on Sept 10 sometime after 8:11AM UTC.

  • Are you aware of any attempts at exploitation, other than the reporter’s proof of concept?

We’ve notified a few projects ourselves to remove their PR builds, they reproed and validated too. Don’t know if it was abused or not.

  • Are there any indications of compromise that we can use? That is, does exploitation leave any trace we can detect?

Not much trace. You can run a script to access an env var and push it through the network. Then submit a force pushed PR to remove traces of the code. Your only indication is PR activity and check if you have access to the code that ws run in them in that time interval.

2 Likes

Travis says that patches started Sept 3.

Yeah, that worries me too. Perhaps it started even earlier in a different form.


This is the response to the post below:

In PR builds, if you have env vas set, you’d get a note:

Encrypted environment variables have been removed for security reasons.
See Building Pull Requests - Travis CI

We saw that the note was replaced with the usual redacted env var listing:

Setting environment variables from repository settings
$ export AWS_ACCESS_KEY_ID=[secure]
$ export AWS_SECRET_ACCESS_KEY=[secure]

Our repos are generally idle during the weekend, so we started looking for other high profile repos that were pushing PRs and found one with keys in them. Then just binary searched their logs to find the time when it started (and eventually stopped) happening.


PS: I can’t comment any more on this thread XD New users are only allowed 3 comments in total on a topic, so yeah, I’m just going to leave this forum now.

2 Likes

Oh, it’s you! Hah. Thanks for the confirmation on the timing on your side.

When you say you “found the first instance on Sept 3”, what exactly did you find an instance of?

1 Like

Is there a way to rotate our Travis CI API tokens?

Could you clarify were those only “encrypted secrets” (identified in code via secure: flag), or “encrypted/hidden environment variables” also (defined via repo settings in Travis UI)?

@Montana Could you add some clarification here?

I wrote a small tool to help organizations analyze blast radius and figure out what repositories are potentially impacted.

https://www.npmjs.com/package/travis-org-vuln-scanner

You can run it as simple as ‘npx travis-org-vuln-scanner’

Since it’s hard to understand from the announcement what is the exact vulnerable window, it’s not filtering anything by dates. The script will output repos that had Travis builds + env variables + forks, then prints repo names + contact information of the top 3 contributors for each potentially impacted repository.

Imprint