Image: Shutterstock, ArtHead.
In an effort to blend in and make their malicious traffic tougher to block, hosting firms catering to cybercriminals in China and Russia increasingly are funneling their operations through major U.S. cloud providers. Research published this week on one such outfit — a sprawling network tied to Chinese organized crime gangs and aptly named “Funnull” — highlights a persistent whac-a-mole problem facing cloud services.
In October 2024, the security firm Silent Push published a lengthy analysis of how Amazon AWS and Microsoft Azure were providing services to Funnull, a two-year-old Chinese content delivery network that hosts a wide variety of fake trading apps, pig butchering scams, gambling websites, and retail phishing pages.
Funnull made headlines last summer after it acquired the domain name polyfill[.]io, previously the home of a widely-used open source code library that allowed older browsers to handle advanced functions that weren’t natively supported. There were still tens of thousands of legitimate domains linking to the Polyfill domain at the time of its acquisition, and Funnull soon after conducted a supply-chain attack that redirected visitors to malicious sites.
Silent Push’s October 2024 report found a vast number of domains hosted via Funnull promoting gambling sites that bear the logo of the Suncity Group, a Chinese entity named in a 2024 UN report (PDF) for laundering millions of dollars for the North Korean Lazarus Group.
In 2023, Suncity’s CEO was sentenced to 18 years in prison on charges of fraud, illegal gambling, and “triad offenses,” i.e. working with Chinese transnational organized crime syndicates. Suncity is alleged to have built an underground banking system that laundered billions of dollars for criminals.
It is likely the gambling sites coming through Funnull are abusing top casino brands as part of their money laundering schemes. In reporting on Silent Push’s October report, TechCrunch obtained a comment from Bwin, one of the casinos being advertised en masse through Funnull, and Bwin said those websites did not belong to them.
Gambling is illegal in China except in Macau, a special administrative region of China. Silent Push researchers say Funnull may be helping online gamblers in China evade the Communist party’s “Great Firewall,” which blocks access to gambling destinations.
Silent Push’s Zach Edwards said that upon revisiting Funnull’s infrastructure again this month, they found dozens of the same Amazon and Microsoft cloud Internet addresses still forwarding Funnull traffic through a dizzying chain of auto-generated domain names before redirecting malicious or phishous websites.
Edwards said Funnull is a textbook example of an increasing trend Silent Push calls “infrastructure laundering,” wherein crooks selling cybercrime services will relay some or all of their malicious traffic through U.S. cloud providers.
“It’s crucial for global hosting companies based in the West to wake up to the fact that extremely low quality and suspicious web hosts based out of China are deliberately renting IP space from multiple companies and then mapping those IPs to their criminal client websites,” Edwards told KrebsOnSecurity. “We need these major hosts to create internal policies so that if they are renting IP space to one entity, who further rents it to host numerous criminal websites, all of those IPs should be reclaimed and the CDN who purchased them should be banned from future IP rentals or purchases.”
A Suncity gambling site promoted via Funnull. The sites feature a prompt for a Tether/USDT deposit program.
Reached for comment, Amazon referred this reporter to a statement Silent Push included in a report released today. Amazon said AWS was already aware of the Funnull addresses tracked by Silent Push, and that it had suspended all known accounts linked to the activity.
Amazon said that contrary to implications in the Silent Push report, it has every reason to aggressively police its network against this activity, noting the accounts tied to Funnull used “fraudulent methods to temporarily acquire infrastructure, for which it never pays. Thus, AWS incurs damages as a result of the abusive activity.”
“When AWS’s automated or manual systems detect potential abuse, or when we receive reports of potential abuse, we act quickly to investigate and take action to stop any prohibited activity,” Amazon’s statement continues. “In the event anyone suspects that AWS resources are being used for abusive activity, we encourage them to report it to AWS Trust & Safety using the report abuse form. In this case, the authors of the report never notified AWS of the findings of their research via our easy-to-find security and abuse reporting channels. Instead, AWS first learned of their research from a journalist to whom the researchers had provided a draft.”
Microsoft likewise said it takes such abuse seriously, and encouraged others to report suspicious activity found on its network.
“We are committed to protecting our customers against this kind of activity and actively enforce acceptable use policies when violations are detected,” Microsoft said in a written statement. “We encourage reporting suspicious activity to Microsoft so we can investigate and take appropriate actions.”
Richard Hummel is threat intelligence lead at NETSCOUT. Hummel said it used to be that “noisy” and frequently disruptive malicious traffic — such as automated application layer attacks, and “brute force” efforts to crack passwords or find vulnerabilities in websites — came mostly from botnets, or large collections of hacked devices.
But he said the vast majority of the infrastructure used to funnel this type of traffic is now proxied through major cloud providers, which can make it difficult for organizations to block at the network level.
“From a defenders point of view, you can’t wholesale block cloud providers, because a single IP can host thousands or tens of thousands of domains,” Hummel said.
In May 2024, KrebsOnSecurity published a deep dive on Stark Industries Solutions, an ISP that materialized at the start of Russia’s invasion of Ukraine and has been used as a global proxy network that conceals the true source of cyberattacks and disinformation campaigns against enemies of Russia. Experts said much of the malicious traffic traversing Stark’s network (e.g. vulnerability scanning and password brute force attacks) was being bounced through U.S.-based cloud providers.
Stark’s network has been a favorite of the Russian hacktivist group called NoName057(16), which frequently launches huge distributed denial-of-service (DDoS) attacks against a variety of targets seen as opposed to Moscow. Hummel said NoName’s history suggests they are adept at cycling through new cloud provider accounts, making anti-abuse efforts into a game of whac-a-mole.
“It almost doesn’t matter if the cloud provider is on point and takes it down because the bad guys will just spin up a new one,” he said. “Even if they’re only able to use it for an hour, they’ve already done their damage. It’s a really difficult problem.”
Edwards said Amazon declined to specify whether the banned Funnull users were operating using compromised accounts or stolen payment card data, or something else.
“I’m surprised they wanted to lean into ‘We’ve caught this 1,200+ times and have taken these down!’ and yet didn’t connect that each of those IPs was mapped to [the same] Chinese CDN,” he said. “We’re just thankful Amazon confirmed that account mules are being used for this and it isn’t some front-door relationship. We haven’t heard the same thing from Microsoft but it’s very likely that the same thing is happening.”
Funnull wasn’t always a bulletproof hosting network for scam sites. Prior to 2022, the network was known as Anjie CDN, based in the Philippines. One of Anjie’s properties was a website called funnull[.]app. Loading that domain reveals a pop-up message by the original Anjie CDN owner, who said their operations had been seized by an entity known as Fangneng CDN and ACB Group, the parent company of Funnull.
A machine-translated message from the former owner of Anjie CDN, a Chinese content delivery network that is now Funnull.
“After I got into trouble, the company was managed by my family,” the message explains. “Because my family was isolated and helpless, they were persuaded by villains to sell the company. Recently, many companies have contacted my family and threatened them, believing that Fangneng CDN used penetration and mirroring technology through customer domain names to steal member information and financial transactions, and stole customer programs by renting and selling servers. This matter has nothing to do with me and my family. Please contact Fangneng CDN to resolve it.”
In January 2024, the U.S. Department of Commerce issued a proposed rule that would require cloud providers to create a “Customer Identification Program” that includes procedures to collect data sufficient to determine whether each potential customer is a foreign or U.S. person.
According to the law firm Crowell & Moring LLP, the Commerce rule also would require “infrastructure as a service” (IaaS) providers to report knowledge of any transactions with foreign persons that might allow the foreign entity to train a large AI model with potential capabilities that could be used in malicious cyber-enabled activity.
“The proposed rulemaking has garnered global attention, as its cross-border data collection requirements are unprecedented in the cloud computing space,” Crowell wrote. “To the extent the U.S. alone imposes these requirements, there is concern that U.S. IaaS providers could face a competitive disadvantage, as U.S. allies have not yet announced similar foreign customer identification requirements.”
It remains unclear if the new White House administration will push forward with the requirements. The Commerce action was mandated as part of an executive order President Trump issued a day before leaving office in January 2021.
Malicious hackers are exploiting a zero-day vulnerability in Versa Director, a software product used by many Internet and IT service providers. Researchers believe the activity is linked to Volt Typhoon, a Chinese cyber espionage group focused on infiltrating critical U.S. networks and laying the groundwork for the ability to disrupt communications between the United States and Asia during any future armed conflict with China.
Image: Shutterstock.com
Versa Director systems are primarily used by Internet service providers (ISPs), as well as managed service providers (MSPs) that cater to the IT needs of many small to mid-sized businesses simultaneously. In a security advisory published Aug. 26, Versa urged customers to deploy a patch for the vulnerability (CVE-2024-39717), which the company said is fixed in Versa Director 22.1.4 or later.
Versa said the weakness allows attackers to upload a file of their choosing to vulnerable systems. The advisory placed much of the blame on Versa customers who “failed to implement system hardening and firewall guidelines…leaving a management port exposed on the internet that provided the threat actors with initial access.”
Versa’s advisory doesn’t say how it learned of the zero-day flaw, but its vulnerability listing at mitre.org acknowledges “there are reports of others based on backbone telemetry observations of a 3rd party provider, however these are unconfirmed to date.”
Those third-party reports came in late June 2024 from Michael Horka, senior lead information security engineer at Black Lotus Labs, the security research arm of Lumen Technologies, which operates one of the global Internet’s largest backbones.
In an interview with KrebsOnSecurity, Horka said Black Lotus Labs identified a web-based backdoor on Versa Director systems belonging to four U.S. victims and one non-U.S. victim in the ISP and MSP sectors, with the earliest known exploit activity occurring at a U.S. ISP on June 12, 2024.
“This makes Versa Director a lucrative target for advanced persistent threat (APT) actors who would want to view or control network infrastructure at scale, or pivot into additional (or downstream) networks of interest,” Horka wrote in a blog post published today.
Black Lotus Labs said it assessed with “medium” confidence that Volt Typhoon was responsible for the compromises, noting the intrusions bear the hallmarks of the Chinese state-sponsored espionage group — including zero-day attacks targeting IT infrastructure providers, and Java-based backdoors that run in memory only.
In May 2023, the National Security Agency (NSA), the Federal Bureau of Investigation (FBI), and the Cybersecurity Infrastructure Security Agency (CISA) issued a joint warning (PDF) about Volt Typhoon, also known as “Bronze Silhouette” and “Insidious Taurus,” which described how the group uses small office/home office (SOHO) network devices to hide their activity.
In early December 2023, Black Lotus Labs published its findings on “KV-botnet,” thousands of compromised SOHO routers that were chained together to form a covert data transfer network supporting various Chinese state-sponsored hacking groups, including Volt Typhoon.
In January 2024, the U.S. Department of Justice disclosed the FBI had executed a court-authorized takedown of the KV-botnet shortly before Black Lotus Labs released its December report.
In February 2024, CISA again joined the FBI and NSA in warning Volt Typhoon had compromised the IT environments of multiple critical infrastructure organizations — primarily in communications, energy, transportation systems, and water and wastewater sectors — in the continental and non-continental United States and its territories, including Guam.
“Volt Typhoon’s choice of targets and pattern of behavior is not consistent with traditional cyber espionage or intelligence gathering operations, and the U.S. authoring agencies assess with high confidence that Volt Typhoon actors are pre-positioning themselves on IT networks to enable lateral movement to OT [operational technology] assets to disrupt functions,” that alert warned.
In a speech at Vanderbilt University in April, FBI Director Christopher Wray said China is developing the “ability to physically wreak havoc on our critical infrastructure at a time of its choosing,” and that China’s plan is to “land blows against civilian infrastructure to try to induce panic.”
Ryan English, an information security engineer at Lumen, said it’s disappointing his employer didn’t at least garner an honorable mention in Versa’s security advisory. But he said he’s glad there are now a lot fewer Versa systems exposed to this attack.
“Lumen has for the last nine weeks been very intimate with their leadership with the goal in mind of helping them mitigate this,” English said. “We’ve given them everything we could along the way, so it kind of sucks being referenced just as a third party.”
The U.S. government is warning that “smart locks” securing entry to an estimated 50,000 dwellings nationwide contain hard-coded credentials that can be used to remotely open any of the locks. The lock’s maker Chirp Systems remains unresponsive, even though it was first notified about the critical weakness in March 2021. Meanwhile, Chirp’s parent company, RealPage, Inc., is being sued by multiple U.S. states for allegedly colluding with landlords to illegally raise rents.
On March 7, 2024, the U.S. Cybersecurity & Infrastructure Security Agency (CISA) warned about a remotely exploitable vulnerability with “low attack complexity” in Chirp Systems smart locks.
“Chirp Access improperly stores credentials within its source code, potentially exposing sensitive information to unauthorized access,” CISA’s alert warned, assigning the bug a CVSS (badness) rating of 9.1 (out of a possible 10). “Chirp Systems has not responded to requests to work with CISA to mitigate this vulnerability.”
Matt Brown, the researcher CISA credits with reporting the flaw, is a senior systems development engineer at Amazon Web Services. Brown said he discovered the weakness and reported it to Chirp in March 2021, after the company that manages his apartment building started using Chirp smart locks and told everyone to install Chirp’s app to get in and out of their apartments.
“I use Android, which has a pretty simple workflow for downloading and decompiling the APK apps,” Brown told KrebsOnSecurity. “Given that I am pretty picky about what I trust on my devices, I downloaded Chirp and after decompiling, found that they were storing passwords and private key strings in a file.”
Using those hard-coded credentials, Brown found an attacker could then connect to an application programming interface (API) that Chirp uses which is managed by smart lock vendor August.com, and use that to enumerate and remotely lock or unlock any door in any building that uses the technology.
Update, April 18, 11:55 a.m. ET: August has provided a statement saying it does not believe August or Yale locks are vulnerable to the hack described by Brown.
“We were recently made aware of a vulnerability disclosure regarding access control systems provided by Chirp, using August and Yale locks in multifamily housing,” the company said. “Upon learning of these reports, we immediately and thoroughly investigated these claims. Our investigation found no evidence that would substantiate the vulnerability claims in either our product or Chirp’s as it relates to our systems.”
Update, April 25, 2:45 p.m. ET: Based on feedback from Chirp, CISA has downgraded the severity of this flaw and revised their security advisory to say that the hard-coded credentials do not appear to expose the devices to remote locking or unlocking. CISA says the hardcoded credentials could be used by an attacker within the range of Bluetooth (~30 meters) “to change the configuration settings within the Bluetooth beacon, effectively removing Bluetooth visibility from the device. This does not affect the device’s ability to lock or unlock access points, and access points can still be operated remotely by unauthorized users via other means.”
Brown said when he complained to his leasing office, they sold him a small $50 key fob that uses Near-Field Communications (NFC) to toggle the lock when he brings the fob close to his front door. But he said the fob doesn’t eliminate the ability for anyone to remotely unlock his front door using the exposed credentials and the Chirp mobile app.
Also, the fobs pass the credentials to his front door over the air in plain text, meaning someone could clone the fob just by bumping against him with a smartphone app made to read and write NFC tags.
Neither August nor Chirp Systems responded to requests for comment. It’s unclear exactly how many apartments and other residences are using the vulnerable Chirp locks, but multiple articles about the company from 2020 state that approximately 50,000 units use Chirp smart locks with August’s API.
Roughly a year before Brown reported the flaw to Chirp Systems, the company was bought by RealPage, a firm founded in 1998 as a developer of multifamily property management and data analytics software. In 2021, RealPage was acquired by the private equity giant Thoma Bravo.
Brown said the exposure he found in Chirp’s products is “an obvious flaw that is super easy to fix.”
“It’s just a matter of them being motivated to do it,” he said. “But they’re part of a private equity company now, so they’re not answerable to anybody. It’s too bad, because it’s not like residents of [the affected] properties have another choice. It’s either agree to use the app or move.”
In October 2022, an investigation by ProPublica examined RealPage’s dominance in the rent-setting software market, and that it found “uses a mysterious algorithm to help landlords push the highest possible rents on tenants.”
“For tenants, the system upends the practice of negotiating with apartment building staff,” ProPublica found. “RealPage discourages bargaining with renters and has even recommended that landlords in some cases accept a lower occupancy rate in order to raise rents and make more money. One of the algorithm’s developers told ProPublica that leasing agents had ‘too much empathy’ compared to computer generated pricing.”
Last year, the U.S. Department of Justice threw its weight behind a massive lawsuit filed by dozens of tenants who are accusing the $9 billion apartment software company of helping landlords collude to inflate rents.
In February 2024, attorneys general for Arizona and the District of Columbia sued RealPage, alleging RealPage’s software helped create a rental monopoly.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) said today it is investigating a breach at business intelligence company Sisense, whose products are designed to allow companies to view the status of multiple third-party online services in a single dashboard. CISA urged all Sisense customers to reset any credentials and secrets that may have been shared with the company, which is the same advice Sisense gave to its customers Wednesday evening.
New York City based Sisense has more than a thousand customers across a range of industry verticals, including financial services, telecommunications, healthcare and higher education. On April 10, Sisense Chief Information Security Officer Sangram Dash told customers the company had been made aware of reports that “certain Sisense company information may have been made available on what we have been advised is a restricted access server (not generally available on the internet.)”
“We are taking this matter seriously and promptly commenced an investigation,” Dash continued. “We engaged industry-leading experts to assist us with the investigation. This matter has not resulted in an interruption to our business operations. Out of an abundance of caution, and while we continue to investigate, we urge you to promptly rotate any credentials that you use within your Sisense application.”
In its alert, CISA said it was working with private industry partners to respond to a recent compromise discovered by independent security researchers involving Sisense.
“CISA is taking an active role in collaborating with private industry partners to respond to this incident, especially as it relates to impacted critical infrastructure sector organizations,” the sparse alert reads. “We will provide updates as more information becomes available.”
Sisense declined to comment when asked about the veracity of information shared by two trusted sources with close knowledge of the breach investigation. Those sources said the breach appears to have started when the attackers somehow gained access to the company’s Gitlab code repository, and in that repository was a token or credential that gave the bad guys access to Sisense’s Amazon S3 buckets in the cloud.
Customers can use Gitlab either as a solution that is hosted in the cloud at Gitlab.com, or as a self-managed deployment. KrebsOnSecurity understands that Sisense was using the self-managed version of Gitlab.
Both sources said the attackers used the S3 access to copy and exfiltrate several terabytes worth of Sisense customer data, which apparently included millions of access tokens, email account passwords, and even SSL certificates.
The incident raises questions about whether Sisense was doing enough to protect sensitive data entrusted to it by customers, such as whether the massive volume of stolen customer data was ever encrypted while at rest in these Amazon cloud servers.
It is clear, however, that unknown attackers now have all of the credentials that Sisense customers used in their dashboards.
The breach also makes clear that Sisense is somewhat limited in the clean-up actions that it can take on behalf of customers, because access tokens are essentially text files on your computer that allow you to stay logged in for extended periods of time — sometimes indefinitely. And depending on which service we’re talking about, it may be possible for attackers to re-use those access tokens to authenticate as the victim without ever having to present valid credentials.
Beyond that, it is largely up to Sisense customers to decide if and when they change passwords to the various third-party services that they’ve previously entrusted to Sisense.
Earlier today, a public relations firm working with Sisense reached out to learn if KrebsOnSecurity planned to publish any further updates on their breach (KrebsOnSecurity posted a screenshot of the CISO’s customer email to both LinkedIn and Mastodon on Wednesday evening). The PR rep said Sisense wanted to make sure they had an opportunity to comment before the story ran.
But when confronted with the details shared by my sources, Sisense apparently changed its mind.
“After consulting with Sisense, they have told me that they don’t wish to respond,” the PR rep said in an emailed reply.
Update, 6:49 p.m., ET: Added clarification that Sisense is using a self-hosted version of Gitlab, not the cloud version managed by Gitlab.com.
Also, Sisense’s CISO Dash just sent an update to customers directly. The latest advice from the company is far more detailed, and involves resetting a potentially large number of access tokens across multiple technologies, including Microsoft Active Directory credentials, GIT credentials, web access tokens, and any single sign-on (SSO) secrets or tokens.
The full message from Dash to customers is below:
“Good Afternoon,
We are following up on our prior communication of April 10, 2024, regarding reports that certain Sisense company information may have been made available on a restricted access server. As noted, we are taking this matter seriously and our investigation remains ongoing.
Our customers must reset any keys, tokens, or other credentials in their environment used within the Sisense application.
Specifically, you should:
– Change Your Password: Change all Sisense-related passwords on http://my.sisense.com
– Non-SSO:
– Replace the Secret in the Base Configuration Security section with your GUID/UUID.
– Reset passwords for all users in the Sisense application.
– Logout all users by running GET /api/v1/authentication/logout_all under Admin user.
– Single Sign-On (SSO):
– If you use SSO JWT for the user’s authentication in Sisense, you will need to update sso.shared_secret in Sisense and then use the newly generated value on the side of the SSO handler.
– We strongly recommend rotating the x.509 certificate for your SSO SAML identity provider.
– If you utilize OpenID, it’s imperative to rotate the client secret as well.
– Following these adjustments, update the SSO settings in Sisense with the revised values.
– Logout all users by running GET /api/v1/authentication/logout_all under Admin user.
– Customer Database Credentials: Reset credentials in your database that were used in the Sisense application to ensure continuity of connection between the systems.
– Data Models: Change all usernames and passwords in the database connection string in the data models.
– User Params: If you are using the User Params feature, reset them.
– Active Directory/LDAP: Change the username and user password of users whose authorization is used for AD synchronization.
– HTTP Authentication for GIT: Rotate the credentials in every GIT project.
– B2D Customers: Use the following API PATCH api/v2/b2d-connection in the admin section to update the B2D connection.
– Infusion Apps: Rotate the associated keys.
– Web Access Token: Rotate all tokens.
– Custom Email Server: Rotate associated credentials.
– Custom Code: Reset any secrets that appear in custom code Notebooks.
If you need any assistance, please submit a customer support ticket at https://community.sisense.com/t5/support-portal/bd-p/SupportPortal and mark it as critical. We have a dedicated response team on standby to assist with your requests.
At Sisense, we give paramount importance to security and are committed to our customers’ success. Thank you for your partnership and commitment to our mutual security.
Regards,
Sangram Dash
Chief Information Security Officer”
As head of the Cisco Trust Office, Matt Fussa leads a global team that partners with government agencies, regulators, and customers to help shape cybersecurity regulation and manage cyber risk. He is… Read more on Cisco Blogs
A tools for Find APK Infrastructure .
HADESS performs offensive cybersecurity services through infrastructures and software that include vulnerability analysis, scenario attack planning, and implementation of custom integrated preventive projects. We organized our activities around the prevention of corporate, industrial, and laboratory cyber threats.
pip install -r requirements.txt
python main.py
--help Display help
--path Required path of apk file
--manifest Display manifest informations
--infra Find all infra addresses included ip,domain ex. --infra ip,domain
--whoise Whoise all infra included ip,domain ex. --whoise ip,domain
--output Set output files ex. --output out.txt
Example Usage:
1.Find infra(domain and ip) in sample4.apk and set output result into out.txt
python3 main.py --path sample4.apk --infra domain,ip --output out.txt
python3 main.py --path sample.apk --whois ip
The U.S. government agency in charge of improving the nation’s cybersecurity posture is ordering all federal agencies to take new measures to restrict access to Internet-exposed networking equipment. The directive comes amid a surge in attacks targeting previously unknown vulnerabilities in widely used security and networking appliances.
Under a new order from the Cybersecurity and Infrastructure Security Agency (CISA), federal agencies will have 14 days to respond to any reports from CISA about misconfigured or Internet-exposed networking equipment. The directive applies to any networking devices — such as firewalls, routers and load balancers — that allow remote authentication or administration.
The order requires federal departments to limit access so that only authorized users on an agency’s local or internal network can reach the management interfaces of these devices. CISA’s mandate follows a slew of recent incidents wherein attackers exploited zero-day flaws in popular networking products to conduct ransomware and cyber espionage attacks on victim organizations.
Earlier today, incident response firm Mandiant revealed that since at least October 2022, Chinese cyber spies have been exploiting a zero-day vulnerability in many email security gateway (ESG) appliances sold by California-based Barracuda Networks to hoover up email from organizations using these devices.
Barracuda was alerted to the exploitation of a zero-day in its products in mid-May, and two days later the company pushed a security update to address the flaw in all affected devices. But last week, Barracuda took the highly unusual step of offering to replace compromised ESGs, evidently in response to malware that altered the systems in such a fundamental way that they could no longer be secured remotely with software updates.
According to Mandiant, a previously unidentified Chinese hacking group was responsible for exploiting the Barracuda flaw, and appeared to be searching through victim organization email records for accounts “belonging to individuals working for a government with political or strategic interest to [China] while this victim government was participating in high-level, diplomatic meetings with other countries.”
When security experts began raising the alarm about a possible zero-day in Barracuda’s products, the Chinese hacking group altered their tactics, techniques and procedures (TTPs) in response to Barracuda’s efforts to contain and remediate the incident, Mandiant found.
Mandiant said the attackers will continue to change their tactics and malware, “especially as network defenders continue to take action against this adversary and their activity is further exposed by the infosec community.”
Meanwhile, this week we learned more details about the ongoing exploitation of a zero-day flaw in a broad range of virtual private networking (VPN) products made by Fortinet — devices many organizations rely on to facilitate remote network access for employees.
On June 11, Fortinet released a half-dozen security updates for its FortiOS firmware, including a weakness that researchers said allows an attacker to run malware on virtually any Fortinet SSL VPN appliance. The researchers found that just being able to reach the management interface for a vulnerable Fortinet SSL VPN appliance was enough to completely compromise the devices.
“This is reachable pre-authentication, on every SSL VPN appliance,” French vulnerability researcher Charles Fol tweeted. “Patch your #Fortigate.”
In details published on June 12, Fortinet confirmed that one of the vulnerabilities (CVE-2023-27997) is being actively exploited. The company said it discovered the weakness in an internal code audit that began in January 2023 — when it learned that Chinese hackers were exploiting a different zero-day flaw in its products.
Shodan.io, the search engine made for finding Internet of Things devices, reports that there are currently more than a half-million vulnerable Fortinet devices reachable via the public Internet.
The new cybersecurity directive from CISA orders agencies to remove any networking device management interfaces from the internet by making them only accessible from an internal enterprise network (CISA recommends an isolated management network). CISA also says agencies should “deploy capabilities, as part of a Zero Trust Architecture, that enforce access control to the interface through a policy enforcement point separate from the interface itself (preferred action).”
Security experts say CISA’s directive highlights the reality that cyberspies and ransomware gangs are making it increasingly risky for organizations to expose any devices to the public Internet, because these groups have strong incentives to probe such devices for previously unknown security vulnerabilities.
The most glaring example of this dynamic can be seen in the frequency with which ransomware groups have discovered and pounced on zero-day flaws in widely-used file transfer applications. One ransomware gang in particular — Cl0p — has repeatedly exploited zero day bugs in various file transfer appliances to extort tens of millions of dollars from hundreds of ransomware victims.
On February 2, KrebsOnSecurity broke the news that attackers were exploiting a zero-day vulnerability in the GoAnywhere file transfer appliance by Fortra. By the time security updates were available to fix the vulnerability, Cl0p had already used it to steal data from more than a hundred organizations running Fortra’s appliance.
According to CISA, on May 27, Cl0p began exploiting a previously unknown flaw in MOVEit Transfer, a popular Internet-facing file transfer application. MOVEit parent Progress Software has since released security updates to address the weakness, but Cl0p claims to have already used it to compromise hundreds of victim organizations. TechCrunch has been tracking the fallout from victim organizations, which range from banks and insurance providers to universities and healthcare entities.
The always on-point weekly security news podcast Risky Business has recently been urging organizations to jettison any and all FTP appliances, noting that Cl0p (or another crime gang) is likely to visit the same treatment on other FTP appliance vendors.
But that sound advice doesn’t exactly scale for mid-tier networking devices like Barracuda ESGs or Fortinet SSL VPNs, which are particularly prominent in small to mid-sized organizations.
“It’s not like FTP services, you can’t tell an enterprise [to] turn off the VPN [because] the productivity hit of disconnecting the VPN is terminal, it’s a non-starter,” Risky Business co-host Adam Boileau said on this week’s show. “So how to mitigate the impact of having to use a domain-joined network appliance at the edge of your network that is going to get zero-day in it? There’s no good answer.”
Risky Business founder Patrick Gray said the COVID-19 pandemic breathed new life into entire classes of networking appliances that rely on code which was never designed with today’s threat models in mind.
“In the years leading up to the pandemic, the push towards identity-aware proxies and zero trust everything and moving away from this type of equipment was gradual, but it was happening,” Gray said. “And then COVID-19 hit and everybody had to go work from home, and there really was one option to get going quickly — which was to deploy VPN concentrators with enterprise features.”
Gray said the security industry had been focused on building the next generation of remote access tools that are more security-hardened, but when the pandemic hit organizations scrambled to cobble together whatever they could.
“The only stuff available in the market was all this old crap that is not QA’d properly, and every time you shake them CVEs fall out,” Gray remarked, calling the pandemic, “a shot in the arm” to companies like Fortinet and Barracuda.
“They sold so many VPNs through the pandemic and this is the hangover,” Gray said. “COVID-19 extended the life of these companies and technologies, and that’s unfortunate.”
The legislation aims to bolster the Union’s cyber-resilience and enhance its capabilities to prepare for, detect and respond to incidents
The post The EU’s Cyber Solidarity Act: Security Operations Centers to the rescue! appeared first on WeLiveSecurity
Editor’s note: While this topic isn’t entirely security-specific, Trend Micro leader William Malik, has career expertise on the trending topic and shared his perspective.
——
There was a provocative report recently that the Governor of New Jersey told reporters that the state of New Jersey needed COBOL programmers. The reason was that the number of unemployment claims had spiked, and the legacy system running unemployment claims had failed. That 40-year-old system was written in COBOL, so the conclusion was that the old language had finally given out. Hiring COBOL programmers would let the State update and modernize the application to handle the increase in load.
This might be the problem, but it probably is not. Here’s why.
From these points, we learn the following lessons.
Software Doesn’t Wear Out
Logic is indelible. A computer program is deterministic. It will do exactly what you tell it to do, even if what you tell it to do isn’t precisely what you meant it to do. Code never misbehaves – but your instructions may be incorrect. That’s why debugging is such a hard problem.
Incidentally, that’s also why good developers usually make lousy testers. The developer focuses her mind on one thing – getting a bunch of silicon to behave. The tester looks for faults, examines edge conditions, limit conditions, and odd configurations of inputs and infrastructure to see how things break. The two mindsets are antithetical.
Once a piece of software has been in production long enough, the mainline paths are usually defect free. In fact, the rest of the code may be a hot mess, but that stuff doesn’t get executed so those defects are latent and do not impact normal processing. Ed Adams published a report in 1984 titled “Optimizing Preventative Service for Software Products” (https://ieeexplore.ieee.org/document/5390362, originally published in the IBM Journal of Research and Development, v 28, n 1). He concluded that once a product has been in production for a sufficient time, it was safer to leave it alone. Installing preventative maintenance was likely to disrupt the system. Most IT organizations know this, having learned the hard way. “If it ain’t broke, don’t fix it” is the mantra for this wisdom.
As a corollary, new software has a certain defect rate. Fixes to that software typically have a defect rate ten times greater. So if a typical fix is large enough, you put in a new bug for every bug you take out.
Computers Are Constrained
All computers have constraints. The relative amount of resources mean some computers are better for some workloads than others. For mainframes, the typical constraint is processing power. That’s why mainframes are tuned to run at 100% utilization, or higher. (How do you get past 100% utilization? Technically, of course, you can’t. But what the measurements are showing you is how much work is ready to run, waiting for available processing power. The scale actually can go to 127%, if there’s enough work ready.)
Different types of computers have different constraints. Mainframes run near 100% utilization – the CPU is the most expensive and constrained resource. PCs on the other hand never get busy. No human can type fast enough to drive utilization above a few percent. The constrained resource on PCs is typically disk storage. That’s why different types of computers do better at different types of work. PCs are great for user interface stuff. Mainframes are perfect for chewing through a million database records. By chance we developed mainframes first; that’s not an indictment of either type, Both are useful.
Computers Can Run Out of Resources
Any IT infrastructure has a design point for load. That is, when you put together a computer you structure it to meet the likely level of demand on the system. If you over-provision it, you waste resources that will never be used. If you under-provision it, you will not meet your service level agreements. So when you begin, you must know what the customers – your users – expect in terms of response time, number of concurrent transactions, database size, growth rates, network transaction load, transaction mix, computational complexity of transaction types, and so on. If you don’t specify what your targets are for these parameters, you probably won’t get the sizing right. You will likely buy too much of one resource or not enough of another.
Note that cloud computing can help – it allows you to dynamically add additional capacity to handle peak load. However, cloud isn’t a panacea. Some workloads don’t flex that much, so you spend extra money for flexibility for a capability that you can provide more economically and efficiently if it were in-house.
Add Capacity in Balance
When I was in high school our physics teacher explained that temperature wasn’t the same as heat. He said “Heat is the result of a physical or chemical reaction. Temperature is simply the change in heat over the mass involved.” One of the kids asked (snarkily) “Then why don’t drag racers have bicycle tires on the back?” The teacher was caught off guard. The answer is that the amount of heat put into the tire is the same regardless of its size, but the temperature was related to the size of the area where the tire touched the road. A bicycle tire has only about two square inches on the pavement, a fat drag tire has 100 square inches or more. So putting the same amount of horsepower spinning the tire will cause the bicycle tire’s temperature to rise about 50 times more than the gumball’s will.
When you add capacity to a computing system, you need to balance related capacity elements or you’ll be wasting money. Doubling the processor’s power (MHz or MIPS) without proportionately increasing the memory or network capacity simply moves the constraint from one place to another. What used to be a system with a flat-out busy CPU now becomes a system that’s waiting for work with a queue at the memory, the disk drive, or the network card.
Adding Staff Makes Things Worse
Increasing any resource creates potential problems of its own, especially of the system’s underlying architecture is ignored. Fore the software development process (regardless of form) one such resource is staff. The book “The Mythical Man-Month” by Fred Brooks (https://www.barnesandnoble.com/w/the-mythical-man-month-frederick-p-brooks-jr/1126893908) discusses how things go wrong.
The core problem is adding more people require strong communications and clear goals. Too many IT projects lack both. I once was part of an organization that consulted on a complex application rewrite – forty consultants, hundreds of developers, and very little guidance. The situation degenerated rapidly when the interim project manager decided we shouldn’t waste time on documentation. A problem would surface, the PM would kick off as task force, hold a meeting, and send everybody on their way. After the meeting, people would ask what specific decisions had been reached, but since there were no minutes, nobody could be sure. That would cause the PM to schedule another meeting, and so on. Two lessons I learned concerns meetings:
When you add staff, you must account for the extra overhead managing the activities of each person, and establish processes to monitor changes that every participant must follow. Scrum is an excellent way of flattening potentially harmful changes. By talking face to face regularly, the team knows everything that’s going on. Omit those meetings or rely on second-hand reports and the project is already off the rails. All that remains is to see how far things go wrong before someone notices.
In Conclusion …
If you have a computer system that suddenly gets a huge spike in load, do these things first:
If you are unable to resolve the capacity constraints with these steps, examine the programs for internal limitations:
Note that if you do not have (or cannot find) the relevant documentation, you will need to examine the source code. At this point, you may need to bring in a small set of experts in the programming language to recreate the relevant documentation. Handy hint: before you start working on the source code, regenerate the load modules and compare them with the production stuff to identify any patches or variance between what’s in the library and what’s actually in production.
Bringing in a bunch of people before going through this analysis will cause confusion and waste resources. While to an uninformed public it may appear that something is being done, the likelihood is that what is actually being done will have to be expensively undone before the actual core problem can be resolved. Tread lightly. Plan ahead. State your assumptions, then verify them. Have a good plan and you’ll work it out. Remember, it’s just ones and zeros.
What do you think? Let me know in the comments below, or @WilliamMalikTM.
The post “We Need COBOL Programmers!” No, You Probably Don’t appeared first on .