This week, we have a lot of high-profile API vulnerabilities, like Instagram, Zipato, and 7-Eleven. Also, 42Crunch has released a native API firewall for microservices in Kubernetes.
Vulnerability: Instagram
Laxman Muthiyah got his $30K bug bounty for reporting this vulnerability to Instagram: He managed to use the Instagram API to take over an arbitrary account.
The vulnerability was in the API that Instagram exposes for password resets in its mobile app. You can make a POST call to request a 6-digit password reset code sent to the mobile number associated with the account. You then have 10 minutes to use the code to reset the account password before the code expires. Without the phone, attackers must “guess” the code. For this, there is another POST call that could be used to try the million possible code variations.
To prevent this kind of brute-forcing, Instagram had implemented rate-limiting so that only about 200 attempts can be made from a single IP address. However, Muthiyah overcame this limitation by renting out AWS EC2 instances for 10 minutes and running the calls from them. The rented instances all had different IP addresses, so Instagram’s rate limiting did not get triggered.
To prevent similar exploits, API providers should not limit throttling to just IP addresses. For example, too many frequent password reset attempts sent for a single account obviously is an attack and needs to be blocked as such.
Vulnerability: Zipato
Zipato smart hub is used in thousands of homes. Researchers found a combination of vulnerabilities that let them remotely lock and unlock doors managed by Zipato controllers.
The first vulnerability was in the shared SSH private keys used on the devices. The researchers located and extracted the keys from one of the controllers and verified that the same keys were used in all of Zipato devices. Using the SSH key, the researchers could then remotely connect to the smart hubs and get records of the users and the locks connected to the system.
At this point, the researchers found that the APIs for the locks had vulnerable authentication mechanism. In what is referred to as “pass-the-hash” vulnerability, the locks accepted password hash instead of the actual password to authenticate! With the hashes obtained from the smart hubs, researchers could now authenticate and make API calls to open or close the individual locks.
Advice to API providers: never ever use hard-coded, default, shared passwords or keys, and always adhere to authentication best practices.
Vulnerability: 7-Eleven Japan
Another API hack through the password reset API. This one the attackers successfully used in the wild, stealing about $510K from 900 customers.
7-Eleven Japan released a mobile payment app, 7pay, for their customers. The app had a vulnerable API for password reset. The API required providing some user profile information — such as the date of birth, phone number, and email address — before it would send the password reset link to the email address that the user supplied. Interestingly, the app allowed specifying a different email for this than the one that was used when registering the account.
The attackers used various databases containing the personal information of Japanese population and a script that called the API for each record to test the required user information. When the attackers requested password reset, they simply specified the reset link to be sent in their own email address.
According to 7-Eleven Japan, the attackers managed to take over about 900 user accounts and spend their money before the vulnerability was discovered. The timeline is very impressive, and everything happened very quickly. The vendor had to pull the application from the market after a mere 3 days of introducing it!
In this particular case, beyond the lack of proper rate limiting and monitoring, the issue was obviously in the design of the API design: allowing password reset code to be sent to an arbitrary email address is a clear design flaw.
Tools: 42Crunch API protection for microservices
The API security vendor, 42Crunch, has updated their API security platform to provide a native API firewall for microservices in Kubernetes.
Service meshes like Istio offer some network-level protection features for microservices. For example, you can specify that microservice A is only allowed to talk to microservice B.
42Crunch API Firewall complements this on the application (API) level. The firewall checks each and every API call and response to make sure that only transactions conforming to the API contract get through to the API. This functionality complements static and dynamic API checks that 42Crunch Platform offers to locate possible vulnerabilities.
See the demo video and details in the company’s announcement.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
