Critical vulnerabilities doesn't have to be complex or have a CVE -...
Nagli@galnagli
15 views
Jan 30, 2025
~4 min read
Advertisement
1
Critical vulnerabilities doesn't have to be complex or have a CVE - @deepseek_ai publicly exposed their internal ClickHouse database to the world, without any authentication at all, and leaked sensitive data.
No one is safe from security mistakes, follow along to learn more 🧵
No one is safe from security mistakes, follow along to learn more 🧵
2
@deepseek_ai @wiz_io When facing the task of discovering vulnerabilities on a specific company, the first step is to identify the externally facing attack surface, and later exploiting potential vulnerabilities - in this case, the 2 steps combined all together.
It all starts with DNS Discovery!
It all starts with DNS Discovery!
3
Taking our target root domain (for Bug Bounty / Responsible Disclosure) such as deepseek[.]com, we will want to feed it into DNS Discovery tools, those divide to 2 main workflows - Passive & Active.
In the passive sense, we want to query public DNS datasets all over the internet and collect known subdomains of our target, the best way to do that is using a tool such as subfinder by @pdiscoveryio
In the active sense, we will collect public wordlists with hundreds of thousands of domain names, and will try to fuzz and "guess" additional valid domains under our target - deepseek[.]com, such as "admin.deepseek[.].com" etc,etc...
For this task, a tool I recommend is Puredns github.com/d3mondev/pured…
Which is simply run by the following command:
Additionally, there are more techniques such as permutation (adding dev-admin.deepseek[.]com for example) but we will leave it like that.
The goal of this phase is to collect a list of valid subdomains, and save them all in a single place.
Valid subdomain in our sense - a DNS record that has an IP Address or points to another asset.
In the passive sense, we want to query public DNS datasets all over the internet and collect known subdomains of our target, the best way to do that is using a tool such as subfinder by @pdiscoveryio
In the active sense, we will collect public wordlists with hundreds of thousands of domain names, and will try to fuzz and "guess" additional valid domains under our target - deepseek[.]com, such as "admin.deepseek[.].com" etc,etc...
For this task, a tool I recommend is Puredns github.com/d3mondev/pured…
Which is simply run by the following command:
Additionally, there are more techniques such as permutation (adding dev-admin.deepseek[.]com for example) but we will leave it like that.
The goal of this phase is to collect a list of valid subdomains, and save them all in a single place.
Valid subdomain in our sense - a DNS record that has an IP Address or points to another asset.
4
Okay - so now we have a list of subdomains that are configured with some sort of DNS record and belong to our target.
We want to narrow down the scope now to everything that is externally facing, and actively expose some sort of service (could be HTTP server or Network component such as database)
To do that, we should use Port Scanning and HTTP Probing - basically checking for external exposures on the DNS names.
Myself and usually most of the community starts with HTTP Probing, taking our list of subdomains and feeding it to a tool such as httpx by @pdiscoveryio, will return a list of DNS names that are publicly facing and serving a web server on ports 80 + 443
However - important to note, not all public exposures are being served either with HTTP or even on the default ports, as there are thousands of self-hosted applications development teams are utilizing, and while every company has their own unique nature of development, that's why it is super important to basically scan for all open ports (1-65,535) and check whether they expose any additional services.
Such was the case in this exposure that affected @deepseek_ai, and for that task I usually use tools like Masscan or Naabu, collect a list of open ports and feed them again to HTTPX to identify open web servers.
We want to narrow down the scope now to everything that is externally facing, and actively expose some sort of service (could be HTTP server or Network component such as database)
To do that, we should use Port Scanning and HTTP Probing - basically checking for external exposures on the DNS names.
Myself and usually most of the community starts with HTTP Probing, taking our list of subdomains and feeding it to a tool such as httpx by @pdiscoveryio, will return a list of DNS names that are publicly facing and serving a web server on ports 80 + 443
However - important to note, not all public exposures are being served either with HTTP or even on the default ports, as there are thousands of self-hosted applications development teams are utilizing, and while every company has their own unique nature of development, that's why it is super important to basically scan for all open ports (1-65,535) and check whether they expose any additional services.
Such was the case in this exposure that affected @deepseek_ai, and for that task I usually use tools like Masscan or Naabu, collect a list of open ports and feed them again to HTTPX to identify open web servers.
5
Looking at the results so far, I had a list of publicly facing HTTP servers that belong to DeepSeek - most of them were completely legitimate such as their Chatbot, API Docs or status web server.
Two assets caught my attention, oauth2callback.deepseek.com & dev.deepseek.com
It's pretty rare to see these ports serving any intended HTTP web servers to the public, but more commonly those are used for development procedures.
Two assets caught my attention, oauth2callback.deepseek.com & dev.deepseek.com
It's pretty rare to see these ports serving any intended HTTP web servers to the public, but more commonly those are used for development procedures.
6
In the meantime, while I started looking on all the assets we already discovered, I had another tool running in the background - @pdnuclei, what that tool does is simply checking whether there are any immediate HTTP & Network based misconfigurations on the servers we discovered.
Those range from Default Credentials, Unauthenticated access to portals, CVEs & more - every thing is being validated in such manner that there are rarely any false positives, and the scans are not intrusive and couldn't damage any legitimate operations of our targets.
Navigating to the hosts, the response disclosed right away that the assets are running ClickHouse, which is usually an internally facing DBMS used to store large analytics & big query data, I ran Nuclei on the asset to check whether it is unauthenticated or misconfigured - which prompted for me out the result that the assets are indeed publicly open to the wide internet.
Those range from Default Credentials, Unauthenticated access to portals, CVEs & more - every thing is being validated in such manner that there are rarely any false positives, and the scans are not intrusive and couldn't damage any legitimate operations of our targets.
Navigating to the hosts, the response disclosed right away that the assets are running ClickHouse, which is usually an internally facing DBMS used to store large analytics & big query data, I ran Nuclei on the asset to check whether it is unauthenticated or misconfigured - which prompted for me out the result that the assets are indeed publicly open to the wide internet.
7
From this point - validating the exposure was pretty straight forward, looking at ClickHouse API - we were able to access the HTTP API which allows straight forward querying the MySQL database
There was a significant exposure of data, especially from the log_stream table, over 1M lines of logs that also included Chat history, DeepSeek API Keys, Infrastructure & Operational information and much more.
There was a significant exposure of data, especially from the log_stream table, over 1M lines of logs that also included Chat history, DeepSeek API Keys, Infrastructure & Operational information and much more.
8
Generalizing the process:
1. Discovering Subdomains
2. Probing for externally exposed services
3. Identifying anomalies and potential internal development services
4. Exploitation Validation (in a safe, none destructive manner)
5. Responsible Disclosure
This is what happened here - and is applicable for every company around the world, doesn't matter if its a new AI startup or a 50 years old bank, everyone are making the same mistakes!
1. Discovering Subdomains
2. Probing for externally exposed services
3. Identifying anomalies and potential internal development services
4. Exploitation Validation (in a safe, none destructive manner)
5. Responsible Disclosure
This is what happened here - and is applicable for every company around the world, doesn't matter if its a new AI startup or a 50 years old bank, everyone are making the same mistakes!
9
@deepseek_ai @wiz_io @pdnuclei I invite everyone to read our blog at @wiz_io of this specific exposure wiz.io/blog/wiz-resea… and welcome you all to ask questions, I hope that sooner rather than later companies will eliminate their unnecessary external risks proactively : ) 🙏
10
@deepseek_ai @wiz_io @pdnuclei @deepseek_ai response
