I just dedicate half an hour to an hour every day to exercise and to study a little bit, and I still get my other work done. It’s a discipline, and there’s no easy answer John. That’s the best. I think, unfortunately, you’re exactly correct.
Jim Manico
Recently I watched a talk from Tanya Janca on DevSecOps worst practices. The talk is interesting because I have seen similar practices during the early adoption stage of DevSecOps processes and culture. If you find that your DevSecOps practices have plateaued, chances are that your program is practicing some of the bad practices.
Below is a list of bad practices mentioned by Tanya:
I will only highlight a few of these practices and share my thoughts.
Testing a new tool for effectiveness is HARDER than we think. Usually POC on a vendor product has a limited timeframe (about one month plus). And you need to identify the teams that are suitable to test the products. If you chose the wrong team to test the product, you might jump into conclusion that this product is bad. Or if you test it on only subset of team, we still find it uncertain if the performance can be replicated to other teams who are using a different tech stack.
Tanya mentioned that one way we can do is buy perpetual license and trial it for about 6 months before deciding to purchase a larger contract. I think this is a good recommendation.
From vendor point of view, you should think about how you can let the security team try the important features of product and test it sufficiently so that they can make better conclusions.
Tanya gave an example about how the development team can disable tests in order to deploy to production. If too much permission is given to the team, some might abuse the permissions to reach their goal.
In general, I think CI is a wild jungle where you can run any scripts or workflows. But the crucial thing is to restrict the permissions for deployment (CD). If we control the permissions better, we can stop people from abusing deployment rights.
In some organizations, there are strict SLA requirements for deployment to production. For example, there can be a SLA that “NO CRITICAL or HIGH” issues in production.
This might be impossible to meet for some of the teams (Especially if they have legacy apps). Tanya recommends that Security team should consult other teams to see if this SLAs is feasible. Listen to see if the teams can fix the issues to meet the SLAs.
When writing a AWS lambda function, we need to be careful about secure coding issues.
If your lambda function takes an input and use it to run a command, you need to avoid using os.system(...). You should use subprocess.run(...) but without the shell. The commands provided to subprocess should be in arguments.
I will use an example of AWS Lambda function that takes an input from event and uses it in a subprocess to run a command. Notice the command is used in a f-string.
import subprocess
import uuid
def lambda_handler(event, context):
rand_value = uuid.uuid4().hex[:6]
file_name = f'{event['file_name']}_{rand_value}'
print('Creating:', file_name)
result = subprocess.run(f'cd /tmp && touch {file_name} && ls -la', shell=True, stdout=subprocess.PIPE)
print(result.stdout.decode('utf-8'))We can inject a malicious filename to steal the values in env
ubuntu@ubuntu-virtual-machine:~$ python3 command_injection.py
Enter file name: hello && env | base64 #
Creating: hello && env | base64 #_526feb
R0pTX0RFQlVHX1RPUElDUz1KUyBFUlJPUjtKUyBMT0cKTEVTU09QRU49fCAvdXNyL2Jpbi9sZXNzcGlwZSAlcwpVU0VSPXVidW50dQpTU0hfQUdFTlRfUElEPTE0MDIKWERHX1NFU1NJT05fVFlQRT14MTEKU0hMVkw9MQpIT01FPS9ob21lL3VidW50dQpPTERQV0Q9L2hvbWUvdWJ1bnR1CkRFU0tUT1BfU0VTU0lPTj11YnVudHUKR05PTUVfU0hFTExfU0VTU0lPTl9NT0RFPXVidW50dQpHVEtfTU9EVUxFUz1nYWlsOmF0ay1icmlkZ2UKTUFOQUdFUlBJRD0xMDI5CkRCVVNfU0VTU0lPTl9CVVNfQUREUkVTUz11bml4OnBhdGg9L[...]We should refactor the vulnerable code by adding two defences:
Dependings on the context, try to whitelist the allowed characters.
If you do not know in advanced then it is crucial that you follow the next defence of using arguments command for subprocess.
Instead of providing the commands in concatenated string or string format, provide an argument format ['touch', file_name]. This means you need to break down the command in different `subprocess` calls. You cannot run the multiple commands in one single subprocess.
One common routine is that you need to run a sequence of command at a specific same directory. With the use of cwd argument in subprocess.run(...), you can specify where the command should be executed.
import subprocess
import uuid
def lambda_handler(event, context):
rand_value = uuid.uuid4().hex[:6]
file_name = f'{event['file_name']}_{rand_value}'
print('Creating:', file_name)
working_dir = '/tmp'
subprocess.run(['touch', file_name], cwd=working_dir, stdout=subprocess.PIPE)
result = subprocess.run(['ls', '-la'], cwd=working_dir, stdout=subprocess.PIPE)
print(result.stdout.decode('utf-8'))Canary Token is a great idea for early detection of possible intrusion in your system.
But be careful when you are using the free service from Thinkst Canary (https://canarytokens.org/generate) to generate Canary AWS tokens. You shouldn’t use it for real life production.
A threat actor may notice a common pattern in the AWS access key id (generated from Thinkst Canary) and avoid triggering your honeypot detection.
Aidan Steele wrote an in-depth article on AWS Access Key ID format. Highly recommend to read it.
Things to note from Aidan’s article:
We can get the AWS account id from the access key by using the aws-cli
$ aws sts get-access-key-info --access-key-id <<ACCESS_KEY_ID>> --query Account --no-cli-pager
xxxxxxxxxxxxxxxxxxxxxxxxxxxLet’s generate a few Canary tokens from https://canarytokens.org/generate
[default]
aws_access_key_id = AKIAYVP4CIPPxxxxxxxU
aws_secret_access_key = xxxxxxxx
output = json
region = us-east-2[default]
aws_access_key_id = AKIAYVP4CIPPxxxxxxxW
aws_secret_access_key = xxxxxxxxx
output = json
region = us-east-2As you can see from the two generated Canary token, the four chars of the access key id show that this is an access key. Then the next crucial pattern (next 8 chars) will expose the information that this access key belongs to the AWS account from the free Canary token service.
A smart threat actor will detect this pattern and avoid using it. As a result, your Canary Token honeypot will likely to fail.
Below are some of the configurations of Gitea that are useful for security hardening:
Config Reference: https://docs.gitea.io/en-us/config-cheat-sheet/
The more features we disable, the less attack surfaces we will face when using Gitea.
version: "3"
networks:
gitea:
external: false
volumes:
gitea-data:
driver: local
gitea-config:
driver: local
services:
server:
image: gitea/gitea@sha256:ef6279e13e223d956bc417f299a3530795afcf79f3af429a5c893262c550a648
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
- GITEA__repository__DISABLE_DOWNLOAD_SOURCE_ARCHIVES=true
- GITEA__repository__DISABLE_HTTP_GIT=true
- GITEA__repository__repository.upload__ENABLED=false
- GITEA__server__DISABLE_SSH=true
- GITEA__security__DISABLE_GIT_HOOKS=true
- GITEA__security__DISABLE_WEBHOOKS=true
- GITEA__security__PASSWORD_COMPLEXITY=on
- GITEA__security__MIN_PASSWORD_LENGTH=10
- GITEA__attachment__ENABLED=false
- GITEA__api__ENABLE_SWAGGER=false
- GITEA__packages__ENABLED=false
- GITEA__migrations__ALLOWED_DOMAINS=github.com,*.github.com
- GITEA__repository__MAX_CREATION_LIMIT=0
- GITEA__security__PASSWORD_HASH_ALGO=argon2
- GITEA__mirror__DISABLE_NEW_PUSH=true
- GITEA__service__DISABLE_REGISTRATION=true
- GITEA__repository__DISABLED_REPO_UNITS=repo.issues, repo.ext_issues, repo.pulls, repo.wiki, repo.ext_wiki, repo.projects
- GITEA__service__DEFAULT_ALLOW_CREATE_ORGANIZATION=false
- GITEA__service__DEFAULT_USER_IS_RESTRICTED=true
- GITEA__repository__DISABLE_MIGRATIONS=true # Set as false when there is new mirror
- GITEA__mirror__DISABLE_NEW_PULL=true # Set as false when there is new mirror
restart: always
networks:
- gitea
volumes:
- gitea-data:/var/lib/gitea
- gitea-config:/etc/gitea
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "222:22"
Create a docker.compose.yml file with the latest Gitea rootless image:
version: "3"
networks:
gitea:
external: false
services:
server:
image: gitea/gitea@sha256:ef6279e13e223d956bc417f299a3530795afcf79f3af429a5c893262c550a648
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
restart: always
networks:
- gitea
volumes:
- ./gitea:/data
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "222:22"Run a command to start Gitea as a docker image in your machine:
docker-compose --project-name gitea -f docker.compose.yml up -d
docker ps -a # Check if the containers are runningGo to localhost and you can see that a local instance of Gitea is running.
Create a Web app in Okta:
Configure the redirect URL: http://localhost:3000/user/oauth2/okta/callback
Save the Client Id and Client secret that will be input into Gitea
You must name the authentication to be the same name under the redirect url. In this case, I have name it as okta
http://localhost:3000/user/oauth2/okta/callback
The admin should paste the Client Id and Client secrets from Okta app to the Authentication Sources tab in “Site Administration”.
Sign in with OpenID
You will be redirected to Okta for authentication (ensure MFA is enabled preferably with FIDO2)
If this is the first time that you login with Gitea, you will need to fill in your username and email address to create an account.
Suppose you have a Github Actions script like below:
The script will be triggered when a new issue comment is added to the issue or a comment is edited.
name: GitHub Actions Demo
on:
issue_comment:
types: [created, edited]
jobs:
Explore-GitHub-Actions:
runs-on: ubuntu-latest
steps:
- run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
- run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
- run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
- run: echo ${{ github.event.comment.body }}
Notice that ${{ github.event.comment.body }} is used in the run step directly? This makes the script vulnerable to Command Injection. Why?
Read this: https://securitylab.github.com/research/github-actions-untrusted-input/#remediation
In this context, someone can inject commands to the GH Action script by adding their payload to the issue comment. The GH Action script is triggered every time there is a new issue comment.
Did you notice we can run echo bye? This is just a simple example but worse scenario can be reverse-shell (if you are using self-hosted GH Runners) or secrets theft.
You can even attack in a stealth mode by deleting the comment immediately once the workflow is triggered.
Set the github context data in env variable before you use it in the run
[...]
- env: # Add this
BODY: ${{ github.event.comment.body }} # Add this
run: echo "$BODY"Add a new comment that contains a payload:
You can see the script is interpreting the comment body as string rather than interpolating it as a command to execute.
Book Link: https://www.amazon.com/Art-Impossible-Peak-Performance-Primer/dp/0062977539
Personal Notes:
Although the book presented like an algorithmic process for triggering flow that help to accomplish the daily tasks, the process is not so linear. You might not know what are your MTP (massively transformative purposes) while reading the book. This discovery of your MTP might take time and explorations of your curiosity.How do you even have 25 list of items that you are curious about? It can be things that you learn from books, online courses, youtube videos, internet forums, social media or from friends etc. Everytime you consume the information, take note of what you are curious about and the questions that you want to ask further on a specific area.
In order to read the Git Blob objects, we need to understand that git uses zlib to compress the stored objects. We can use the Java zip utils to decompress the Git blob.
Below are some methods of decompressing the Blob file. If you did some research online, you will find many examples showing Method 1.
But I recommend using Method 2 as it is does not assume the size of the decompressed file. This method is also used in Apache Commons library.
Make sure the binary file is not corrupted or you might encounter
java.util.zip.ZipException
Method 1
The byte array size of result can be arbitrarily set with a specific size. But you will have problems if the decompressed file size is uncertain.
String file = "<PATH to Git blob>";
byte[] fileBytes = Files.readAllBytes(Paths.get(file));
Inflater decompresser = new Inflater();
decompresser.setInput(fileBytes, 0, fileBytes.length);
byte[] result = new byte[1024]; // Size need to be set
int resultLength = 0;
resultLength = decompresser.inflate(result);
decompresser.end();Method 2: Checks if end of compressed data is reached
This method reads the content of the file and output to ByteArrayOutputStream object.
String file = "<PATH to Git blob>";
byte[] fileBytes = Files.readAllBytes(Paths.get(file));
Inflater inflater = new Inflater();
inflater.setInput(fileBytes);
ByteArrayOutputStream outputStream = new ByteArrayOutputStream(fileBytes.length);
byte[] buffer = new byte[1024];
while (!inflater.finished()) {
int count = inflater.inflate(buffer);
outputStream.write(buffer, 0, count);
}
outputStream.close();
byte[] result = outputStream.toByteArray();Highly recommend security researchers to watch this. The talk focuses more toward improving your methodology and mindset: