Listing AWS Public EBS Snapshots

Create Volume Permissions

The create volume permissions fall into the following categories:

       o public : The owner of the snapshot granted create volume  permissions
         for  the snapshot to the all group. All AWS accounts have create vol-
         ume permissions for these snapshots.

       o explicit : The owner of the snapshot granted  create  volume  permis-
         sions to a specific AWS account.

       o implicit  : An AWS account has implicit create volume permissions for
         all snapshots it owns.

--filters

 o owner-alias  - Value from an Amazon-maintained list (amazon | self
            | all | aws-marketplace | microsoft ) of snapshot owners.  Not  to
            be  confused  with the user-configured AWS account alias, which is
            set from the IAM console.

Run aws ec2 describe-snapshots help to get the help for command in scope.

Below command lists public EBS snapshots
praveend$ aws ec2 describe-snapshots --profile pd-dev --region us-east-1 --output table --filters Name=owner-alias,Values=all

Testing/Writing Chef Cookbooks

Writing cookbooks

Cookbooks has attributes, recipes, templates etc


Using Community cookbooks

1. Modify Berksfile in the cookbook by adding cookbook name, say, cookbook 'yum-centos', '~> 3.0.0'
2. Modify metadata.rb in cookbook by updating dependencies, say, depends 'yum-centos', '~> 3.0.0'
3. Execute below commands

$ berks install
$ berks upload

Prerequisites

Make sure we have below configs/files

• Chef cookbook
• Chef Environment
• Chef Role

Testing cookbook locally

1. Install vagrant from https://www.vagrantup.com/downloads.html
2. Install Virtualbox
3. Modify .kitchen.yml file referring to community cookbook recipe to test locally.
4. Goto cookbook directory and execute kitchen commands to build, list, login to new created resource from chef cookbooks.

$ kitchen converge
$ kitchen list
$ kitchen login

Update authentication key
# Connect to chef server 

[pd@ip-disects ~]$ ssh -A -t SSH_SERVER_IP 

# Following commands are executed on chef server 

[pd@ip-disects ~]$ sudo chef-server-ctl user-create praveend Praveen Darshanam praveend@chef.io Myp@ssw0rd -f /tmp/praveend.key 

ERROR: Conflict 

Response: Username or email address already in use. 

[pd@ip-disects ~]$ sudo chef-server-ctl user-delete praveend 

Do you want to delete the user praveend? (Y/N) y 

Checking organization memberships... 

Checking admin group memberships for 1 org(s). 

FATAL: praveend is in the 'admins' group of the following organization(s): 

- disects



Run this command again with the --remove-from-admin-groups option to remove the user from these admin group(s) automatically. 

[pd@ip-disects ~]$ sudo chef-server-ctl user-delete praveend --remove-from-admin-groups 

Do you want to delete the user praveend? (Y/N) y 

Checking organization memberships... 

Checking admin group memberships for 1 org(s). 

Removing praveend from admins group of 'disects' 

Deleting user praveend. 

[pd@ip-disects ~]$ sudo chef-server-ctl user-create praveend Praveen Darshanam praveend@chef.io Myp@ssw0rd -f /tmp/praveend.key 

[pd@ip-disects ~]$ sudo chef-server-ctl org-user-add disects praveend --admin 

User praveend is added to admins and billing-admins group


Upload working cookbook to chef server after local testing. Test the cookbook on a cluster node to make sure everything is working fine, this needs some experience though.

$ knife cookbook upload cookbook_name

Kubernetes ingress custom Certificates with valid CA

Irrespective of ingress FQDN, Kubernetes creates Certificates with domain name ingress.local which creates below issues.
CoreOS Dex need certificates from valid CA, self-signed certificates will now work
Gardener dashboard authentication has issues with self-signed certificates. AuthN flow will not happen without accepting invalid Cert error
Accessing ingress in any browser will complain self-signed server error

Fix: Lets encrypt


Install Certbot from LetsEncrypt

$ brew install certbot

Create wildcard Certificate for domain, *.pd.example.com 

Before entering Yes to confirm, make sure you add TXT record entry as prompted by certbot.

# create directories named le_wd, le_cd, le_ld before executing below command
$ certbot certonly --manual -d *.pd.example.com  --work-dir=le_wd --config-dir=le_cd --logs-dir=le_ld 

