31–38 of 38 posts
Need an edit here > As it described on Clickhouse documentation, their API is designed to be READ ONLY on any operation for HTTP GET As described in the Clickhouse documentation, their API is designed to be READ ONLY on any operation for HTTP GET requests.
Out of interest, how much does ZDI pay for a bug like this?
They probably don't accept something like this. Not that many Posthog self-hosted instances out there...
Earlier quoted context omitted.
ssrf was the entry point, and clickhouse is supposed to be an internal only service, but one could reach it only with that ssrf, so hence less of "scrutiny". The 0day by itself wouldnt be useful, unless an attacker can reach clickhouse, which they usually can't.
But if they do, prohibiting SQL injection, a critical last mile vulnerability, seems trivial?
There as a actually a vulnerability Clickhouse, which helps you to execute any query on the remote postgresl. By default, you can't execute any random query! This bug was seperately reported to the Clickhouse and has been fixed seperately https://github.com/ClickHouse/ClickHouse/pull/74144/commits/...
Very nice write up!
Earlier quoted context omitted.
But if they do, prohibiting SQL injection, a critical last mile vulnerability, seems trivial?
The author already had basically full Clickhouse querying abilities, and Clickhouse lets you run arbitrary SQL on postgres, the fact that the author used a read-only command to execute it wasn't the author bypassing a security boundary (anyone with access to the Clickhouse DB also had access to the Postgres DB), it was just a gadget that made the SSRF more convenient. They could have escalated it into a different int…
Need an edit here > As it described on Clickhouse documentation, their API is designed to be READ ONLY on any operation for HTTP GET As described in the Clickhouse documentation, their API is designed to be READ ONLY on any operation for HTTP GET requests.
hi, this is the author of the article. Thanks for the feedback mate. fixed it.
Earlier quoted context omitted.
It looks like the entire class of bugs here are "if you have access to Posthog's admin dashboard, you can configure webhook URLs that hit Posthog's internal services". That's not particularly surprising for a self-hosted system like the author's, but I expect it would pretty bad if you were using their cloud-hosted product.
Ah of couse! I forgot about the cloud hosted option.
Earlier quoted context omitted.
The author already had basically full Clickhouse querying abilities, and Clickhouse lets you run arbitrary SQL on postgres, the fact that the author used a read-only command to execute it wasn't the author bypassing a security boundary (anyone with access to the Clickhouse DB also had access to the Postgres DB), it was just a gadget that made the SSRF more convenient. They could have escalated it into a different int…
That being said, having the ability to send HTTP requests to the internal servers is usually not critical vulnerability. Therefore having Clickhouse low-severity escaping vulnerability actually lead the whole chain to reach code execution. All the other services were requiring me to send special headers, which is not possible most of the SSRF cases :(