A Russian ransomware gang CLOp has reportedly been exploiting a zero day vulnerability in a secure file transfer software called MOVEit and has reportedly affected hundreds of businesses in UK and USA.
Moveit is a managed file transfer software product produced by Ipswitch,inc which encrypts files and uses FTP or SFTP protocols to transfer data. According to wikipedia, a stable release of the software is dated 2019. The program is used by many organizations including PWC, E& Y, BBC, Shell, British Airways, Boots, Zellis and several government agencies such as U.S. Department of Energy, the Louisiana Office of Motor Vehicles, the Oregon Department of Transportation, the Minnesota Department of Education, the Novia Scotia government etc.
It is surprising that the vulnerability remained undetected and unpatched showing the lack of security oversight in the software product industry worldwide. Though thousands of high profile companies used the software, it is surprising that no audit had brought out the security vulnerability.
The attack has rightly renewed the call for holding the software developers legally responsible for lack of “Reasonable Security”. Under the Indian law, if the software supplier contract is a “Service Contract”, the software company may be liable as an “Intermediary”.
If it is an outright sale, then the software developer may claim transfer of responsibility on the basis of “As is Where Is” sale contract. However reasonable disclosure of the product vulnerabilities or alternatively an access to code audit is essential for the software supplier to escape full liability as an “Intermediary” under ITA 2000.
Naavi has always advocated such a liability and as a measure of better security and it appears that Whitehouse’s National CyberSecurity Strategy has also called for similar measures.
Speaking on behalf of the software developers, Naavi has advocated that apart from the reasonable efforts at testing before a “Stable Release”, every developer should mandatorily run a “Bug Bounty Program” and try to continue the testing in the public space with a reward program implemented fairly. This is a compliance measure included in the now increasingly appreciated PDPCSI (Personal Data Protection Compliance Standard of India), a framework of compliance designed by Naavi and implemented by FDPPI in its certification audits.
We may also highlight that this software MOVEit may be classified as an “Automated Personal Data Processing Software” and hence use of the software was subject to regulations like GDPR. Compliance in such context required a DPIA by the user organization and a requirement of an assurance certificate from the licensing organization.
It is now the turn of GDPR supervisory authorities to question the users of MOVEit and demand payment of penalties for not conducting DPIA when they started using the software.
According to securityweek.com the company has now started releasing security patches which will apply necessary changes to Moveit transfer and Moveit Automation, the two products affected by the vulnerability.
One of the vulnerability patched is a SQL injection vulnerability that allows an unauthenticated attacker to gain unauthorized access to the MOVEit Transfer database. Using this vulnerability, an attacker could submit a crafted payload to a MOVEit Transfer application endpoint which could result in modification and disclosure of MOVEit database content.
The patches also covered multiple high-severity Progress MOVEit Transfer vulnerabilities that allowed authenticated attackers to gain unauthorized access to the MOVEit Transfer database. where by an attacker could submit a crafted payload to a MOVEit Transfer application endpoint which could result in modification and disclosure of MOVEit database content.
Security investigators in KROLL have reported details of the codes exploited by the hackers and indicate that over the course of approximately 14 minutes, threat actors were observed exploiting a MOVEIt web server, dropping a web shell, establishing connections to the web shell, and initiating automated data enumeration and exfiltration preparatory steps. They also noted that there were no active user sessions created in the table, no log entries and no unusual activity appearing within the MOVEit logs. At the end of the 14 minutes, a new threat actor IP address established a web shell connection and what followed for the next several hours were several thousand GET and POST requests which, when overlayed with the available firewall logging, indicated several large volumes of data being transferred to the new IP address.
Kroll observes that because of the exfiltration method used, it can be missed during initial forensic investigation. However the organizations need to carefully observe the GET and POST requests executed and if any uptick is observed, additional measures triggered to confirm the malicious activity.
The lessons that Privacy professionals should take from the incident are
a) Document an assurance from all software suppliers that they have undertaken reasonable measures of testing and the installed version is free from zero day vulnerabilities.
b) Conduct and document a DPIA when new software products/services are used
c) Initiate a “Exfiltration Watch” which observes any accelerated activity and raise alarms as a part of the Data Leak Prevention strategies.
Software developers need to revise their testing process to stand the test to be called “Reasonably rigorous” and support by continued bug bounty program”.
Buyers of software need to review the contracts to see if they have a Code review option or an indemnity against zero day vulnerabilities or at least an insurance back up.
Naavi
Comments welcome
Also Refer:
Bug Bounty Policy as part of Corporate Governance Responsibilities
