Information Technology

T-Mobile has confirmed a data breach that was caused in part by SIM swapping attacks, according to a statement from the company.The T-Mo Report, a blog tracking T-Mobile, obtained internal reports showing that some data was leaked from a subset of customers. 

Some individuals had their customer proprietary network information (CPNI) leaked, which includes information about a customer’s plan, the number of lines, the phone numbers, the billing account, and more. Others had their SIMs swapped. Some were victims of both the CPNI leak and the SIM swaps.When pressed for comment by ZDNet, T-Mobile refused to go into detail about the attack and would not say how many customers were affected in the incident.”Our people and processes worked as designed to protect our customers from this type of attempted fraud that unfortunately occurs all too frequently in our industry,” a T-Mobile representative said in response to questions from ZDNet. The company told CNET and Bleeping Computer that it sent notices to “a small number of customers” who were dealing with SIM swapping attacks, calling the attacks “a common industry-wide occurrence.”

A T-Mobile representative tweeted to say the company “is taking immediate steps to help protect all individuals who may be at risk from this cyberattack.” The company experienced a massive data breach in August that exposed sensitive information from over 50 million current, former, and prospective customers. This included names, addresses, social security numbers, driver’s licenses, and ID information. T-Mobile users have long criticized the carrier for its lackluster support for SIM swapping victims. The company has repeatedly announced SIM swapping attacks and data breaches since 2018.  More

Newly-formed cryptocurrency platform Saitama announced Wednesday that its smart wallet, SaitaMask, has passed an audit. It received certification from blockchain cryptocurrency auditing firm CertiK, declaring that SaitaMask is “issue free and hacker resistant.”

Passing the audit will make it easier for the six-month-old crypto platform “to apply for, and be listed on, additional exchanges,” making its $SAITAMA tokens more accessible. Currently, there are about 300,000 token holders with a market cap of $4 billion, the company said in its press release. Saitama noted that its SaitaMask smart wallet is designed to be a “one stop shop” for its users who can link their choice of payment system to buy, sell, and transfer any crypto coin without having to leave its mobile app, which will be available for download in January. To give its users the ability to be more in control of their assets, the company said it plans to make SaitaMask “a hub connecting users to multiple tools helping them analyze and make investment choices.” Among the tools is an “Edutainment platform” to educate users about finance and investing, Saitama said.Launched on May 31, Saitama’s $SAITAMA token is built on the Ethereum blockchain ERC-20, the standard that’s used for all smart contracts on the Ethereum blockchain to administer tokens. The company said that the ERC-20 network incorporates “smart coding” that benefits loyal token holders with “rewards to protect against big wallet holders (whales) from trying to manipulate the price in their favor or from dumping tokens by selling out.”This is a busy time for New York-based CertiK, which is working with PeckShield to help crypto exchange platform Binance provide comprehensive security audits when reviewing project tokens that get listed on the exchange. Dubbed “Project Shield,” CertiK and PeckShield are providing the latest level of protection designed to safeguard Binance users and provide them access to secure projects. More

Two LastPass vice presidents have released statements about the situation surrounding LastPass security issues that came to light this week. 

Two days ago, hundreds of LastPass users took to Twitter, Reddit, and other sites to complain that they were getting alerts about their master password being used by someone who was not them. Some reported that even after changing their master password, someone tried to access their account again. On Tuesday, the company released a brief statement noting that its security team observed and received reports of potential credential stuffing attempts. Credential stuffing involves attackers stealing credentials (usernames, passwords, etc.) to access users’ accounts.”While we have observed a small uptick in this activity, we are utilizing multiple technical, organizational, and operational methods designed to protect against credential stuffing attempts. Importantly, we also want to reassure you that there is no indication, at this time, that LastPass or LogMeIn were breached or compromised,” wrote Gabor Angyal, VP of engineering at LastPass. On Wednesday, the company expanded Angyal’s original statement, explaining that it recently investigated reports of an uptick of users receiving blocked access emails, normally sent to users who log in from different devices and locations. The company’s initial findings led it to believe that these alerts were triggered in response to attempted “credential stuffing” activity. Angyal’s Wednesday statement said, “Out of an abundance of caution, we continued to investigate in an effort to determine what was causing the automated security alert emails to be triggered from our systems. Our investigation has since found that some of these security alerts, which were sent to a limited subset of LastPass users, were likely triggered in error. As a result, we have adjusted our security alert systems and this issue has since been resolved.” Angyal noted that at “no time does LastPass store, have knowledge of, or have access to a user’s Master Password(s).”

