C@PTCHA service providers validate millions of C@PTCHAs each day and protect thousands of websites against the bots. A secure C@PTCHA generation and validation ecosystem forms the basis of the mutual trust model between the C@PTCHA provider and the consumer. A variety of damage can occur if any component of this ecosystem is compromised.
During Analysis of the C@PTCHA integration libraries provided by several C@PTCHA providers (including reC@PTCHA) revealed that almost all of the C@PTCHA verification API’s relied on plain text HTTP protocol to perform C@PTCHA validation. Because of this, the C@PTCHA provider’s identity was not validated, message authentication checks were not performed and the entire C@PTCHA validation was performed on an unencrypted channel. This vulnerability was also reported to reC@PTCHA team several months back.
If you decompile the .NET Plugin, you'll be able to pull out reC@PTCHA's verification URL, which demonstrates the absense of HTTPS:
In the current scenario, two types of attacks can be launched against vulnerable C@PTCHA implementations. These attacks are based on the assumption that an attacker is able to intercept the C@PTCHA validation traffic between target website and the C@PTCHA provider.
Private Key Compromise
Most of C@PTCHA providers issue private and public keys to identify a particular consumer and to enforce an upper limit on the number of C@PTCHAs used by them. Private keys are often sent over to the C@PTCHA provider during the C@PTCHA validation process. If the public and private keys are sent using plain text HTTP, an attacker could sniff the private keys and:- Use the C@PTCHA service for without registering for the service by using the captured keys.
- Exhaust the target web site’s C@PTCHA quota for the service, which depending on the C@PTCHA provider may cause a wide variety of unexpected issues.
The C@PTCHA Clipping Attack
The following image describes what I call the "C@PTCHA Clipping Attack". Notice that steps 5 and 6 in blue would be the normal operation of events. We'll go into the attack in a little more detail below.
Since the website’s application server acts as a client to C@PTCHA provider during steps 5 and 6 (in blue) and the application server often neglects to validate the C@PTCHA provider’s identity and the session integrity checks, an attacker may be able to impersonate the C@PTCHA provider and undermine the anti-automation protection (steps 5 and 6 in red). C@PTCHA validation responses are mostly Boolean (true or false, success or failure, pass or fail, 0 or 1). The response format and its contents are also publicly available as part of C@PTCHA provider’s API documentation. This allows an attacker to easily construct the finite set of possible responses, impersonate the C@PTCHA provider, and perform malicious C@PTCHA validation for the application servers.
To exploit this vulnerability an attacker performs the following:
- The attacker acts as a legitimate application user and submits a large number of requests to the web application.
- At the same time, he/she intercepts C@PTCHA validation requests, masquerades as the C@PTCHA provider and approves all submitted requests.
Masquerading as the C@PTCHA provider and not forwarding the C@PTCHA validation requests to the actual C@PTCHA provider is the C@PTCHA Clipping Attack.
clipc@ptcha
clipcaptcha is a proof of concept exploitation tool that specifically targets the vulnerabilities discussed above and allows complete bypass of C@PTCHA provider protection. clipcaptcha is built on the sslstrip codebase and has the following features:- Performs signature based C@PTCHA provider detection and clipping.
- Can be easily extended to masquerade as any C@PTCHA provider by adding corresponding signatures to the configuration XML file.
- Has built in signatures of several C@PTCHA providers including reC@PTCHA, OpenC@PTCHA, C@ptchator etc…
- Logs POST requests that match any supported C@PTCHA provider to capture private and public keys. Unmatched requests are forwarded as is.
- clipcaptcha supports five operational modes. These are “monitor”, “stealth”, “avalanche”, “denial of service” and “random”.
