Offensive AWS — Attacking Identity and Access Management (IAM)

Pada saat awal mulai belajar AWS Security, saya pikir hal utama untuk dipelajari adalah berbagai macam services yang disediakan AWS tapi ternyata setelah saya memahami konsep Attack Vector yang ada di environment AWS itu mostly karena kesalahan permission yang dimana itu berhubungan dengan IAM, dan IAM adalah service AWS yang melakukan managemen terkait Access Control baik itu proses autentikasi ataupun autorisasi, karena di IAM semua permission itu setting, dan apabila ada kesalahan konfigurasi permission di IAM akan berakibat fatal khusus nya permission yang berhubungan dengan action WRITE (Create, Update, Delete, Attach). Oleh karena itu IAM merupakan salah satu service yang paling penting untuk dipelajari apabila ingin melukan pentesting atau operasi red team di environment AWS.

Source : https://www.msp360.com/resources/blog/aws-iam-policy/

Terdapat 3 Identities pada IAM yaitu Users, Groups, dan Roles yang dimana masing-masing identity ini akan di-attach Policies yang berisi permission yang akan menentukan identities ini bisa melakukan aksi apa saja terhadap resource yang disediakan AWS.

Users

Istilah user di IAM itu sebenarnya sama seperti istilah user pada aplikasi biasa, dimana dia bisa berinteraksi dengan fitur-fitur yang ada di AWS, akan tetapi batasan interaksi nya sesuai dengan permission yang di-attach ke user tersebut.

Sebagai contoh sebut saja terdapat IAM user “user1”, IAM user ini di-attach dengan policy bawaan AWS (AWS managed policy) yaitu “AmazonS3FullAccess” sehingga IAM user tersebut memiliki akses penuh terhadap service S3 untuk melakukan operasi READ (List, Get, Describe) dan WRITE baik itu untuk membuat bucket baru, mengupload objek, menghapus bucket, dan sebagainya.

Pada percobaan menggunakan AWS CLI, terlihat user1 ini tidak memiliki permission untuk melihat daftar Instances EC2, tetapi bisa melihat daftar bucket dan daftar object dari bucket “evil-corp-bucket” dikarenakan memang user1 ini HANYA memiliki permission Full Access ke S3 sesuai yang di-attach.

IAM user bisa di akses dengan 2 cara, yaitu :

  1. Programatic Access yaitu menggunakan Access Key dan Secret Access Key, akses dengan model ini biasa digunakan oleh aplikasi yang membutuhkan API dari AWS untuk mengakses berbagai macam service, semisal tool bawaan dari AWS sendiri “AWS CLI”, atau library boto3 python yang tujuanya nya tidak lain untuk mengakses resource AWS, sebagai contoh terdapat aplikasi Django yang akan memindahkan file yang di-upload user ke S3 Bucket.
  2. Password Access yaitu dengan mengakses Web Console AWS (GUI) dengan username dan password. Dari kedua jenis cara akses tersebut sama sekali tidak ada perbedaan fitur yang membedakannya hanyalah interface-nya saja GUI dan CLI.

Programatic Access bisa di upgrade access nya ke Web Console AWS (GUI) apabila mempunyai permission sts:GetFederationToken, tool aws_consoler bisa digunakan untuk meng-generate session nya.

Note: Satu hal yang perlu ditegaskan, IAM user itu berbeda dengan root user, karena root user adalah user yang digunakan untuk proses mendaftar AWS dari awal, tetapi IAM user bisa di-attach dengan policy “AdministratorAccess” agar bisa mengelola semua resource yang ada.

Note: Root User sangat powerfull tidak bisa di limit, sehingga salah satu best practice nya adalah agar tidak menggunakan root user saat melakukan administrasi resource AWS, dan menghapus password-nya, lalu menggunakan IAM User.

Note: Federating User adalah user yang bukan merupakan member dari account kita, maksud nya akun disini adalah akun orang lain dan permission-nya bisa diberikan lewat IAM Role.

Groups

Kumpulan dari IAM users sehingga mempermudah dalam pemberian permission, jadi setiap user yang ada berada dalam grup ini, otomatis akan memliki permission yang di-attach ke grup ini. Sebagai contoh terdapat 2 member grup “Dev-S3” yaitu user1 dan user2 dan grup ini memiliki policy “AmazonS3ReadOnlyAccess” otomatis semua member dari grup ini akan mewarisi policy “AmazonS3ReadOnlyAccess” walaupun policy tersebut tidak di-attach di masing-masing user teersebut.