LastPass VP of product management Dan DeMichele sent out a notice to multiple outlets with the same information that was shared in the updated statement from Angyal. Some online were not assuaged by the statement, noting the qualifiers used that prompted more questions. Craig Lurey, CTO of password manager Keeper, said that what is so concerning about credential stuffing attacks is that attackers prey on a highly-prevalent problem among consumers right now: breach fatigue. “With a slew of breaches and alerts throughout 2021, consumers have become apathetic to compromised accounts. In fact, a recent survey from the Identity Theft Resource Center revealed that 16% of breach victims take absolutely no action to re-secure their accounts,” Lurey said. “In their minds, the ‘data is already out there,’ the hacked organization will take care of it, they don’t know what to do, or, ironically, they dismiss the notification as a scam. This apathy is what cybercriminals thrive on and is why we can expect to see a rise in credential stuffing alerts.”Due to the concerns over master passwords, Perimeter 81 CEO Amit Bareket suggested using biometric authentication or MFA for master passwords with managers like LastPass. Parent company LogMeIn announced just two weeks ago that it is spinning off LastPass into its own company.  More

Cybersecurity company CrowdStrike has discovered an attempt by a China-based group to infiltrate an academic institution through the Log4j vulnerability. 

more Log4j

CrowdStrike called the group “Aquatic Panda” and said it is an “intrusion adversary with a dual mission of intelligence collection and industrial espionage” that has operated since at least May 2020. The group’s exact intent is unknown because the attack was disrupted. CrowdStrike told ZDNet, however, that Aquatic Panda is known to maintain persistence in environments to gain access to intellectual property and other industrial trade secrets.”Aquatic Panda operations have primarily focused on entities in the telecommunications, technology, and government sectors,” CrowdStrike explained in a report.According to CrowdStrike, their system uncovered “suspicious activity stemming from a Tomcat process running under a vulnerable VMWare Horizon instance at a large academic institution, leading to the disruption of an active hands-on intrusion.”After watching the group operate and examining the telemetry available, CrowdStrike said it believes that a modified version of the Log4j exploit was likely used during the course of the threat actor’s operations.The team at CrowdStrike discovered that Aquatic Panda used a public GitHub project from Dec.13, 2021 in order to gain access to the vulnerable instance of VMWare Horizon. 

“Aquatic Panda continued their reconnaissance from the host, using native OS binaries to understand current privilege levels as well as system and domain details. OverWatch threat hunters also observed an attempt to discover and stop a third-party endpoint detection and response (EDR) service,” the company explained.”Throughout the intrusion, OverWatch tracked the threat actor’s activity closely in order to provide continuous updates to the victim organization. Based on the actionable intelligence provided by OverWatch, the victim organization was able to quickly implement their incident response protocol, eventually patching the vulnerable application and preventing further threat actor activity on the host.”CrowdStrike officials told ZDNet that they are seeing various threat actors both inside and outside of China leveraging the Log4J vulnerability, with adversaries ranging from advanced threat actors to eCrime actors. “In the end, the viability of this exploit is well-proven with a substantial attack surface still present. We will continue to see threat actors making use of this vulnerability until all recommended mitigations are put into place,” CrowdStrike said in an interview.Last week, the US, UK, Australia and other countries issued a Log4j advisory in response to “active, worldwide exploitation by numerous threat actors, including malicious cyber threat actors.” Numerous groups from North Korea, Iran, Turkey and China have been seen exploiting the vulnerability alongside a slate of ransomware groups and cybercriminal organizations. CISA Director Jen Easterly said Log4j vulnerabilities present a severe and ongoing threat to organizations and governments around the world”We implore all entities to take immediate action to implement the latest mitigation guidance to protect their networks,” Easterly said. “These vulnerabilities are the most severe that I’ve seen in my career, and it’s imperative that we work together to keep our networks safe.”  More

Digital photography company Shutterfly reported a ransomware attack on Sunday. The incident was first reported by Bleeping Computer, which said a source told them the company was attacked by the Conti ransomware group.  In a statement, the company said portions of the Lifetouch and BorrowLenses business were affected. They experienced interruptions with Groovebook, manufacturing offices, and some corporate systems as well. Law enforcement has been contacted and a cybersecurity company was also hired to help respond to the incident. “As part of our ongoing investigation, we are also assessing the full scope of any data that may have been affected. We do not store credit card, financial account information, or the Social Security numbers of our Shutterfly.com, Snapfish, Lifetouch, TinyPrints, BorrowLenses, or Spoonflower customers, and so none of that information was impacted in this incident,” Shutterfly explained.”However, understanding the nature of the data that may have been affected is a key priority and that investigation is ongoing. We will continue to provide updates as appropriate.”Conti began leaking information it stole to a leak site, according to Bleeping Computer, which added that the attack started about two weeks ago and involves a ransom demand in the millions. Last week, researchers with security firm Advanced Intelligence discovered the Conti ransomware group exploiting VMware vCenter Server instances through the Log4j vulnerabilities.

In a report, the security company said it discovered multiple members of Conti discussing ways to take advantage of the Log4j issue, making them the first sophisticated ransomware group spotted trying to weaponize the vulnerability. AdvIntel said the current exploitation “led to multiple use cases through which the Conti group tested the possibilities of utilizing the Log4J2 exploit.” They noted that their research of ransomware logs shows Conti made over $150 million in the last six months. AdvIntel laid out a timeline of events for Conti’s interest in Log4j starting on November 1, when the group sought to find new attack vectors. Throughout November, Conti redesigned its infrastructure as it sought to expand, and by December 12, they identified Log4Shell as a possibility. By December 15, they began actively targeting vCenter networks for lateral movement. Both CISA and the FBI said in September that they have seen more than 400 attacks involving Conti’s ransomware targeting US organizations as well as international enterprises. The FBI has previously implicated Conti in attacks on at least 290 organizations in the US. Conti has made a name for itself by attacking hundreds of healthcare institutions — including a debilitating ransomware attack on Ireland’s Health Service Executive on May 14 — as well as schools like the University of Utah and other government organizations like the city government of Tulsa, Oklahoma and the Scottish Environment Protection Agency. More

Linux is everywhere. It’s what all the clouds, even Microsoft Azure, run.  It’s what makes all 500 of the Top 500 supercomputers work. Heck, even desktop Linux is growing if you can believe Pornhub, which claims Linux users grew by 28%, while Windows users declined by 3%. 

Open-source software is also growing by leaps and bounds. According to Gartner’s 2021 Hype Cycle for Open-Source Software (OSS): “Through 2025, more than 70% of enterprises will increase their IT spending on OSS, compared with their current IT spending. Plus, by 2025, software as a service (SaaS) will become the preferred consumption model for OSS due to its ability to deliver better operational simplicity, security, and scalability.”Thinking of databases, the beef and potatoes of enterprise software, Gartner predicts that over 70% of new in-house applications will be developed on an open-source database. Simultaneously,  50% of existing proprietary relational database instances will have been converted or are being converted to open-source DBMSs.I’ll buy those numbers. I’ve been following Linux and open-source software since day one. Everywhere I go and everyone I talk to acknowledges that the pair run the software universe.But with great power also comes great responsibility as Spider-Man knows. And, as many developers recently found out when multiple security vulnerabilities with the Apache Java logging open-source library log4j2 were discovered, also comes great headaches.  The log4j2 problems are as bad as bad can get. By the National Vulnerability Database (NVD) scale, it’s rated as 10.0 CVSSv3 which is perfectly awful. Its real trouble isn’t so much with open-source itself. There’s nothing magical about open-source methodology and security. Security mistakes can still enter the code. Linus’s law is that given enough eyeballs, all bugs are shallow. But, if not enough developers are looking, security vulnerabilities will still go unnoticed. As what I’m now calling Schneier’s law, “Security is a process, not a product,” points out constant vigilance is needed to secure all software. 

