Officescan server not updating
Analyzing the security of security software is one of my favorite research areas: it is always ironic to see software originally meant to protect your systems open a gaping door for the attackers.Earlier this year I stumbled upon the Office Scan security suite by Trend Micro, a probably lesser known host protection solution (AV) still used at some interesting networks.Remember: digital signatures only tells you about the creator of the message, not the intent of the creator :) All in all I could identify several weaknessess of Office Scan: the following video demonstrates the attack: This attack is realistic when the attacker is able to intercept client GUIDs from the network or wants to escalate her privileges locally.With another infoleak it might be possible to improve the attack to be CVSS 10.0.
I assumed that there must be some kind of connection between the server and the clients so the clients can obtain new updates and configuration parameters.I started to monitor the network connections of the clients and found some interesting interfaces, one of these looked like this: POST /officescan/cgi/isapi HTTP/1.1 User-Agent: 11111111111111111111111111111111 Accept: */* Host: 192.168.124.180 Content-Type: application/x-www-form-urlencoded Content-Length: 96 Proxy-Connection: Keep-Alive Cache-Control: no-cache Pragma: no-cache Connection: close Request ID=123&Function Type=0&UID=11111111-2222-3333-4444-555555555555&RELEASE=10.6&chk Database=1 The Request ID parameters were the same, but I quickly loaded the request to Burp Intruder and tried to brute-force other valid identifiers. 5231C05389DD886C99EA4646653498C2DB98EFD6EF61BD4907B2BD97E4ACDAED73AEE46B44AACBC450915317269 (...) which are (seemingly) encrypted, indicating that these params are something to protect.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.The only problematic part is the IP parameter that seems to contain a hash value. You can use scripts like Find Crypt to find the MD5 routine in the [jdk Notify] error=-1471291287,clinet=472bc675-3862-4e9d-9890-e3b14d4ddc3e,server=SEQ=80&DELAY=0&USEPROXY=0&PROXY=&PROXYPORT=0&PROXYLOGIN=&PROXYPWD=&SERVER=192.168.124.134&SERVERPORT=8080cc NT_Version=10.6&Pcc95_Version=10.6&Engine NT_Version=9.700.1001&Engine95_Version=&ptch Hotfix Date=20131228153813&PTNFILE=1050100&ROLLBACK=1050100&MESSAGE=20&TIME=201312281648170406&DIRECT_UPDATE=1, return -1293342568 (sic!) parameter, that is the GUID of the client generated at install time.