IAM Group Dev-S3
S3 Bucket listing

Roles

IAM Role adalah mekanisme pemberian “privilege” untuk melakukan operasi atau aksi tertentu ke service-service AWS. Permission nya tidak di-attach secara langsung ke IAM user ataupun IAM grup tapi ke Role itu sendiri.

Role tidak bisa berdiri sendiri dan harus diatur Principal-nya, dimana Principal ini bisa dibilang sebagai “whitelistresource yang bisa me-Assume atau menggunakan Role tersebut, dan Pricipal bisa berupa service AWS seperti Lambda, EC2, etc, atau User Account sendiri maupun User AWS Lain/Cross-Account (Federating User), sehingga resource yang malakukan Assume atau menggunakan IAM Role ini akan mempunyai permission yang sama dengan yang di-attach ke IAM role tersebut.

Sebagai contoh kita membuat role baru bernama S3ReadOnlyAccess-Role, lalu kita membuat instance profile untuk EC2 dan me-attach role S3ReadOnlyAccess-Role ke instance EC2, Maka Secara otomatis Instances tersebut akan memiliki privilege untuk melakukan operasi Read Only ke S3 tanpa harus menggunakan Credential yang dimana cara ini lebih aman.

Akses EC2 menggunakan SSH untuk memastikan bahwa dari EC2 tersebut kita bisa melakukan salah satu aksi Read Only yaitu listing bucket (READ ONLY ACCESS - sesuai dengan Policy yang di-attach) ke S3 Bucket walaupun tanpa menggunakan Credentials yang di-set.

EC2 Instance have the privilege to access S3

IAM Role yang di-attach sebagai instance profile di EC2 ini credential-nya akan disimpan di-metadata, oleh karena itulah saat aplikasi yang berjalan diatas EC2 terdapat celah seperti SSRF, temporary credentialnya bisa diakses oleh Attacker.

Tapi apabila yang meng-Assume nya adalah IAM User atau AWS User Account, credential nya harus di-set agar bisa digunakan, baik itu dengan aws configure ataupun dengan set env variable nya.

Nah credential dari hasil assume role tersebut bisa digunakan untuk melakukan kegiatan administrasi resource AWS.

Sebagai informasi, ACCESS_KEY_ID Credential yang didapatkan dari STS AssumeRole itu memiliki awalan ASIAXXXXXXX, sedangkan yang didapatkan dari Credential Dashboard IAM user berawalan AKIAXXXXXXXX

MITRE ATT&CK : AWS Matrix

Initial Access

Seperti yang disinggung diatas, pengaksesannya bisa dengan secara Programatic atau Password Access.

Pada programatic access kita membutuhkan Security Credentials yang dimana ini terdiri dari ACCESS_KEY_ID dan SECRET_KEY_ID tapi apabila Security Credential bersifat Temporary ada tambahan SESSION_TOKEN.

Contoh Temporary Security Credential bisa didapatkan dari Instance EC2 Metadata yang biasa di-abuse via SSRF, environment variable Lambda Function, dari STS AssumeRole "aws sts assume-role", atau bahkan dari Harcoded credential yang berada di repository atau source code dari hasil reverse engineering.

IAM User Credentials Leaked, Source: https://swizec.com/blog/what-happens-when-you-push-aws-credentials-to-github
EC2 SSRF Leaked, Source: https://notsosecure.com/exploiting-ssrf-in-aws-elastic-beanstalk/

Programmatic Access sebagai contoh menggunakan AWSCLI,

aws configure --profile whateveruwant

Selain menggunakan aws configure, bisa juga dengan memembuat environment variable AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN (apabila temporary credential).

aws sts get-caller-identity adalah semacam command “whoami”.

Password Access bisa dengan login via https://signin.aws.amazon.com/

Terdapat dua pilihan login disini yaitu Root User dan IAM user, apabila login menggunakan IAM user dibutuhkan ACCOUNT ID, lalu setelahnya tinggal mengisi IAM user dan password-nya.

Root user adalah user yang digunakan untuk mendaftar AWS dari awal.

Enumeration

Enumerasi adalah step yang paling penting setelah initial access, karena dari sini kita bisa memetakan aksi yang bisa dilakukan seperti apakah kita melihat daftar bucket, melihat daftar EC2 Instance, melihat daftar user, melihat daftar permission, melihat daftar roles, dsb.

ada dua tools yang sangat terkenal menurut saya untuk melakukan enumerasi IAM yaitu enumerate-iam dan pacu

running enumrate-iam

Atau pacu

Hal yang sangat penting untuk diketahui adalah, proses enumerasi yang dilakukan kedua tools tersebut hanya meng-enumerasi permission yang sifat nya READ-ONLY, sedangkan permission yang sifatnya WRITE tidak dilakukan enumerasi. Sehingga ada kasus dimana saat menjalankan tools tersebut ternytata tidak ada permission READ yang bisa digunakan, tapi sebenanrya bisa saja memang Credential yang kita dapatkan itu memang tidak memiliki permission untuk READ, tapi memiliki permission untuk WRITE sehingga harus dicoba juga secara manual untuk permission-permission yang tidak di-handle oleh tools tersebut.

Contoh kasus nyata yang pernah saya temukan adalah waktu itu saat saya melakukan enumerasi permission READ di service S3 ternyata tidak bisa, semuanya “Access Danied” mulai dari list bucket, list objet, dan list bucket policy, tapi saat saya mencoba meng-upload file ke bucket tersebut ternyata sukses, so jangan lupa untuk melakukan manual enumerasi.

Cloudtrail Event vs Enumeration

Semua aktivitas yang berhubungan dengan API Call ke Service AWS akan dicatat di Cloudtrail Event History, jadi dengan menggunakan tools automate enum tersebut akan sangat “noisy” menyebabkan Blue Team akan mendeteksi adanya serangan.

Cloudtrail event history
Cloudtrail Event history

Enumerasi hal yang berkaitan dengan IAM sangat penting karena dengan mengetahui hal-hal dasar seperti detail dari policies, roles, users,dan groups akan mempermudah step selanjutnya seperti melakukan Privilege Escalation, dan Persistence.

Privilege Escalation

Privlege Escalation sangat bergantung pada permission yang kita punya saat ini, pada IAM serivce sendiri apabila kita mempunyai permission yang bisa melakukan perubahan (WRITE Access) entah itu attach, put, create, atau update akan sangat memudahkan kita untuk melakukan privilege escalation.

Sebagai contoh apabila access kita mempunyai permission iam:AttachUserPolicy, kita bisa menambahkan policy “AdministratorAccess” ke user yang digunakan.

Beberapa IAM Permission lain yang bisa digunakan untuk privilege escalation adalah AttachGroupPolicy, AttachRolePolicy, PutGroupPolicy, PutRolePolicy, PutUserPolicy, CreateAccesskey, CreateLoginProfile, atau selengkapnya bisa melihat pada Official IAM Permission list di AWS dan Intro: AWS Privilege Escalation Vulnerabilities.

Tapi dengan permission READ ada kemungkinan kita bisa melakukan Priviliege Escalation pada service-service yang berhubungan dengan penyimpanan data, misal DynamoDB, SecretsManager, SSM Parameter Store, dan S3, karena dari situ bisa saja terdapat data-data penting seperti Username-Password, Private Key SSH, API Key, dan sebagainya.

Persistence

Persistence Access di IAM bisa didapatkan dari action yang berkaitan dengan credential, semisal Create Access Key (iam:CreateAccessKey), Create Password (iam:CreateLoginProfile), atau bahkan memanfaatkan Role trust relationships.

Create Access key (required permission : iam:CreateAccessKey)

Hal penting yang perlu diketahui adalah 1 IAM user mempunyai batasan maksimal 2 Access Key, apabila membuat lebih dari 2 Access key akan mengeluarkan pesan error “Cannot exceed quota for AccessKeysPerUser: 2”

Tapi apabila mendapatkan masalah max 2 access key dan tidak memiliki permission delete access key, kita masih bisa membuat Access Key untuk IAM user lain, jadi proses enumerasi user sangat penting sehingga kita bisa membuat access key untuk IAM user tersebut.

Selain digunakan untuk persistence Create Access Key bisa juga digunakan untuk Privilege Escalation, karena semisal IAM user yang kita create access key-nya itu di-attach dengan policy seperti AdministratorAccess.

Trust relationships Backdooring (required permission : iam:UpdateAssumeRolePolicy)

Skenario melakukan backdoor “Trust relationships” adalah si attacker harus mempunyai akun AWS sendiri, dimana dengan melakukan “Trust relationships” si attacker bisa melakukan assume role dari IAM role akun AWS si korban. Sebenarnya cara ini dikenal dengan “Cross Account Access” dan sangat normal dan menjadi best-practices untuk pemberian akses ke orang lain, tapi dari sudut pandang Attacker hal ini bisa dimanfaatkan untuk melakukan backdooring terhadap IAM role dari akun AWS si korban.

Sebagai contoh, dari hasil enumerasi ditemukan ada IAM role admin access dan role “AdminAccessRole” ini akan di backdoor bagian Principal atau Trusted Identity-nya dengan akun milik si Attack.

Untuk melakukan backdooring ke Trusted Identity perlu dilakukan update terhadap AssumeRolePolicyDocument nya dimana field yang penting adalah “Principal”, Principal disini bisa di arahkan ke ARN dari IAM user akun si Attacker.

# backdooring-trust-policy.json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<ACCOUNT_ID>:user/<iam_user_name>"
},
"Action": "sts:AssumeRole"
}
]
}

Dari sisi Attacker untuk mendapatkan credential dari IAM role di akun AWS korban tinggal melakukan Assume Role.

Lalu dari crendetial yang didadapatkan tersebut bisa langsung digunakan.

Saat menggunakan metode ini, usahakan Principal nya mengarah ke ARN yang specifik, jangan menggunakan tanda “*” (Wildcard) karena apabila menggunakan Wildcard, backdoor kita bisa saja di manfaatkan oleh “pemain” lain.

Untuk automasi proses persistence, ada tool dengan nama “Endgame” menurut saya tool ini sangat powerfull untuk persistence di environment AWS, karena tool ini bisa melakukan berbagai macam teknik persistence di berbagai macam service yang disediakan AWS.

source : https://github.com/SpenGietz/endgame-1
Source : https://github.com/SpenGietz/endgame-1

Defense Evasion

Proses ini sangat penting sehingga dari sisi Attacker bisa menghindar agar tidak terdeteksi oleh Blue Team, sehingga ada beberapa hal yang harus diperhatikan.

Cloudtrail Insight

Usahakan untuk tidak memanggil API yang sifat nya Write terlalu sering dalam jangka waktu yang cepat, karena Cloudtrail insight akan mendeteksi aktivitas ini sebagai Suspicious.

Credential Use

Usahakan selalu menggunakan Credential yang didapatkan dari dalam EC2 Instance, baik itu dari EC2 Instance dimana credential itu dapatkan ataupun di EC2 instance yang kita setup sendiri, ini gunanya untuk menghindari proses pendeteksian API CALL AWS itu dipanggil dari resource mana.

User-agent

Usahakan menggunakan user-agent yang umum, ada beberapa kasus yang saya temukan dimana proses deteksi dan alert dikirim berdasarkan pattern dari user agent, “awscli” menggunakan python dan library boto sebagai SDK nya.

Attacker menggunakan Kali Linux

Apabila proses deteksi dan alert nya menggunakan regex apakah string “aws-cli” atau penggunaan awscli dari distro yang berhubungan dengan kegiatan hacking seperti “Kali Linux” alert-nya akan dikirim ke Blue Team.

Monitor disruption

Apabila kita mempunyai hak akses untuk meng-update atau menghapus resource yang berkaitan dengan Monitoring dan Detection seperti Guarduty dan Cloudtrail, maka hal ini bisa kita lakukan untuk mematikan proses Deteksinya, karena logika ini sama seperti saat kita mendapatkan akses Administrator di system operasi tertentu lalu mematikan fitur Anti-Virus.

Kesimpulan

IAM mempunyai 3 identity yaitu IAM User, Role, dan Group. Lalu IAM identity ini bisa diattacth dengan IAM Policies yang berguna untuk mengizinkan dan menolak aksi yang dilakulan oleh IAM identity terhadap resource AWS di akun tersebut. Untuk Attack Matrix dari IAM itu tergantung dari policies yang di-attach ke IAM identity tersebut, oleh karena itu semakin tinggi hak akses dari IAM identity yang didapatkan bisa menentukan hal apa saja yang bisa kita lakukan di environment AWS.

Referensi

https://hackingthe.cloud/aws/avoiding-detection/guardduty-pentest/
https://blog.knoldus.com/deep-dive-aws-temporary-security-credentials-assumerole-and-iam-role/
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html
https://docs.aws.amazon.com/iam/?id=docs_gateway
https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Cloud%20-%20AWS%20Pentest.md#aws---shadow-admin
https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html

--

--

Application & Cloud Security | Software Developer | CEH

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Muh. Fani Akbar

Muh. Fani Akbar

Application & Cloud Security | Software Developer | CEH