# Check if certificates are created
$ certbot certificates --work-dir=le_wd --config-dir=le_cd --logs-dir=le_ld

Certs are located at le_cd/live/pd.example.com /


Create secret with the Certificates we want to use

$ kubectl create secret tls pd-custom-certs --key pd.example.com.key --cert pd.example.com.crt -n namespace_of_interest

Configure ingress with the TLS secret.
----SNIP(FQDN 1)---- ingress: enabled: true path: / hosts: - a.pd.example.com tls: - hosts: - a.pd.example.com secretName: pd-custom-certs ----SNIP(FQDN 2)---- ingress: enabled: true path: / hosts: - b.pd.example.com tls: - secretName: pd-custom-certs hosts: - b.pd.example.com

Accessing ingress should not show invalid Cert errors now.

Kubernetes Pod Security Policies

Start minikube with RBAC and admission-plugins enabled

$ minikube start --extra-config=apiserver.authorization-mode=Node,RBAC --extra-config=apiserver.enable-admission-plugins=PodSecurityPolicy
# or
$ minikube start --extra-config=apiserver.authorization-mode=Node,RBAC --extra-config=apiserver.Admission.PluginNames=PodSecurityPolicy

These commands are not working on my Mac machine, looks like API Server issue as it is not accepting any requests (might not be up).

Create namespace and Service Account

$ kubectl create namespace praveend-psp kubectl create sa test-psp-sa -n praveend-psp

Policy definitions

Kubernetes Privilege Escalation (CVE-2018-1002105)

Introduction

Kubernetes is an open source production grade container orchestration system for deploying and managing docker/container applications. There are managed kubernetes orchestration service providers like Amazon Elastic Container Service for Kubernetes (EKS), Azure Kubernetes Service (AKS) etc.

kubectl

Kubernetes cluster users can perform management tasks using kubectl binary which talks to API Server. Example kubectl commands

# display pod resource
kubectl get pods -n my_namespace

# Execute a command in a container
kubectl -n my_namespace exec -it pods_name -- sh


# Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod
kubectl -n my_namespace port-forward pod/mypod 5000 6000

# Get output from ruby-container from pod my-pod-pd

kubectl attach my-pod-pd -c ruby-container

kubectl execution flow (source: 1ambda.github.io)

kubelet

kubelet, kube-proxy run's on each compute node (VM, Worker, EC2 Instance etc), kubelet listens on TCP port 10250 and 10255 (with no authentication/authorization). API Server acts as Reverse Proxy to kubelet and API Aggregation. API Server connects to the kubelet to fulfill commands like exec, port=forward and opens a websocket connection which connects stdin, stdout, or stderr to user’s original call [01].

API Aggregation

Installing or writing additional API's into Kubernetes API Server i.e. extending core API Server

Vulnerability

Vulnerability is in Kubernetes API Server, crafted request can execute arbitrary commands on the backend servers (pods) through the same channel client established to backend through API Server [02]

Check nodes Kubernetes version

$ kubectl get nodes -o wide
NAME        STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
pd-worker-01 Ready node 13d v1.12.3 10.250.0.6 Container Linux by CoreOS 1745.7.0 (Rhyolite) 4.14.48-coreos-r2 docker://18.3.1
pd-worker-02 Ready node 13d v1.12.3 10.250.0.5 Container Linux by CoreOS 1745.7.0 (Rhyolite) 4.14.48-coreos-r2 docker://18.3.1
pd-worker-03 Ready node 13d v1.12.3 10.250.0.4 Container Linux by CoreOS 1745.7.0 (Rhyolite) 4.14.48-coreos-r2 docker://18.3.1

Vulnerable API Servers

If API server response looks as bellow and using vulnerable API versions of Kubernetes the you are vulnerable using anonymous-user escalation, patch Kubernetes immediately.
HTTP response error code 403 indicates Forbidden i.e. related to Authorization implies we successfully passed through Authentication phase.
{ "kind": "Status", "apiVersion": "v1", "metadata": { }, "status": "Failure", "message": "forbidden: User \"system:anonymous\" cannot get path \"/api/v1/\"", "reason": "Forbidden", "details": { }, "code": 403 }

anonymous user

