A not so Clearview?

Unless you were asleep last week, you probably saw the press story about the controversial facial recognition vendor, Clearview AI, being breached.

There is debate about whether Clearview should be permitted to scrape photos from social media and use them to populate its facial recognition system, as used by law enforcement agencies.

The New York Times ran a piece here.

This piqued our interest, so we had a quick look at the API endpoint published in the mobile app.

Now, we didn’t have an account nor did we have permission to test the app, so we were VERY limited in what we could do.

BUT

The API endpoint is at https://app.clearview.ai/app/

Notice anything odd about this request?

Yep, it’s missing an authentication header. An API missing an authentication header is usually an open API. If it was missing authentication, then it may be possible for anyone to run queries and access image data. That’s a big if though.

Now, it is perfectly possible that authentication is being carried out somewhere else in the system, but it seems very odd not to authenticate requests to this API directly.

Disclosure

We didn’t have any contacts at Clearview, but we did know a journalist with a history of supporting responsible disclosure who had been interacting with them around the breach story.

We asked if they could contact Clearview on our behalf, with the proviso that they followed our responsible disclosure process, which they agreed to do.

A response came back from the Clearview CEO, stating that all requests were correctly authorised, but gave nothing to support this.

Then things got a little weird. After pushing for a response, asking for detail of authentication as it wasn’t apparent in the API, the journalist received a Cease & Desist letter.

Wow! What an odd way to respond. Surely the answer would be to simply show that authentication was done elsewhere? We would have been fine with that and gone away quietly.

…But now I’m thinking that we were on to something.

Anyway, the API suddenly went down. 500 errors a-plenty.

And then the API changed, returning a nice error message simply from browsing to its web page, notifying us that we were not logged in:

Was this just tidying up error handling, or had authentication just been implemented?

Remember, we couldn’t test the API as we didn’t have permission. We weren’t in a position to prove or disprove its security.

@brxxnh1 also looked at the API and published some interesting findings: https://twitter.com/brxxnh1/status/1234628044742152193

Conclusion

We noticed something that didn’t prove a vulnerability, but suggested there might be some security issues.

We reported it to the vendor via a journalist.

The vendor threatened the journalist.

The API went down for a while and then changed.

Was it vulnerable? You decide.