That said, the real pain-in-the-rump with log4j is with how Java hides what libraries its source code and binaries use in numerous Java Archive (JAR) variations. The result? You may be using a vulnerable version of log4j and not know until it’s been exploited. As Josh Bressers, Anchore’s vice president of security recently explained, “One of the challenges the log4j vulnerability poses is actually finding it. Java applications and dependencies are usually in some sort of packaging format that makes the distribution and running really easy, but it can make figuring out what’s inside of those software packages difficult.”Fortunately, there are log4j scanners that can help you spot defective log4j libraries in use. But, they’re not perfect.Behind the log4j mess is another problem, That’s “How do you know what open-source components your software is using?” For example, log4j2 has been in use since 2014. You can’t expect anyone to remember if they used that first version in some program you’re still using today. The answer is one that the open-source community started taking seriously in recent years: The creation of Software Bills of Material (SBOM). An SBOM spells out exactly what software libraries, routines, and other code has been used in any program. Armed with this, you can examine what component versions are used in your program.As David A. Wheeler, the Linux Foundation’s Director of Open Source Supply Chain Security, has explained, by using SBOMs and verified reproducible builds, you can make sure you know what’s what in your programs. That way, if a security hole is found in a component, you can simply patch it rather than search like a maniac for any possible problem code before being able to fix it. “A reproducible build,” by the way explains Wheeler,  is one “that always produces the same outputs given the same inputs so that the build results can be verified. A verified reproducible build is a process where independent organizations produce a build from source code and verify that the built results come from the claimed source code.”To do this, you and your developers need to track your programs in an SBOM using the Linux Foundation’s Software Package Data Exchange (SPDX) format. Then, to further safeguard that your code is really what it claims to be you need to notarize and verify your SBOM with services such as the Codenotary Community Attestation Service and Tidelift Catalogs.All this is easy to say. Doing it hard. In 2022, pretty much all open-source developers are going to be spending a lot of time checking their code for problems and then building SPDX-based SBOMs. Users, worried over Solarwind type disasters and log4j security problems, will be demanding this.  At the same time, Linux developers are working on further securing the operating system by making Rust Linux’s second language. Why? Because, unlike C, Linux’s primary language, Rust is much more secure. Specifically, Rust is much safer than C  at handling memory errors.As Ryan Levick, a Microsoft principal cloud developer advocate, explained, “Rust is completely memory safe.” That’s a huge deal, since, as Linux kernel developers Alex Gaynor and Geoffrey Thomas pointed out at the 2019 Linux Security Summit, almost two-thirds of Linux kernel security holes come from memory safety issues. And where do those come from? Inherent problems with C and C++.  Now Linux is going to be rewritten in Rust. At least not this decade, check with me again in the 2030s, but a lot of Linux drivers and other code will be written going forward in Rust. As Linus Torvalds told me while he’s “in no way ‘pushing’ for Rust,” he’s “open to it considering the promised advantages and avoiding some safety pitfalls. Still, he concluded, “I also know that sometimes promises don’t pan out.” We’ll see how it all works out. No matter how the specifics go, one thing I know for certain. We’re going to see securing code become the top issue for Linux and open-source developers in 2022.  They’ve both become too important for it to go any other way. Related Stories: More

International businesses that process information from China should obtain user consent and establish a data map, so they do not run afoul of the country’s Personal Information Protection Law (PIPL). Specifically, they should look closely at cross-border data flow and residency, even as more clarity still is needed on some components in the new legislation. Organisations that already are set up to comply with Europe’s General Data Protection Regulation (GDPR), though, have a good foundation on which to work towards PIPL adherence.Passed in August, the Chinese legislation came into force last month, laying out ground rules around how data should be collected, used, and stored. It outlines data processing requirements for companies based outside of China, which included passing a security assessment conducted by state authorities.Multinational corporations (MNCs) that move personal information of the country also will have to obtain certification on data protection from professional institutions. The Chinese government described the legislation as necessary to address the “chaos” created, in which online platforms had been excessively collecting personal data.  

Because it was modelled broadly after GDPR, enterprises that had readied themselves for the EU data protection legislation would be better placed to prepare for PIPL compliance. For instance, both bills spell out the need to get user consent and rules around data sovereignty, according to Xin Leo, a Shanghai-based senior associate with law firm Pinsent Masons.Like GDPR, companies would need to obtain consent before collecting and using data from customers under PIPL. The Chinese legislation also outlined standard clauses that should be included in service contracts or agreements between both parties–one that provided the data and the other that received it–that were similar to those detailed under GDPR.

