Explanation on Why the Build Job is Successful in the DNS Tutorial

[cedricvanrompay-datadog]

I just tried the following tutorial: https://github.com/step-security/attack-simulator/blob/1948a848cc4bdfb224343b29b9ca010da3488c12/docs/DNSExfiltration.md

Here is the fork I created: https://github.com/DataDog/step-security-agent-attack-simulator

At the end I do get the same result as the screenshot in the tutorial, that is, the "build" job is successful but has an "Error: DNS resolution [...] was blocked" annotation.

However, I am quite surprised that the build job is successful if the hardened runner blocked the DNS resolution, right?

Moreover, if I click on the "build" job and expand the "Simulate DNS traffic" section, it looks like the DNS call was successful, meaning that the DNS exfiltration attack would have worked right?

Run domain="${GITHUB_REPOSITORY}.stepsecurity.io"
Server:     127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:   DataDog-step-security-agent-attack-simulator.stepsecurity.io
Address: 54.185.253.63

Isn't this "a valid response from the DNS server"?

[varunsh-coder]

I just tried the following tutorial: https://github.com/step-security/attack-simulator/blob/1948a848cc4bdfb224343b29b9ca010da3488c12/docs/DNSExfiltration.md

Here is the fork I created: https://github.com/DataDog/step-security-agent-attack-simulator

Hi @cedricvanrompay-datadog, thanks a lot for trying this out and creating the issue!

I am sorry for the delay in responding. I had not noticed the issue.

At the end I do get the same result as the screenshot in the tutorial, that is, the "build" job is successful but has an "Error: DNS resolution [...] was blocked" annotation.

However, I am quite surprised that the build job is successful if the hardened runner blocked the DNS resolution, right?

harden-runner does not fail a job if a DNS request or a network connection is blocked. The job might fail if it needs the connection, but harden-runner does not cause it to fail. This is a design decision, as some jobs make calls to endpoints that are not needed but not in the allowed list (example), which may cause jobs to fail unnecessarily. We have an issue tracking this to provide a flag to fail the job if any traffic is blocked/ harden-runner annotation is added. https://github.com/step-security/harden-runner/issues/195

Moreover, if I click on the "build" job and expand the "Simulate DNS traffic" section, it looks like the DNS call was successful, meaning that the DNS exfiltration attack would have worked right?

Run domain="${GITHUB_REPOSITORY}.stepsecurity.io"
Server:       127.0.0.53
Address:  127.0.0.53#53

Non-authoritative answer:
Name: DataDog-step-security-agent-attack-simulator.stepsecurity.io
Address: 54.185.253.63

Isn't this "a valid response from the DNS server"?

When harden-runner blocks DNS exfiltration, it returns our sinkhole IP address instead of blocking the request. You can see the code here. https://github.com/step-security/agent/blob/main/dnsproxy.go#L193-L213 This enables the rest of the steps to continue, where a network connection may be established after the DNS request, and this enables us to find the process that made the call. So, what you see is a valid response from our DNS proxy but also a valid DNS exfiltration block. Please let me know if you have any follow up questions. Thanks!

[cedricvanrompay-datadog]

Thanks for your answers!