Bash/zsh scripts. Part 3

if [[ -v KEY ]]; then
	export KEY="9e61f1c8210c120fcd41343fd2eb8734"
fi

curl -H "Authorization: admin:pass" -H "X-Key: $KEY" https://tenendo.com:8001

---

Scripts: threat model

• external attacker
• authenticated access to an application
• RCE in a docker container
• access to a single server
• access to a developer’s workstation

---

Export files

export KEY1=...
export KEY2=...
export TOKEN=...

• insecure, but still widely used
• almost the worst case scenario for script secret management

---

Auditing shell scripts

[!NOTE] Could be integrated into a CI/CD pipeline.

• custom auditing for shell scripts in general
• filtering for export, sshpass and other hard-coded secrets
• regex-based secret detection akin to trufflehog

---

Scripts: keyctl/pass/gpg

• decryption of passwords in runtime (with its own disadvantages)
• secure storage of secrets in kernel memory

APIKEY=$(pass Keys/apikey) ./run
vs
APIKEY=$(< ~/.local/share/apikey) ./run

---

Scripts: externally audited store

• auditing and alerts
• could provide a stable IoC

SECRET=$(vault kv get -field foo secret/mysecret)

---

Logging

$ cat /data/logs/application.log | grep -i token | wc -l
37

---

Logging: Docker, scripts and build processes

[!NOTE] An example of this is also shown above.

• may contain heaps of environment information, leaking secrets in the process
• also may include a full cmdline of failed commands

docker logs <containerID>

---

logging: application logs

[!sidenote] Also applies to error handling, although out-of-scope for this training.

• applications often expose relevant environment details or implementation information in logs
• implementing logging and implementing logging sync are often done by different people
• logs are often excluded from the threat model

---

logging: auditing logs

• regexes on test environments
• manual review (if there is some spare time)
• red team (if they get to them)