Digital disaster

A cyberattack by an unknown agent compromises the digital certificates issued by the NIC. As it is not clear how and who hacked the digital security infrastructure, the new government would do well to put on hold its push towards “Digital India”.

A screenshot of the NICCA's home page.

IT came to light on July 2 that the digital security infrastructure of the government was hacked into. The investigations by the National Informatics Centre (NIC) since then have not been able to make much headway and have yielded little information about the root cause of what was clearly a serious breach, according to a highly reliable source at the Department of Electronics and Information Technology (DeitY).

The cyberattack by an unknown agent on the system maintained by the NIC (see http://newsclick.in/india/government-digital-security-infrastructure-hacked) to issue digital certificates, which are meant to guarantee the security of transactions over the Internet, has compromised all the DCs the NIC has issued so far (see box). The NIC is one of the six intermediate Certifying Authorities (CAs) that have been licensed by the Controller of Certifying Authorities (CCA) of the DeitY. The NICCA has the mandate to issue DCs to government entities only and to date has issued about 2.5 lakh DCs to government web servers and individual websites. The other five subordinate CAs, which are authorised to issue DCs to private entities only, are Safescrypt of Sify Technologies Ltd, Chennai; the Institute for Development and Research in Banking Technology (IDRBT), Hyderabad; Tata Consultancy Services (TCS), Mumbai; (n)Code Solutions, a division of Gujarat Narmada Valley Fertilizers & Chemicals Ltd, Ahmedabad; and e-Mudhra, Bangalore. The IDRBT deals in DCs for the banking sector alone.

The infrastructure of the NICCA includes the main database and the main web server at its headquarters in New Delhi and a backup system (called the Disaster Recovery site) in Hyderabad. TCS has supplied the software for generating these DCs. Besides TCS, some other CAs such as the IDRBT also use the TCS software. TCS has an annual maintenance contract with the NIC for the government’s CA infrastructure in Hyderabad.

Interestingly, because of a fire in the NIC premises in New Delhi, the main infrastructure has been non-operational and the database non-accessible for about two months, according to the source. Therefore, the backup system in Hyderabad has effectively been operating as the main CA infrastructure, and this is the site that was compromised. This serious incident of fire was not made public for reasons best known to the NIC. And all indications suggest there was an attempt to hush up the hacking incident as well.

By gaining illegal access to the Hyderabad NICCA system and tampering with its software, the hacker was able to make the system issue fake DCs to private entities, such as certain domains maintained by Google and Yahoo. With these fake DCs, the intruder can create fraudulent, but apparently certified and digitally secure, phishing websites to which communications and transactions that are actually meant to be routed through genuine websites (say, Google or Yahoo domain) can be diverted and thereby gain access to ostensibly secure information and data.

Vulnerable to crimes

The incident has, therefore, rendered all the supposedly digitally secure web servers and websites of government entities vulnerable to various kinds of malicious acts and cybercrimes. An end-user government agency trying to access a particular land record, for example, can no longer be sure that it is authentic. Similarly, a recipient of data from a government agency cannot be certain that the data was not tampered with.

Surprisingly, there has been no official statement on the incident to date. “I know nothing. Please address all your queries to the CCA,” said Gulshan Rai, Director-General of the Indian Computer Emergency Response Team (ICERT) at the DeitY. All attempts to reach T.A. Khan, the CCA at the DeitY, and Rajeev Gauba, the new Director-General of the NIC, were in vain. A Press Trust of India story published on July 14 (https://www.thehindubusinessline.com/features/smartbuy/tech-news/looking-into-unauthorised-digital-certificates-issue-govt/article6209832.ece), however, quoted R.S. Sharma, the Secretary of the DeitY, as saying: “We are looking into this issue. [The] CA is taking appropriate steps and is working under the guidance of the CCA.”

In reality, however, both the CCA and the NICCA are clueless as to how the breach occurred. The hacker seems to have introduced a clever piece of code that bypassed the three levels of check modules, including the one that compares online applications with the hard copies submitted by a Registration Authority, which exist in the system chain for issuing the DCs. The code also enabled the hacker to add on an additional arbitrary application in the registry queue, and once a fake DC was generated, it ensured that no trace of the hacker’s identity was left behind.

According to the source, it could have been the handiwork of either an external agent or an insider, the latter case amounting to sabotage. If it was an external agent, it would mean that there are loophole(s) in the software that the hacker exploited. In case of suspect software, the other CAs who use the TCS software are similarly vulnerable. Indeed, to be on the safe side, the IDRBT-CA has already begun an audit of its DC-issuing system to see whether the TCS software has any bug that can render its infrastructure open to attack. If an insider was responsible, that would mean that the saboteur somehow accessed various secret passwords and IP (Internet Protocol) addresses to bypass the check modules.

The Information Technology Act, 2000, the source noted, requires the CCA to carry out a complete audit of the backup system before migrating to it to issue DCs, but this was not done. When contacted, Sundeep Oberoi, head of the Niche Technology Delivery Group, the TCS wing involved in digital certification, said: “If NICCA’s system has had a problem, ask the NIC. TCS has only provided the software.” Although Oberoi categorically denied that TCS also operated the system, it is learnt that under some informal arrangement between the two entities, TCS does operate it, and immediately after the CCA became aware of the incident, Oberoi was summoned for meetings at the DeitY that lasted over two days.

Google alert

The incident itself came to light on July 2 when Google informed the CCA that the NICCA had issued three fake DCs to Google domains, one on June 25 and two on June 30. Google had not applied for any. VeriSign, a United States-based certifying authority, normally issues Google’s DCs, so when a NICCA-issued DC showed up, Google got suspicious and informed the CCA. A similar fake DC was also apparently issued to a Yahoo domain on June 30 though Yahoo has not made any public statement in this regard. More recently, Google seems to have detected one more fake DC from the NICCA.

These fake DCs issued to Google and Yahoo can be, for example, used to gain unauthorised access to certain Google and Yahoo domains. If Google’s internal security system had not alerted the CCA and the NIC, the two agencies might never have even discovered the incident. It is surprising that the NIC does not have an appropriate monitoring and tracking system in place to detect such intrusions immediately; so much for India being an “IT superpower”.

Google has asked the two agencies to investigate the incident thoroughly, identify the root cause, and take appropriate action, and also make a public statement on the issue. On July 8, Google posted a public statement from its security engineer Adam Langley in its online security blog on the actions it had taken (http://googleonlinesecurity.blogspot.in/2014/07/maintaining-digital-certificate-security.html and https://code.google.com/p/chrom- ium/issues/detail?id=392251).

According to Google’s statement, only Windows users will be affected because the Indian CCA is listed only in Microsoft Root Store, which browsers such as Internet Explorer and Google Chrome use. “We promptly alerted [the] NIC, [the] India CCA and Microsoft about the incident, and we blocked the misissued certificates in Chrome with a CRLSet push,” the statement said. Google and other browsers maintain a Certificate Revocation List (CRL) to protect their services against cyberattacks by entities attempting to access them with fake DCs.

“Firefox,” Google’s statement noted, “is not affected because it uses its own root store that doesn’t include these certificates. We are not aware of any other root stores that include the India CCA certificates, thus Chrome on other operating systems, Chrome OS, Android, iOS and OS X are not affected.” Google Chrome and Internet Explorer have already derecognised websites the NICCA certified as can be easily checked. If, for example, one visits the NICCA (nicca.nic.in), or any other website it has certified, one will see the statement: “There is a problem with this website’s security certificate.”

Google stated that following the alert, on July 3 the CCA said that it had revoked all the “intermediate certificates” issued to the NIC, which basically are the licences that authorise the NIC to be an intermediate CA. Following this action by the CCA, since July 3 the NICCA website has been carrying the following statement: “Due to security reasons NICCA is not issuing certificates as of now. All operations have been stopped for some time and are not expected to resume soon. DSC [Digital Signature Certificate] application forms will not be accepted till operations are resumed and further instructions will be issued thereafter. Inconvenience caused is regretted.”

In a July 9 update, Google said: “[The] India CCA informed us of the results of their investigation on July 8. They reported that NIC’s issuance process was compromised and that only four certificates were misissued; the first on June 25.” While Google has blocked these fake certificates, this may not be enough. As Google itself correctly noted in the update, “We are also aware of misissued certificates not included in that set of four and can only conclude that the scope of breach is unknown ” (emphasis added throughout). Indeed, as Google’s recent discovery of another fake DC clearly indicates, the investigation by the NICCA/CCA is far from complete. Without a proper root-cause analysis, it will not be known when exactly the first instance of hacking occurred. And so it will not be clear how many fake DCs were issued to entities other than Google before June 25 and between June 25 and July 2.

Indeed, alerted by Google, Microsoft too issued a public security advisory on July 10 (No. 2982792 at https://technet.microsoft.com/library/security/2982792), which cautioned that as many as 45 domains belonging to Google and Yahoo services had been rendered vulnerable because of the fake certificates issued to Google and Yahoo. “These SSL [Secure Sockets Layer] certificates [that the NIC improperly issued] could be used to spoof content, perform phishing attacks, or perform man-in-the-middle attacks against web properties. The subordinate CAs may also have been used to issue certificates for other, currently unknown sites, which could be subject to similar attacks ,” the advisory said. Adding that the issue affected all supported releases of Microsoft Windows, the advisory said that Microsoft was not currently aware of attacks related to this issue.

“But a root CA [which is the CCA],” the Google update added, “is responsible for all certificates issued under its authority. In light of this, in a future Chrome release, we will limit the India CCA root certificate to the following domains and subdomains thereof in order to protect users: gov.in, nic.in, ac.in, rbi.org.in, bankofindia.co.in, ncode.in, tcs.co.in.” This essentially implies that secure transactions (say banking) through Google Chrome by web servers and individual websites entities certified by the CCA can now only be carried out between domains with .in extensions, which means between entities within the country. That is, one will not be able to, for example, book a train e-ticket through the Indian Railways website from abroad.

Such incidents of compromised CAs are rare but not new. The most recent one was in 2011 when Comodo, an American CA, and DigiNotar, a Dutch CA, issued fraudulent DCs. VeriSign too was guilty of issuing a couple of improper DCs in 2001.

The immediate action that the CCA is preparing to take is to revoke all the DCs the intermediary NICCA issued and issue fresh ones, which could take at least a couple of months. On July 15, the NICCA’s site carried the following statement: “Due to Security Reasons, NICCA has revoked all the SSL Server Certificates issued by NICCA/SubCA trust chain till now. Arrangements are made to replace these with the alternate valid SSL Certificates from an alternate source. Information regarding this has already been sent to users through email. Any SSL Certificate found in Web space which has NICCA/SubCA signature footprints but has not been legally issued by NICCA/SubCA or otherwise must be treated as invalid.”

Blame game

It should be noted that the NICCA has revoked only the DCs of servers, which, it is learnt, number about 500. Revoking the rest of the 2.5 lakh DCs, including those of individual websites, is bound to take time. According to the source, the alternate source mentioned above could be one of the other subordinate CAs. But, this does not address the root cause of the problem. For the NICCA’s DCs to be internationally recognised once again and for it to be included in the Certificate Trusted List of Google and Microsoft’s Root Store, a complete forensic audit of the incident has to be carried out, and that too by an international expert team. Failing which, the NICCA will continue to be labelled a “rogue CA”. DigiNotar continues to be an untrustworthy CA in Microsoft’s Root Store.

Unfortunately, however, the agencies involved, the NIC, the DeitY and TCS, do not seem to be making any coordinated effort to rectify the situation. There apparently is a blame game going on between the NIC and TCS relating to whose lapse led to the breach and whether the insider belonged to the NIC or TCS, if it was indeed sabotage. The NIC and the ICERT are carrying out investigations independently of each other when actually the NIC should be involving the ICERT in its root-cause analysis. In the beginning, in a bid perhaps to hush up the incident, the NIC apparently even tried to stonewall the ICERT’s attempts to access the system’s database, hardware and logbooks, the source said. When the NIC finally relented, it seems that the ICERT found that the logbooks had not been properly maintained though they may not really be necessary as the system itself would have maintained the entire “login” details. For its investigation, the ICERT has now been able to obtain “images” of all the recent operational history that it could access from the system.

At the higher echelons of the government, the National Security Adviser and the Cabinet Secretary are apparently already seized of the matter. A high-level committee has been constituted to investigate the incident. Meanwhile, the government has also ordered the ICERT to carry out a complete audit of the entire digital infrastructure—not just that of the CA—maintained by the NIC. The new government would do well to put on hold its push towards “Digital India” until its digital housekeeping and digital security are put in order.