|
|
|
|
| |
Credit:
The information has been provided by Derek Callaway.
The original article can be found at: http://www.security-objectives.com/advisories/SECOBJADV-2008-03.txt
|
| |
The PartyGaming PartyPoker client program can be forced into downloading a malicious update. This is a result of the PartyPoker client not properly confirming the authenticity of the network update server or the executable update files themselves. When downloading an update, first the client program resolves the DNS address of the update host. Next, it establishes a TCP connection on port 80 of the previously resolved IP address. Then, it sends an HTTP request for an EXE file under the web server's Downloads directory. Upon receiving the HTTP response, the requested portable executable is written to disk and executed.
Analysis:
To successfully exploit this vulnerability an attacker must be able to somehow position themself such that they can impersonate the update server. This can be accomplished through DNS cache poisoning, ARP redirection, TCP hijacking, impersonation of a Wi-Fi Access Point, etc. The attacker also would have configured a rogue web server to push out update code of their choosing.
Before PartyPoker downloads the update it communicates with another PartyGaming server in the 88.81.154.0/24 subnetwork via SSL to determine if a new client update is available; if so, a HTTP GET request is sent to www1.partypoker.com for an EXE file in the /Downloads/en/vcc directory and is stored on the local filesystem under C:\Programs\PartyGaming\tmpUpgrade and executed. Afterwards, the user may login and operate the PartyPoker client as usual.
Since the update itself is downloaded from a seperate server, the client can contact the legitimate PartyGaming server during exploitation to determine if an update is available as normal. The attacker only needs to masquerade as www1.partypoker.com.
Workaround:
Do not use the PartyPoker client program.
Vendor response:
The vendor was contacted initially and fully aware of the vulnerability. However, after unsuccessfully attempting to reestablish dialogue multiple times with limited responsiveness over a period of several months, Security Objectives proceeded with the advisory.
CVE Information:
CVE-2008-3324
Disclosure Timeline:
20-Feb-2008 - Discovery of Vulnerability
22-Feb-2008 - Developed Proof-of-Concept
25-Feb-2008 - Reported to Vendor
15-Aug-2008 - Published Advisory
|
|
|
|
|