By default, requests to the kubelet’s HTTPS endpoint that are not rejected by other configured authentication methods are treated as anonymous requests, and given a username of system:anonymous and a group of system:unauthenticated.

Mitigations

There are three levels of escalation mitigations

1. anonymous user -> aggregated API server

API Server admission-controller parameter anonymous-auth is set to fault

$ kubectl get po kube-apiserver-01 -n prod -o yaml | grep -i "anonymous-auth" - --anonymous-auth=false 
$ kubectl get po kube-apiserver-01 -n stage -o yaml | grep -i "anonymous-auth" - --anonymous-auth=false

2. authenticated user -> aggregated API server

Suspend aggregated API servers usage

3. authorized pod exec/attach/portforward -> kubelet API

Remove pod exec/attach/portforward permissions for users

References

[01]. https://docs.openshift.com/container-platform/3.11/architecture/networking/remote_commands.html
[02]. https://docs.openshift.com/container-platform/3.11/architecture/networking/remote_commands.html
[03]. https://elastisys.com/2018/12/04/kubernetes-critical-security-flaw-cve-2018-1002105/
[04]. https://github.com/kubernetes/kubernetes/issues/71411

AWS VPC Flow Logs grok Pattern

Amazon Web Services(AWS) can generate VPC flow logs, format below
2 123456789010 eni-abc123de 172.31.9.69 172.31.9.12 49761 3389 6 20 4249 1418530010 1418530070 REJECT OK

For more information on flow logs and grok filter plugin refer below links
https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html
https://www.elastic.co/guide/en/logstash/current/plugins-filters-grok.html

grok patterns can be tested using below links
http://grokdebug.herokuapp.com
http://grokconstructor.appspot.com/do/match#result

%{NONNEGINT:version} %{NONNEGINT:accountid} %{NOTSPACE:interface-id} %{NOTSPACE:srcaddr} %{NOTSPACE:dstaddr} %{NONNEGINT:srcport} %{NONNEGINT:dstport} %{NONNEGINT:protocol} %{NONNEGINT:packets} %{NONNEGINT:bytes} %{NONNEGINT:starttime} %{NONNEGINT:endtime} %{NOTSPACE:action} %{NOTSPACE:log-status}

Test using grokdebugger

Test using grokconstructor

You can also consider INT instead of NONNEGINT


Found few patterns by googling which looked like below, were not working on grokconstructor website.
%{NUMBER:version} %{NUMBER:account-id} %{NOTSPACE:interface-id} %{NOTSPACE:srcaddr} %{NOTSPACE:dstaddr} %{NOTSPACE:srcport:int} %{NOTSPACE:dstport:int} %{NOTSPACE:protocol:int} %{NOTSPACE:packets:int} %{NOTSPACE:bytes:int} %{NUMBER:start:int} %{NUMBER:end:int} %{NOTSPACE:action} %{NOTSPACE:log-status}

Tested on grokdebugger

Tested on grokconstructor

We can use the extracted variables from grok filter plugin in Kibana search or enhance data using logstash filter plugins geoip, dns, date etc.

Working in or using Python virtualenv

Install Python virtualenv on Ubuntu using below command
apt-get -y install python-virtualenv

Create virtualenv
$virtualenv test_env1
New python executable in test_env1/bin/python

$. test_env1/bin/activate
Or
$source test_env1/bin/activate

Exit virtualenv
$deactivate

Switch between virtualenv’s
$workon test_env2

List all available virtualenv’s
$workon


virtualenvwrapper comes with few handy commands

$pip install virtualenvwrapper

virtualenvwrapper supports extra commands like
mkvirtualenv
cdvirtualenv
rmvirtualenv

Linux: Recovering files deleted using "rm -rf"

Removed python script file by accident. Following two methods worked for me in retrieving the file.

Trick 1:

This was posted on askubuntu.com

$grep -a -B 40 -A 80 'string_from_file' /dev/sda1 > save_here.txt

-A 100 save 80 lines after match
-B 40 save 40 lines before match
string_from_file at least one unique string you remembered from deleted file
save_here.txt    retrieved content is copied here

Trick 2:

$lsof | grep -i "/path/to/file"
progname 1234 user_name 44 8,1 43219876 432890 /path/to/file

$cp /proc/1234/fd/44 /restore/file/tothis/path

