Didn't expect to see this here, it was over a month ago this incident happened! Happy to answer any questions about it (author of DataTables here). It was a super stressful event to say the least, and I've been reading along with the recent npm incidents wondering what I can do to make sure my OpSec is as good as it reasonably can be.
> The fact that someone would attack an open source product such as DataTables sickens me. I release by far the majority of my work as free open source software, host a free to use CDN, and support the software.
Seriously, no idea what could motivate this, unless a paid datatables vendor felt you were undercutting their business. We all like to think that attacks are beneath them, but stuff like that has happened before.
It’s still a complicated attack and I can understand the registrar being confused, though they should’ve called you for sure.
> They used an email address intentionally crafted to look like it could be mine and submitted a fake driver's license and utility bill with information that could only have been from leaked WHOIS data. The registrar accepted this as proof of identity and started the transfer process. That included sending an email to me to confirm the transfer, an email which I never saw due to the flood of emails (which it is now easy to say was the start of the attack).
Edit: Cloudflare blocking the attackers code with a 1000 error is interesting. Could you share some information about it?
This is perhaps a lesson that people should use the extra domain security functions, e.g. Domain Lock which is available on most (all ?) TLDs.
If your registrar does not expose the functionality, move to one that does.
N.B. Ideally you want Domain Lock == REGISTRY-LOCK, there is also REGISTRAR-LOCK which is similar in concept but not quite as secure because REGISTRAR-LOCK is implemented at Registrar not Registry level.
Out of curiosity, could this have been a vector for a supply chain attack?
I am currently running an fairly outdated version of datatables on a personal project, v1.11.3 from 2021. I'm not too worried about running this older version, because according to dependency scanning software there's no CVEs for it [1]. Also, upgrading this package is too tricky as there's been some pretty huge breaking changes, so I'm stuck at this older version.
I am _not_ using the datatables CDN but instead self-hosting the static files. However, I did not notice until recently that in v1.11.3 it comes with a CSS stylesheet [2] that loads a static resource from that CDN: `url("https://www.datatables.net/examples/resources/details_open.p...")`
It looks like newer versions of datatables don't import static files from the datatables CDN like this.
Presumably if this domain was hijacked as stated in this incident review, users on affect datatables version could have had their site compromised?
Would it make sense to issue a CVE for older datatables library versions that could be susceptible to this attack?
6 comments
[ 2.5 ms ] story [ 31.8 ms ] threadSeriously, no idea what could motivate this, unless a paid datatables vendor felt you were undercutting their business. We all like to think that attacks are beneath them, but stuff like that has happened before.
> They used an email address intentionally crafted to look like it could be mine and submitted a fake driver's license and utility bill with information that could only have been from leaked WHOIS data. The registrar accepted this as proof of identity and started the transfer process. That included sending an email to me to confirm the transfer, an email which I never saw due to the flood of emails (which it is now easy to say was the start of the attack).
Edit: Cloudflare blocking the attackers code with a 1000 error is interesting. Could you share some information about it?
If your registrar does not expose the functionality, move to one that does.
N.B. Ideally you want Domain Lock == REGISTRY-LOCK, there is also REGISTRAR-LOCK which is similar in concept but not quite as secure because REGISTRAR-LOCK is implemented at Registrar not Registry level.
I am currently running an fairly outdated version of datatables on a personal project, v1.11.3 from 2021. I'm not too worried about running this older version, because according to dependency scanning software there's no CVEs for it [1]. Also, upgrading this package is too tricky as there's been some pretty huge breaking changes, so I'm stuck at this older version.
I am _not_ using the datatables CDN but instead self-hosting the static files. However, I did not notice until recently that in v1.11.3 it comes with a CSS stylesheet [2] that loads a static resource from that CDN: `url("https://www.datatables.net/examples/resources/details_open.p...")`
It looks like newer versions of datatables don't import static files from the datatables CDN like this.
Presumably if this domain was hijacked as stated in this incident review, users on affect datatables version could have had their site compromised?
Would it make sense to issue a CVE for older datatables library versions that could be susceptible to this attack?
[1] https://security.snyk.io/package/npm/datatables.net/1.11.3
[2] https://cdn.datatables.net/1.11.3/css/jquery.dataTables.css