This ensured organisations that collected and processed data would provide similar levels of protection under PIPL as they would with GDPR, Xin said in an interview with ZDNet. Being GDPR-compliant put  enterprises on the right path towards PIPL adherence as well as other associated Chinese legislations, specifically, the country’s 2017 cybersecurity and 2021 data security bills, said JoHannah Harrington, chief legal officer at Elements Global Services, which specialises in HR technology and compliance. The company works with local law firms in China, where it also has corporate secretariat partners. Harrington, too, pointed to the need for user consent before data can be processed or transferred out of China as a common component that PIPL and GDPR shared. In addition, both laws required organisations to meet certain requirements, such as clear and reasonable purpose, for processing data they collected and have processes in place to maintain data protection. These included deploying data security tools and conducting risk mitigation processes, such as firewall and online privacy notices. Like GDPR, PIPL outlines the need to ensure user opt-in and the reclassification of data, said Sovan Bin, CEO of Odaseva. The data management vendor offers tools touted to ensure data is compliant, including with GDPR and PIPL, as it moves across an organisation’s global network.Consumers protected under both legislations also have the right to ask to be deleted or removed from an organisation’s database, Bin told ZDNet. Concerted efforts to define data ownership and return consent to consumers, regardless of where their data sat, began with GDPR, which was released in 2016. He said the EU legislation had put forward the concept of cross-border data transfers, so rules requiring organisations to obtain consent whenever they moved data outside the user’s home country were not unique to PIPL.Chinese regulators, though, had the benefit of time to assess the impact of such laws and adopt a modern approach, he noted. Data had become a key asset for every organisation over the years, while technologies also had evolved. Regulations established in the 1990s, for one, were no longer relevant with the emergence of cloud technologies, he said, adding that several countries were modernising their data regulations so these were more compatible with the cloud era.Questions remain about user consent, conflict with international lawsBut while PIPL shared several similarities with GDPR, there were some significant differences between both legislations that organisations should take note of. According to Harrington, PIPL does not include legitimate interests or purposes as a condition for data processing, while GDPR does. This, for instance, enables organisations to process their employees’ personal data, as it is deemed of legitimate reason. The exclusion of legitimate purposes could mean that MNCs would have to seek the consent of all employees in China, if they had not already done so, before their HR departments were permitted to process the employee’s personal information. Uncertainties over the concept of user consent, which was not well defined yet in PIPL, was one likely reason major technology companies had opted to leave the Chinese market, Harrington said.Clarity around consent was paramount because, under the Chinese legislation, it must be applied before data could be processed. She added that as the law was new and untested, clearer definitions in some areas still needed to be established.According to Xin, the legislation outlined three areas organisations should address with regards to cross-border data transfers. These included the need for a government security assessment, to gain approval, if the data processed exceeded a threshold specified by the legislation. Some requirements called for certain certifications to be established, under specific instances, between the data exporter and data receiver, but how such procedures should be carried out remained unclear, he said.