Retrieved files might have unnecessary data or few lines might be arranged in reverse order.

FinTech, Mobile Applications and Vulnerabilities

MOBILE APPLICATION VULNERABILITIES

Reverse Engineering: Applications published on Google Play or Apple App Store can be reverse engineered by malicious users and create similar applications. Companies can lose their intellectual property.

Insecure Data Storage: FinTech related applications save sensitive data like personally identifiable information (PII), card data (PCI), health information etc. Sensitive personal information saved on mobile should be encrypted.

SSL Pinning bypass: SSL Pinning will

One Time Password: OTP is used as second level of authentication.

OTP Spamming: OTP Spamming is requesting an API/URL which generates OTP by spoofing mobile number to victims phone number. If there is no proper validation, attacker can send many OTP SMS’s to victim phone

OTP Bypass:

-       Modifying checks: OTP validation can be bypassed by modifying checks in the request payload or URI parameters

-       Bypassing SS7

-       Malicious mobile apps sniffing OTP’s

WEB APPLICATION VULNERABILITIES

All OWASP Top 10 or SANS Top 25 Vulnerabilities will be applicable.

- Cross Site Scripting (XSS): If the input values from user is not validated it might lead to java script execution vulnerabilities which might lead to cookie theft, redirection to malicious websites, DDoS attacks on other sites etc..

- SQL Injection: Improper input validation might lead to SQL Injection.

Privilege Escalation: If the authorization is not enforced properly, one user can access other users data.

- Authentication bypass

            SQL Injection

            Session ID Guessing

            Cookie values

- Command Execution: Improper input validation might lead to OS command execution

- Serialization/Deserialization: Data interpreted as code because of improper validation. This might lead to code execution in Java, PHP, Python

- CSRF

- WAF Bypass

- Ratelimiting Issues

            Important API’s

            Forgot/Reset Password

            Login page

            Other important/sensitive API’s

- XXE (XML External Entity) Attack

- SSRF (Server Side Request Forgery)

- JSON Injection

- DoS/DDoS (Layer 3, Layer 4 and Layer 7 attacks)

AWS INFRA

- Public S3 buckets: Will have files

- Public EBS Volumes: Might have sensitive information like SSH Keys, Server Keys, passwords etc.

- No Multi Factor Authentication (MFA, 2FA) to AWS

- Root logins

- Token Disclosure

            Slack

            Git

MISCELLANEOUS       

Crypto Currency based exploitation in future

Sub-domain takeover

Vulnerabilities in protocols

-->

Vulnerabilities in Hardware

Vault7: Malware and Disk I/O (Input Output)

aa
Following were the guidelines given to Malware authors at CIA, how to deal with Disk I/O and steps taken to save data on to disk or deleting saved date from disk.

Directive	Rationale
DO explicitly document the "disk forensic footprint" that could be potentially created by various features of a binary/tool on a remote target.	Enables better operational risk assessments with knowledge of potential file system forensic artefacts.
DO NOT read, write and/or cache data to disk unnecessarily. Be cognizant of 3rd party code that may implicitly write/cache data to disk.	Lowers potential for forensic artefacts and potential signatures.
DO NOT write plain-text collection data to disk.	Raises difficulty of incident response and forensic analysis.
DO encrypt all data written to disk.	Disguises intent of file (collection, sensitive code, etc) and raises difficulty of forensic analysis and incident response.
DO utilize a secure erase when removing a file from disk that wipes at a minimum the file's filename, datetime stamps (create, modify and access) and its content. (Note: The definition of "secure erase" varies from filesystem to filesystem, but at least a single pass of zeros of the data should be performed. The emphasis here is on removing all filesystem artefacts that could be useful during forensic analysis)	Raises difficulty of incident response and forensic analysis.
DO NOT perform Disk I/O operations that will cause the system to become unresponsive to the user or alerting to a System Administrator.	Avoids unwanted attention from the user or system administrator to tool's existence and behavior.
DO NOT use a "magic header/footer" for encrypted files written to disk. All encrypted files should be completely opaque data files.	Avoids signature of custom file format's magic values.
DO NOT use hard-coded filenames or filepaths when writing files to disk. This must be configurable at deployment time by the operator.	Allows operator to choose the proper filename that fits with in the operational target.
DO have a configurable maximum size limit and/or output file count for writing encrypted output files.	Avoids situations where a collection task can get out of control and fills the target's disk; which will draw unwanted attention to the tool and/or the operation.

