Netlock incident from 19.02.2022

275 views
Skip to first unread message

Michel Le Bihan

unread,
Feb 28, 2022, 5:55:46 AM2/28/22
to dev-secur...@mozilla.org
Hello,
> In the early morning of 19. February 2022 (Saturday), Netlock Ltd. was the target of a cyber attack. We had been targeted by smaller attacks on the days prior. Upon noticing the attack, we immediately started the investigation of the events. The analysis of the underlying reasons and events is ongoing. Based on our internal findings, the attack was carried out with the involvement of multiple international locations. Netlock notified all the relevant authorities and filed a report with the police against an unknown suspect.
> We informed our customers in due course, and ensured their safety. Among the potentially involved personal data there were hashed individual passwords used on the onlinessl.netlock.hu website. Thus, we forced reset all passwords on onlinessl.netlock.hu. The onlinessl.netlock.hu webpage provides only limited administrative functions. At this point, our ongoing investigation suggests that the onlinessl certificates were not compromised.

However, I didn't see any related incident reported on Bugzilla nor here.

Ben Wilson

unread,
Feb 28, 2022, 12:00:23 PM2/28/22
to Michel Le Bihan, dev-secur...@mozilla.org
I reached out to Netlock when we were made aware of this attack. I don't believe that this constitutes an "incident" as defined in the Mozilla Root Store Policy, so I haven't requested that anything be filed. Here is Netlock's explanation:

In the early morning of the 19th of February 2022 (Saturday), Netlock Ltd. noticed that we were the target of cyber attacks. The attacks targeted the web frontend of our DVSSL service. Based on our internal findings, the hacker attacked our website (onlinessl.netlock.hu), but it didn’t have an effect on the issuance of SSL certificates. Our certificate issuing service which is on a separate network segment was thus unaffected. We double-checked the certificates issued in the previous weeks and found no irregularities in our signed audit logs. We informed our customers in due course, to ensure their safety, that among the potentially affected personal data there were password hashes for accessing the onlinessl.netlock.hu website. For this reason, we forced a reset for all passwords on onlinessl.netlock.hu. The onlinessl.netlock.hu webpage provides only limited administrative functions, mostly related to payment and invoicing.

Ben

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/beb04420-fd43-42fc-bba2-65e5bfb46163n%40mozilla.org.

Ryan Sleevi

unread,
Feb 28, 2022, 7:54:41 PM2/28/22
to Ben Wilson, Michel Le Bihan, dev-secur...@mozilla.org
While it may not be misissuance, I don’t know if this provides a significant level of reassurance.

For example, there have been repeated discussions in the CA/B Forum about allowing CAs to be permanently delegated to (e.g. via CNAME). This would make such an issue like this functionally equivalent to compromising validation for those domains, and so benefits from a greater degree of public postmortem and incident response.

Even ignoring this, it doesn’t address, for example, whether they allow accounts to reuse cached/past validations, which could have a similar impact today, without changes to the BRs.

Given the quality of Netlock’s past incident reports, it seems reasonable to be concerned, and to hope for a full and public transparent incident report that can build confidence that Netlock truly has considered the edge cases, to examine not only how the incident happened, but how it was detected and should have been prevented.

If you recall, DigiNotar was arguably exemplary in their network design, which was strongly separated and tightly controlled to limit data flow, and that incident still happened - and DigiNotar failed to adequately detect.
Reply all
Reply to author
Forward
0 new messages