Both parties also would need to agree to a model, or template, contract to be stipulated by the regulator. This contract terms, however, had yet to be released. There was further uncertainty over PIPL rules pertaining to data sovereignty, Xin said, under which personal data stored in China could not be provided to foreign jurisdictions or organisations without the Chinese government’s consent. While this policy is not new, as it already is stated in the country’s data security and international corporate criminal laws, there are questions about how this will play out alongside international laws. The US CLOUD (Clarifying Lawful Overseas Use of Data) Act, in particular, gives US law enforcement power to demand access to data stored by cloud providers, including data held outside the US.Doing so in China would be in breach of PIPL, Xin said, which could create a dilemma for MNCs operating in the country. He added that provisions, if any, and procedures organisations should follow under such circumstances currently were unclear.Bin noted that organisations were spending more effort, in particular, on ensuring compliance with specifications related to cross-border data and data residency. PIPL outlined certain thresholds under which organisations would have to adhere to guidelines on how to process cross-border data, he said. Businesses handling personal data of more than 1 million users, for instance, or that had to transfer personal data of more than 100,000 users would have to abide to specific policies.Additional policies regarding data residency also would apply to certain types of data, he said. For instance, companies processing data deemed to be more sensitive must pass a security assessment by Cyberspace Administration of China (CAC).He advised businesses to exercise more care in handling such data across borders, to ensure compliance with PIPL.He further noted that, unlike GDPR where there was a two-year grace period during which organisations could ready themselves before enforcement and fines were implemented, PIPL did not have a similar allowance. In addition, the Chinese legislation was passed and came into force in a shorter time period, giving enterprises less time to prepare for compliance. Seek local representative, consent as first stepsWhile the legislation is new and some definitions remain unclear, there are some first steps organisations can take towards PIPL compliance. These include appointing a local representative and registering, where required, with the relevant authorities. Asking for user consent for all forms of data would be a good baseline from which to start, as well as ensuring there was a clear purpose for collecting user data, said Harrington. She also recommended organisations appoint local representatives to handle data-related processes in China and carry out security assessment of their data management. Xin advised companies to establish a data map, including determining the types of personal data they held, and perform a compliance review to identify gaps between their current data practices and PIPL requirements. They then would need to enhance their data policies as well as IT infrastructure and organisational structure accordingly to plug any gaps, he said. With different business units processing data differently, he stressed the need for organisations to ensure they had a comprehensive understanding of how all these departments collected and processed data. He also underscored the importance of training employees and beefing up overall awareness of data management policies. Businesses could consider appointing a representative for each business unit who was focused on data protection and reported to the company’s data privacy officer, he added.With regards to handling employees’ personal data, Xin also suggested organisations formulated their labour rules to incorporate data collection and protection practices. In accepting their employment with the organisation, employees then would have provided consent to the collection and management of personal data as stipulated under the company’s employment contract or handbook.This then would not require businesses to separately obtain employee consent for PIPL, he said. However, most MNCs that processed data of employees in China likely would need to do a separate privacy impact assessment, he noted.Any organisation that wished to transfer data out of China also would be required to carry out such assessments, he said, adding that those providing sensitive personal data to a third party would need to do likewise.According to PIPL, violators that fail to comply with orders to rectify the breach will face fines of up to 1 million yuan ($150,000), while the person responsible for ensuring compliance can be fined between 10,000 yuan ($1,500) and 100,000 yuan ($15,000). For “serious” cases, Chinese authorities also dish out fines of up to 50 million yuan ($7.5 million) or 5% of the company’s annual turnover for the previous fiscal year. In addition, its business operations may be suspended or business permits and licences revoked. RELATED COVERAGE More

CISA released its own Log4J scanner this week alongside a host of other scanners published by cybersecurity companies and researchers. 

more Log4j

The open-sourced Log4j scanner is derived from scanners created by other members of the open source community, and it is designed to help organizations identify potentially vulnerable web services affected by the Log4j vulnerabilities. CISA said it modified a Log4J scanner created by security company FullHunt and got help from other researchers like Philipp Klaus and Moritz Bechler. The repository provides a scanning solution for CVE-2021-44228 and CVE-2021-45046. CISA said it supports DNS callback for vulnerability discovery and validation while providing fuzzing for HTTP POST Data parameters, fuzzing for JSON data parameters, and support for lists of URLs. It also features WAF Bypass payloads and fuzzing for more than 60 HTTP request headers.CrowdStrike similarly released its own free Log4J scanner called the CrowdStrike Archive Scan Tool, or “CAST.” Yotam Perkal, vulnerability research lead at Rezilion, did a test of some of the Log4J scanners, finding that many were unable to find all instances of the vulnerability. 
Rezilion

“The biggest challenge lies in detecting Log4Shell within packaged software in production environments: Java files (such as Log4j) can be nested a few layers deep into other files – which means that a shallow search for the file won’t find it,” Perkal said. “Furthermore, they may be packaged in many different formats which creates a real challenge in digging them inside other Java packages.”Rezilion tested the nine scanners most commonly used by developers and IT teams against a dataset of packaged Java files where Log4j was nested and packaged in various formats.Perkal said that while some scanners did better than others, none were able to detect all formats. According to Perkal, the research illustrates “the limitations of static scanning in detecting Log4j instances.””It also reminds us that detection abilities are only as good as your detection method. Scanners have blindspots,” Perkal explained. “Security leaders cannot blindly assume that various open source or even commercial-grade tools will be able to detect every edge case. And in the case of Log4j, there are a lot of edge instances in many places.” More