4 ms·
Bypass idea 1: exfiltrate data to known hosts. For example, "github.com" is likely whitelisted - so post stolen credentials as an issue comment in a little-know
by theamk 5y ago
Bypass idea 1: exfiltrate data to known hosts. For example, "github.com" is likely whitelisted - so post stolen credentials as an issue comment in a little-known repository? Or maybe push the stolen data to some repo?
Bypass idea 2: before exfiltrating data, stop (or somehow mess with) the agent. After all, both github actions and user code have the same permissions on the runner.
- varunsharma07 5y agoThanks for the feedback! w.r.t Bypass idea 1: If the compromised step is not supposed to call github.com, this will immediately get detected. This is the advantage of having outbound traffic correlated per step. Most steps do not need to call github.com. In the future, the plan is to also have application level policy, e.g. only allow 'GET https://github.com/owner/repo https://github.com/owner/repo'. w.r.t Bypass idea 2: in the future, the plan is to have a policy to disable sudo. Once that is done, user code will not be able to mess with the agent.