The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers). An example of a network attack is an attacker causing a denial of service by sending a specially crafted TCP packet across a wide area network (e.g., CVE-2004-0230).
Attack Complexity
High
AC
The successful attack depends on the evasion or circumvention of security-enhancing techniques in place that would otherwise hinder the attack. These include: Evasion of exploit mitigation techniques. The attacker must have additional methods available to bypass security measures in place. For example, circumvention of address space randomization (ASLR) or data execution prevention must be performed for the attack to be successful. Obtaining target-specific secrets. The attacker must gather some target-specific secret before the attack can be successful. A secret is any piece of information that cannot be obtained through any amount of reconnaissance. To obtain the secret the attacker must perform additional attacks or break otherwise secure measures (e.g. knowledge of a secret key may be needed to break a crypto channel). This operation must be performed for each attacked target.
Privileges Required
None
PR
The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
User Interaction
None
UI
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Below is a copy: Blizzard Update Agent JSON RPC DNS Rebinding
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 information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum