Issue 96: Vulnerabilities at Cisco and MGM Grand Resort 🏖️, tutorial on Chrome DevTools and pentesting with GraphQL

Cisco has released a set of patches for their Data Center Network Manager (DCNM), a platform for managing Cisco data centers.

One of the critical vulnerabilities that Cisco fixed was, quoting from the Cisco Security Advisory:

“A vulnerability in the REST API of Cisco Data Center Network Manager (DCNM) could allow an unauthenticated, remote attacker to bypass authentication and execute arbitrary actions with administrative privileges on an affected device.

The vulnerability exists because different installations share a static encryption key. An attacker could exploit this vulnerability by using the static key to craft a valid session token. A successful exploit could allow the attacker to perform arbitrary actions through the REST API with administrative privileges.”

Embarrassingly enough, in the beginning of this year Cisco already patched one issue that involved static API key in DCNM. Now the same kind of problem reappears in the very same product. Let’s hope this does not become a recurring issue.

Do not use static or hard-coded API keys. This is a poor security practice, susceptible to key interception and re-use.

MGM Grand hotel and casino in Las Vegas reported a data breach earlier in the year. The breach leaked the personal information of 10.6 million guests that had stayed there over the years.

It was not clear in the beginning if only the Las Vegas resort was affected. However, now 142 million records from the parent company, MGM Resorts International, seem to have become available on the dark web, confirming that the scope of the leak is most likely not limited to a single resort. Although the leaked information is not highly sensitive, like credit card or social security information, it can still be used for further attacks.

It looks like the information ended up in the dark web happened because of a data leak at Data Viper, a security platform (ironically) used by MGM. Matt Keil, Director of Product Marketing at Cequence Security, sheds light on the API-side of this latter leak:

“Data Viper, a purported security company, lost its database as a result of poor API secure coding practices – the developer left their credentials exposed in an API usage document. The scope of the breach and the technique used, highlight two areas of weak security practices. The first weakness is the fact that many of the databases collected by Data Viper were the result of poor cloud-based implementations – they had little or no access control and authentication configured, or the API keys were left exposed  – so the data was freely accessible to anyone on the web. The second weakness is the developer error of leaving API credentials exposed, an all too common error made by many organizations that are moving (rapidly) to an API-based development methodology.”

One more reminder of how critical it is to keep API keys a top secret, closely monitor their use and potential leaks.

Chrome Developer Tools have long been popular among web developers. The video below has some tips on how to use the DevTools for penetration testing, including locating API paths on the Memory tab:

GraphQL APIs are still less adopted than REST APIs but often used in applications that are optimized for quick retrieval of large amounts of data. And just like REST APIs, GraphQL APIs can be vulnerable to attacks.

Check out this video by Farah Hawa to learn about the basics of GraphQL, data schema discovery with Introspection, and a couple attack examples: Broken object level authorization (IDOR/BOLA) and SQL injections.

We had a list of the most common GraphQL vulnerabilities in our issue 82.