|
|
blizzard: agent rpc auth mechanism vulnerable to dns rebinding |
|||
Issue descriptionUpdate: Blizzard have informed me that the fix hadn't been closed yet and a more comprehensive solution is currently being prepared for deployment. All blizzard games are installed alongside a shared tool called "Blizzard Update Agent", investor.activision.com claims they have "500 million monthly active users", who presumably all have this utility installed. The agent utility creates an JSON RPC server listening on localhost port 1120, and accepts commands to install, uninstall, change settings, update and other maintenance related options. Blizzard use a custom authentication scheme to verify the rpc's are from a legitimate source, it looks like this: $ curl -si http://localhost:1120/agent HTTP/1.0 200 OK Content-Length: 359 { "pid" : 3140.000000, "user_id" : "S-1-5-21-1613814707-140385463-2225822625-1000", "user_name" : "S-1-5-21-1613814707-140385463-2225822625-1000", "state" : 1004.000000, "version" : "2.13.4.5955", "region" : "us", "type" : "retail", "opt_in_feedback" : true, "session" : "15409717072196133548", "authorization" : "11A87920224BD1FB22AF5F868CA0E789" } This endpoint is permitted without authentication, but all other requests must have a valid "Authorization" header with the token in that response. As with all HTTP RPC schemes like this, a website can send requests to the daemon with XMLHttpRequest(), but I think the theory is they will be ignored because requests must prove they can read and write the authorization property. I don't think this design will work because of an attack called "dns rebinding". Any website can simply create a dns name that they are authorized to communicate with, and then make it resolve to localhost. To be clear, this means that *any* website can send privileged commands to the agent. I have a domain I use for testing called rbndr.us, you can use this page to generate hostnames: https://lock.cmpxchg8b.com/rebinder.html Here I want to alternate between 127.0.0.1 and 199.241.29.227, so I use 7f000001.c7f11de3.rbndr.us: $ host 7f000001.c7f11de3.rbndr.us 7f000001.c7f11de3.rbndr.us has address 127.0.0.1 $ host 7f000001.c7f11de3.rbndr.us 7f000001.c7f11de3.rbndr.us has address 199.241.29.227 $ host 7f000001.c7f11de3.rbndr.us 7f000001.c7f11de3.rbndr.us has address 127.0.0.1 Here you can see the resolution alternates between the two addresses I want (note that depending on caching it might take a while to switch, the TTL is set to minimum but some servers round up). I just wait for the cached response to expire, and then POST commands to the server. Exploitation would involve using network drives, or setting destination to "Downloads" and making the browser install dlls, datafiles, etc. I made a very simple demo, I'm sure it's quite brittle, but hopefully you get the idea! http://lock.cmpxchg8b.com/yah4od7N.html See screenshot attached of how it's supposed to look. This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available, the bug report will become visible to the public.
,
Dec 9 2017
,
Jan 22 2018
Blizzard were replying to emails, but stopped communicating on December 22nd. Blizzard are no longer replying to any enquiries, and it looks like in version 5996 the Agent now has been silently patched with a bizarre solution. Their solution appears to be to query the client command line, get the 32-bit FNV-1a string hash of the exename and then check if it's in a blacklist. I proposed they whitelist Hostnames, but apparently that solution was too elegant and simple. I'm not pleased that Blizzard pushed this patch without notifying me, or consulted me on this. Here is the blacklist of exenames: .rdata:00719750 69 65 78 70 6C+aIexploreExe db 'iexplore.exe',0 ; DATA XREF: sub_420CBC+D4↑o .rdata:0071975D 00 00 00 align 10h .rdata:00719760 63 68 72 6F 6D+aChromeExe db 'chrome.exe',0 ; DATA XREF: sub_420CBC+F5↑o .rdata:0071976B 00 align 4 .rdata:0071976C 66 69 72 65 66+aFirefoxExe db 'firefox.exe',0 ; DATA XREF: sub_420CBC+10D↑o .rdata:00719778 70 6C 75 67 69+aPluginContaine db 'plugin-container.exe',0 .rdata:00719778 6E 2D 63 6F 6E+ ; DATA XREF: sub_420CBC+125↑o .rdata:0071978D 00 00 00 align 10h .rdata:00719790 6F 70 65 72 61+aOperaExe db 'opera.exe',0 ; DATA XREF: sub_420CBC+13D↑o .rdata:0071979A 00 00 align 4 .rdata:0071979C 73 61 66 61 72+aSafariExe db 'safari.exe',0 ; DATA XREF: sub_420CBC+155↑o See screenshot attached of the verification routine. The obvious flaw in this scheme is that the blacklist needs to be complete and maintained, so I expect it will break in future or for users on unusual browsers.
,
Jan 22 2018
Congrats, Tavis! A bit shame that Blizzard do not take this more in a professional way, giving the timeline of everything and alerting the involved. tbh, the way they fixed, seems kind of lazy stuff.
,
Jan 23 2018
,
Jan 23 2018
Blizzard here. We have a more robust Host header whitelist fix in QA now and will deploy soon. The executable blacklisting code is actually old and wasn’t intended to be a resolution to this issue. We're in touch with Tavis to avoid miscommunication in the future.
,
Jan 25 2018
A new version of the Blizzard Update Agent, 2.13.8, has been released with a Host header whitelist to resolve this issue. It will automatically self-update, so no action is needed by end users. |
||||
►
Sign in to add a comment |
||||
Comment 1 by taviso@google.com
, Dec 8 2017