Officescan server not updating
Now I would like to share a series of little issues which can be chained together to achieve remote code execution.
The issues are logic and/or cryptographic flaws, not standard memory corruption issues.
I put together a small Mit Mproxy script for this task: Still, my evil plan didn’t work, what could have gone wrong?
ID 201 seemed particularly interesting, here’s part of the server’s answer: HTTP/1.1 200 OK Date: Wed, GMT Server: Apache Content-Length: 2296 Connection: close Content-Type: application/octet-stream [INI_CRITICAL_SECTION] Master_Domain Name=192.168.124.134 Master_Domain Port=8080 Use Proxy=0 Proxy_IP= Proxy_Port= Proxy_Login= Proxy_Pwd= Intranet_Proxy_Socks=0 Intranet_No Proxy Cache=0 HTTP_Expired_Day=30 Service Pack_Version=0 Licensed_User Name= Uninstall_Pwd=! 5231C05389DD886C99EA4646653498C2DB98EFD6EF61BD4907B2BD97E4ACDAED73AEE46B44AACBC450915317269 Unload_Pwd=! Actually, the clients can be unloaded or uninstalled only after providing a special password (a SYSTEM level service is responsible for protecting the main processes of the application from killing or debugging), this is what we see encoded in these fields. The Office Scan program directory contains a file called : The naming is not coincidential: this subroutine references two strings wich definitely look like hardcoded passwords: After a quick Google search (Protip: always google strings like these, you can save yourself lots of time by not recreating public results) one can find this post by Luigi Auriemma, that descreibes that this function is used to decrypt the above configuration parameters and in this case return the MD5 hashes of the uninstall/unload passwords.If we set up some higher version numbers in the notification we can also trigger the update process of the software, and we can set our own host as a server or a proxy effectively gaining man-in-the-middle position.From this point the most obvious way to gain control over the client is to hijack the update process and let the client download and execute a malicious binary as part of the update.By hooking these functions one can basically get real-time information about the internal state of the processes.This helped a lot during the reversing process and also revealed the problem with my binary planting: As it turns out OSCE only accept signed binaries, that is a good approach to handle updates which are delivered over untrusted channels (handling TLS certificates in corporate environment can be tricky…).