Bubble vulnerability X thread

Bugs
1

Hi all,

An alleged “0day Bubble exploit” just got “exposed” on X. The post states that allegedly Bubble knew about this but chose to ignore this exploit.

Looking into it I am not sure what the impact would be but I wanted to share it here so we can discuss and hopefully get more information from @fede.bubble. My biggest question is, does this impact apps with privacy rules? As I assume privacy rules are set on the database level and not on the client right so this seems to only affect apps without privacy rules? If so, I don’t really think this is a big deal as apps should have privacy rules and Bubble should come out with a statement to do a bit of damage control. But would love to know more!

Summary

In essence, this exploit allows the execution of arbitrary requests to the applications Elastic search which allows data dumping and/or exfiltration.

The applications encryption workflow is performed in the front-end, because Bubble-dot-io uses fixed IV’s (shared between ALL clients), exploiting Bubble-dot-io is possible due to the creation of arbitrary payloads by abusing the recovery keys.

All tables can be dumped, including custom tables defined as “custom.(table_name)”.

Furthermore, it’s possible to attack other clients from Bubble-dot-io because the application does all hosting internally (shared).

  • Cryptography keys do not rotate, hence an attacker can reuse the same keys in new Elastic searches
  • Timestamps are not verified
  • Attackers can enumerate customer subdomains by fuzzing *.bubbleapps-dot-io domain, making identification of targets easier
  • If domain doesn’t match target, response header will return correct target in ‘X-BUBBLEAPP-NAME’

Bubble’s reaction

Upon discovering the vulnerability, these 2 researchers notified Bubble. Unfortunately, for whatever reason, this fell on deaf ears.

Vulnerability Discovery

Through reverse engineering the platform’s JavaScript code and analyzing the HTTP headers, we discovered a vulnerability that could potentially allow an attacker to execute arbitrary queries against the Elasticsearch instance powering Bubble.io applications.

Technologies Involved:

  • Elasticsearch: Used by Bubble.io to perform database searches.
  • AES-CBC + PBKDF2_HMAC: Encryption methods used to protect requests to Elasticsearch.

Read more on Github:

More info:

2

This is not a 0 day. It’s the expected behaviour as outlined in the docs.

You should be using privacy rules to restrict database queries.

It’s a shame that something like this goes viral when it’s flat out untrue, and that’s all users will hear of Bubble.

3 Likes
3

@georgecollier Yeah it is definitely a bad look. Bubble should come out with a statement saying exactly that. The timing is also quite interesting as it might be that a big part of the Bubble team is OOO for Easter. I don’t really think that is a coincidence

1 Like
4

No doubt, it’s a bad look. But the ‘zero day’ they’re reporting is actually that lots of apps don’t have privacy rules configured. Which is true - but not a zero day, and not Bubble’s fault - that’s user error.

1 Like
5

I said this would happen for a different (actual) vulnerability (technically a bug) but funny that instead this fake vulnerability comes out. To be honest, it seems like the solution is to stop obfuscating the requests entirely. Does it do anything other than add a slight overhead to searches?

6

already replied in another thread talking about this but just in case: this is all documented and not a “zero day exploit”. The team will post a more official response later today

1 Like
7

This topic was automatically closed after 14 days. New replies are no longer allowed.