Vault7: Malware evasion and Reverse Engineering difficulty Comparison

This is basically Do's and Don'ts for a Malware author. Below table explains how a malware author can bypass different AntiVirus engines, by reversing the logic we can use similar concepts to detect the malware. Below pointers apply to PE files, Mach-O, ELF and other binaries.

Evasion	Rationale/Detection
DO obfuscate or encrypt all strings and configuration data that directly relate to tool functionality. Consideration should be made to also only de-obfuscating strings in-memory at the moment the data is needed. When a previously de-obfuscated value is no longer needed, it should be wiped from memory.	String data and/or configuration data is very useful to analysts and reverse-engineers.
DO NOT decrypt or de-obfuscate all string data or configuration data immediately upon execution.	Raises the difficulty for automated dynamic analysis of the binary to find sensitive data.
DO explicitly remove sensitive data (encryption keys, raw collection data, shellcode, uploaded modules, etc) from memory as soon as the data is no longer needed in plain-text form. DO NOT RELY ON THE OPERATING SYSTEM TO DO THIS UPON TERMINATION OF EXECUTION.	Raises the difficulty for incident response and forensics review.
DO utilize a deployment-time unique key for obfuscation/de-obfuscation of sensitive strings and configuration data.	Raises the difficulty of analysis of multiple deployments of the same tool.
DO strip all debug symbol information, manifests(MSVC artefact), build paths, developer usernames from the final build of a binary.	Raises the difficulty for analysis and reverse-engineering, and removes artefacts used for attribution/origination.
DO strip all debugging output (e.g. calls to printf(), OutputDebugString(), etc) from the final build of a tool.	Raises the difficulty for analysis and reverse-engineering.
DO NOT explicitly import/call functions that is not consistent with a tool's overt functionality (i.e. WriteProcessMemory, VirtualAlloc, CreateRemoteThread, etc - for binary that is supposed to be a notepad replacement).	Lowers potential scrutiny of binary and slightly raises the difficulty for static analysis and reverse-engineering.
DO NOT export sensitive function names; if having exports are required for the binary, utilize an ordinal or a benign function name.	Raises the difficulty for analysis and reverse-engineering.
DO NOT generate crash dump files, core dump files, "Blue" screens, Dr Watson or other dialog pop-ups and/or other artefacts in the event of a program crash. DO attempt to force a program crash during unit testing in order to properly verify this.	Avoids suspicion by the end user and system admins, and raises the difficulty for incident response and reverse-engineering.
DO NOT perform operations that will cause the target computer to be unresponsive to the user (e.g. CPU spikes, screen flashes, screen "freezing", etc).	Avoids unwanted attention from the user or system administrator to tool's existence and behaviour.
DO make all reasonable efforts to minimize binary file size for all binaries that will be uploaded to a remote target (without the use of packers or compression). Ideal binary file sizes should be under 150KB for a fully featured tool.	Shortens overall "time on air" not only to get the tool on target, but to time to execute functionality and clean-up.
DO provide a means to completely "uninstall"/"remove" implants, function hooks, injected threads, dropped files, registry keys, services, forked processes, etc whenever possible. Explicitly document (even if the documentation is  "There is no uninstall for this ") the procedures, permissions required and side effects of removal.	Avoids unwanted data left on target. Also, proper documentation allows operators to make better operational risk assessment and fully understand the implications of using a tool or specific feature of a tool.
DO NOT leave dates/times such as compile timestamps, linker timestamps, build times, access times, etc. that correlate to general US core working hours (i.e. 8am-6pm Eastern time)	Avoids direct correlation to origination in the United States.
DO NOT leave data in a binary file that demonstrates CIA, USG, or its witting partner companies involvement in the creation or use of the binary/tool.	Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future USG operations and equities.
DO NOT have data that contains CIA and USG cover terms, compartments, operation code names  or other CIA and USG specific terminology in the binary.	Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future USG operations and equities.
DO NOT have "dirty words" in the binary.	Dirty words, such as hacker terms, may cause unwarranted scrutiny of the binary file in question.

CIA - Central Intelligence Agency
USG - United States Government