Search This Blog

Powered by Blogger.

Blog Archive

Labels

Showing posts with label TLS. Show all posts

NCSC Unveils “Pigmy Goat” Malware Targeting Sophos Firewalls in Advanced Chinese Cyberattack

 

The National Cyber Security Centre (NCSC) recently disclosed the presence of a Linux malware, “Pigmy Goat,” specifically designed to breach Sophos XG firewall devices. This malware, allegedly developed by Chinese cyber actors, represents a significant evolution in network infiltration tactics due to its complexity and advanced evasion methods. 

This revelation follows Sophos’ recent “Pacific Rim” reports, which detail a five-year campaign involving Chinese threat actors targeting network devices at an unprecedented scale. Among the identified tools, “Pigmy Goat” stands out as a rootkit crafted to resemble legitimate Sophos product files, making it challenging to detect. This strategy is known to use stealth by masking its identity within commonly named system files to evade basic detection protocols. “Pigmy Goat” enables threat actors to establish persistent, unauthorized access to the target’s network. Using the LD_PRELOAD environment variable, it embeds itself in the SSH daemon (sshd), allowing it to intercept and alter incoming connections. 

The malware seeks specific sequences called “magic bytes” to identify backdoor sessions, which it redirects through a Unix socket, thereby concealing its presence from standard security monitoring. Once a connection is established, it communicates with command and control (C2) servers over TLS. The malware cleverly mimics Fortinet’s FortiGate certificate, blending into networks where Fortinet devices are prevalent, to avoid suspicion. This backdoor offers threat actors multiple capabilities to monitor, control, and manipulate the network environment. Through commands from the C2, attackers can remotely open shell access, track network activity, adjust scheduled tasks, or even set up a SOCKS5 proxy, which helps them remain undetected while maintaining control over the network. These actions could allow unauthorized data access or further exploitation, posing significant threats to organizational cybersecurity. 

The NCSC report aligns “Pigmy Goat” with tactics used in “Castletap” malware, which cybersecurity firm Mandiant has linked to Chinese nation-state actors. The report’s insights reinforce concerns over the evolving sophistication in state-sponsored cyber tools aimed at infiltrating critical network infrastructure worldwide. Detection and prevention of “Pigmy Goat” are crucial to mitigating its impact. The NCSC report provides tools for identifying infection, including file hashes, YARA rules, and Snort rules, which can detect specific sequences and fake SSH handshakes associated with the malware. 

Additionally, monitoring for unusual files and behaviours, such as encrypted payloads in ICMP packets or the use of ‘LD_PRELOAD’ within the sshd process, can be effective. These insights empower network defenders to recognize early signs of compromise and respond swiftly, reinforcing defences against this sophisticated threat.

WeChat's Updated Encryption System Prone to Threats for its Users

 




More than a billion people send messages over WeChat and as per a new study recently, it discovered some security flaws in terms of the encryption system. While some applications use end-to-end encryption to prevent secret conversations from being read, WeChat's messages can be viewed by its servers. Researchers now find some vulnerability in WeChat's customised encryption that could leave users vulnerable to threats.


Weakened Encryption in WeChat

Scientists at the Citizen Lab of University of Toronto have established that WeChat is using a variation of the general security protocol named Transport Layer Security, or TLS 1.3. The new version of it is called MMTLS and it is actually made up of another layer of encryption called "Business-layer encryption," which encrypts messages right before they are going to be sent.

While this does mean that there is extra security placed on this system, it does not have weaknesses in the design. The inner Business-layer encryption does not protect critical information, including user IDs and request information. MMTLS also uses predictable patterns of a type of deterministic initialization vectors (IVs) that can lead to compromised encryption security overall.


Missing Forward Secrecy

Another weakness with WeChat's encryption is a lack of "forward secrecy." Forward secrecy helps to secure later communications in cases where old encryption keys are compromised. In the absence of this feature, if the attackers get hold of those encryption keys, they can decrypt old messages, compromising the users' long-term privacy.

Even before 2016, WeChat was employing the Business-layer encryption. This has made WeChat vulnerable to attacks since it had nearly no defences.

With the implementation of MMTLS, security becomes even enhanced with an added layer of protection that is acquired in the process. However, the changes are not yet at extreme conditions expected for the size of users in an app.


Improvements But Still Some Concerns

Though the security has been increased in WeChat, researchers could not break through the encryption layer that is currently used. The new MMTLS layer does hide the older, weaker encryption layer and offers protection from it. Still, the modifications to the protocol of TLS remain a security liability .


Chinese Apps Custom Security Practices

Problems with encryption form part of a broader problem about Chinese apps. Increasingly, app developers in all parts of China do not depend on widely trusted international standards but instead come up with their own custom solutions. For Citizen Lab, this forms a worrisome trend, since their homemade security solutions are nothing close to the generally recognized methods.

For instance, some Chinese apps utilise proprietary processing of DNS hijacking, and many rely on open-source software, as used in the case of Tencent Mars, and thus not all such applications or software will maintain stringent security levels or best practices for security.


WeChat Needs Stronger Encryption

Hence, although WeChat has become far safer lately, it is far from perfect. Users may have weak encryption methods that could expose their private data to possible threats. Such an application with thousands of users worldwide should deploy better standards of encryption to protect conversation among its users.


Domain Validation Bug: DigiCert Revokes TLS Certificates


In a major development in the tech landscape, SSL/TLS certificate provider "DigiCert" recently announced that it will be revoking around 83,267 certificates. This big step was taken due to a bug in their domain validation process, which dented the integrity of the affected certificates. The incident underscores the need for strong domain validation mechanisms and is a prompt reminder of the possible loopholes in cyberspace. 

“Recently, we learned that we did not include the underscore prefix with the random value used in some CNAME-based validation cases. This impacted approximately 0.4% of the applicable domain validations we have in effect. Under strict CABF rules certificates with an issue in their domain validation must be revoked within 24 hours, without exception,” said DigiCert in a statement.

The DigiCert incident

The main reason for the mass revocation exists within DigiCert's Domain Control Validation (DCV) process. The bug contained a missing underscore in the DNS CNAME entry, an important component to verify domain ownership. Due to the oversight, the certificates were issued without validation, undermining their credibility.

Domain validation is a basic step for issuing SSL/TLS certificates, it ensures the legitimacy of the entity requesting the certificate, to check if it's legit or not. In case of failure to validate domain ownership can be a security hazard. This includes man-in-the-middle attacks, where the threat actors intercept and manipulate communication between users and websites.

The impact

The impacted bug resulted in the potential exposure of various websites to security flaws. DigiCert acted promptly to contain the damage, issuing notice to the affected customers and giving a 24-hour wind to reissue certificates. But mass revocation also had repercussions for the affected organizations. Reissuing certificates on such massive scales required constant effort and coordination, especially for businesses with deep digital infrastructures.

Lessons for the future

1. Communications and transparency: DigiCert's swift response to impacted customers was crucial in addressing the bug. Being transparent with your customers becomes paramount, encouraging trust between both parties.

2. Rigorous testing and quality assurance: DigiCert's DCV process bug shows how a minor oversight can cause major disruptions.

3. Proactive, not just preventive measures: An important measure for tracking and addressing flaws before threat actors can exploit them. Frequent audits, auto-testing, and constant monitoring will help.

Microsoft and Google's Approach to Replace Obsolete TLS Protocols

Tech behemoths Microsoft and Google have teamed up to phase out outmoded TLS (Transport Layer Security) protocols in a decisive drive to strengthen online security. TLS protocols are essential for protecting internet connections because they guarantee that data is kept private and unchanged while in transit. Older TLS versions are now vulnerable to attacks as cyber threats advance, which has sparked a move toward more see-cure alternatives.

Microsoft, in a recent announcement, emphasized the importance of migrating away from TLS 1.0 and 1.1. As per their advisory, support for these outdated protocols will be disabled in the upcoming Windows updates. Jeff Jones, Senior Director at Microsoft, stated, "Continued use of these older protocols leaves systems open to numerous known vulnerabilities and attacks." This proactive measure is aimed at safeguarding users against potential security breaches.

Google has echoed this sentiment, highlighting the necessity for a collective industry effort to deprecate obsolete TLS versions. The company has already taken steps towards this goal, gradually phasing out support for TLS 1.0 and 1.1 across its products and services. A spokesperson from Google emphasized, "It's crucial for the entire ecosystem to move towards more secure protocols to ensure a safer online experience for everyone."

The move towards more advanced TLS protocols is a critical step in fortifying cybersecurity in an age of increasingly sophisticated cyber threats. TLS 1.0, introduced over two decades ago, and TLS 1.1, which followed shortly after, have shown their age. Security experts have identified vulnerabilities that make them susceptible to various attacks, including the notorious BEAST and POODLE exploits.

This joint effort by Microsoft and Google serves as a powerful catalyst for industry-wide change. It sends a clear message to developers, businesses, and users alike that embracing modern TLS protocols is essential for maintaining a secure online environment. As the transition gains momentum, organizations are encouraged to update their systems and applications to support TLS 1.2 and 1.3, which offer significantly improved security features.

Microsoft and Google's joint initiative to phase out antiquated TLS protocols represents a big step towards a more secure digital environment. This move not only improves the security of their individual ecosystems but also establishes an important standard for the larger tech community. The adoption of contemporary TLS protocols is a critical step in the direction of evolving defenses against cyber attacks to keep pace with the digital world.




Must Follow Guidelines for API Security

An online store can collect payments via the PayPal API, for instance, rather than developing their own payment gateway. APIs serve the required function while sparing business time and effort, which is why it is evident they are useful. 

Protecting these APIs from security risks and breaches entails securing them together with all linked apps and users. 

APIs are used by businesses to link services and move data. Major data breaches are caused by compromised, broken, or exposed APIs. They make private and delicate financial, medical, and personal information available to the public. However, not all data is created equal, and not all data should be safeguarded in the same way. The type of data being exchanged will determine how you should approach API security. 

In the last 12 months, 95% of firms encountered an API security issue, according to the most recent Salt Labs State of API Security report. Additionally, during the past year, a variety of businesses—including Facebook, Experian, Starbucks, and Peloton—have experienced public API problems. Clearly, APIs need more protection against intrusions than the present crop of application security approaches can provide.

Security leaders need to carefully examine the way they are currently approaching API security to fix the issue. Understanding how a third-party application is sending data back to the internet is important if user API connects to one. 

Strategies for API Security

  1.  Put a secure authentication and authorization protocol into action: The first stage in an API security approach is authenticating and authorizing the appropriate users.
  2. Implement the "Least Privilege" Principle: The attack surface is decreased by restricting access to only essential tasks, which helps reduce the exposure to security breaches.
  3.  Constrain Data Sharing: To find weak spots, keep track of the data shared between apps, APIs, and users, and then secure them by restricting the shared data.
  4. Not utilize HTTPS: In order to communicate data securely, APIs employ HTTP connections and require Secure Sockets Layer (SSL) or Transport Layer Security (TLS) encryption.
  5.  Implement a policy of zero trust: We can leave out the zero-trust policy when discussing API security advice. It operates under the premise that no user, device, or server should be trusted until proven otherwise.
  6. Implement data logging: Logs provide admins with a wealth of information that can be utilized to enhance API security and assist with manual inspection and monitoring.
Security requires ongoing work in the age of technology and the internet. Unfortunately, security problems would not disappear, and as IoT technology grows more widespread, the dangers and vulnerabilities will only become worse. Beware of such ineffective strategies for API security. The security strategy must broaden to keep up with attackers' growing skill sets. 

Being proactive is vital, which means keeping an eye on current technology, patching up any flaws, and implementing cutting-edge cybersecurity measures.

AnchorDNS Loophole of a TrickBot Spyware Upgraded to AnchorMail

 

Even after the TrickBot infrastructure was shut down, the malware's operators continued to improve and retool its arsenal in preparation for attacks which ended in the distribution of the Conti ransomware. The new, improved edition of the criminal gang's AnchorDNS backdoor was called AnchorMail by IBM Security X-Force, which discovered it. 

According to IBM's malware reverse researcher Charlotte Hammond, AnchorMail "uses an email-based [command-and-control] server with which it connects using SMTP and IMAP protocols over TLS." "AnchorMail's behavior is essentially similar to vs its AnchorDNS predecessor, excluding the redesigned C2 communication method." 

The Trickbot Group, also known as ITG23 on X-Force, is a cybercriminal group best known for creating the Trickbot financial Trojan. Originally discovered in 2016, it was used to aid online banking fraud, initially. The gang adapted to the ransomware economy by gaining a footing for ransomware assaults utilizing its Trickbot and Bazarloader payloads, a tight partnership with both the Conti ransomware-as-a-service provider (RaaS). 

ITG23 is also known for creating the Anchor malware framework, which includes the AnchorDNS variant. In 2018 various high-profile targets were being infected with Trickbot or Bazarbackdoor, another ITG23 backdoor. AnchorDNS is known for using the DNS protocol to communicate with its Command and Control (C2) server. The improved backdoor, dubbed AnchorMail or Delegatz by IBM Security X-Force researchers, now communicates with an email-based C2 server through SMTP and IMAP protocols via TLS. AnchorMail's functionality is essentially similar to its AnchorDNS predecessor for most of its part, with the exception of the redesigned C2 communication mechanism. 

The uncovering of this updated Anchor variant adds an extra inconspicuous backdoor during ransomware assaults, demonstrating the group's drive to continually improve its malware. AnchorMail provides a scheduled job for persistence after execution, which is set to execute every 10 minutes. It then gathers basic system data, registers with its C2, and enters a loop of monitoring for and executing commands received. 

The command structure of the backdoor and AnchorDNS appear to be fairly similar, and both forms appear to accept the same set of control codes, which allow a variety of various possibilities for processing orders and payloads received from the C2. The commands include the ability to run binaries, DLLs, and shellcode downloaded from a remote server, as well as launch PowerShell commands and erase themselves from infected PCs. 

"The revelation of this new Anchor version adds a new covert gateway used during ransomware assaults, AnchorMail has only been seen to target Windows PCs so far. However, given the AnchorDNS has been adapted to Linux, a Linux-based version of AnchorMail appears inevitable," said Charlotte Hammond, BM's malware reverse engineer.

SSRF Attacks can be Used to Compromise Java RMI Services

 

According to a detailed analysis of the problem by security researcher Tobias Neitzel, Java RMI services can be targeted using server-side request forgery (SSRF) attacks. Server-side request forgery (SSRF) is a type of attack that allows attackers to send fraudulent requests to other systems by exploiting a vulnerable web server. 

Requests between HTTP servers can be initiated by web applications. These are commonly used to retrieve remote resources such as software updates or to import metadata from a URL or another web application. Such inter-server requests are not inherently harmful, but if not performed correctly, they can expose a server to server-side request forgery. When user-controllable data is utilized to construct the target URL, an SSRF vulnerability is introduced. An attacker can then use an SSRF attack to initiate or control requests from the vulnerable server by changing a parameter value in the vulnerable web application.

Java RMI is an object-oriented Remote Procedure Call (RPC) mechanism that is included in the vast majority of Java installations. The technology can be used by software developers to make functionality available through a network. Java RMI relies on serialized Java objects for communication, a mechanism that attackers can exploit despite the fact that the technology has been hardened and tempered in recent years, according to Neitzel.

“As with all SSRF techniques, the major problem is that attackers may be able to attack RMI services that are supposed to only be accessed from trusted networks,” Neitzel explained. “Securing RMI properly is not that intuitive and there is a lot of hidden attack surface. Instead of configuring it properly, administrators often take the easy route and only allow access from trusted networks or clients.” 

JMX is the most often utilized RMI service. Neitzel demonstrated that SSRF can be used to compromise a backend JMX service, but only if the system delivers responses from the backend service and accepts arbitrary bytes inside them. Similarly, SSRF-based attacks on default RMI components like the RMI registry are conceivable, but only if the system enables arbitrary bytes to be delivered to the backend service. 

The German researcher goes on to list security best practices and counter-measures for RMI services against potential attacks in his blog post. These include enabling TLS-enabled communication for all RMI endpoints, employing deserialization filters, and implementing stricter authentication controls.

Google Voice Disruption Caused by Expired TLS Certificates

 

Google has affirmed that a Google Voice malfunction that had impacted the majority of telephone service users this month was triggered, in an incident report released on Friday, by expired TLS certificates. It stopped most of Google Voice users from signing into their accounts and allowing more than four hours of use of the app between 15 February and 16 February 2021. 

Google Voice is a Google voicemail service that allows users to send free texts, personalize the voicemail, read text transcripts for voicemail, and much more. The voicemail service of Google, which previously required a Google Voice invitation code for installation, is now free of charge available for all Gmail users. 

The incident report states that, "Google Voice users experienced an issue in which some new inbound or outbound Voice over Internet Protocol (VoIP) calls failed to connect, for a total duration of 4hours 22 minutes." 

In order to manage phone calls over the Internet protocol, Google Voice uses the Initiation Session Protocol (SIP). Google Voice consumer devices aim at ensuring a continuous SIP link with Google Voice services during routine operation. The customer tries to regain contact automatically after a link fails. Transport Layer Security (TLS) certificates are also rotated periodically to ensure that all Google Voice traffic is protected and linked. 

"Due to an issue with updating certificate configurations, the active certificate in Google Voice frontend systems inadvertently expired at 2021-02-15 23:51:00, triggering the issue," Google explained. "During the impact period, any clients attempting to establish or re-establish a SIP connection were unable to do so." 

Users could not access the Google Voice platform to make or accept VoIP calls following the breakdown of expired certificates. However, consumer systems with an active SIP connection were not impacted during the outage before this incident (as long as the connection was not interrupted). The technical team concluded after the analysis that the root cause was certificate configuration. The team has developed and initiated an emergency roll-out of modified credentials and configuration information to interfaces. After mitigation was enforced, the functionality of Google Voice SIP customers restored retrieval of their connections.

Publishing the incident report, the Google Workspace Team stated the steps taken by the engineers. They insisted on, setting additional constructive warnings for credential expiry incidents to come, and set up additional reactive warnings in Google Voice frontend applications for TLS errors. Alongside, enhance automatic credential rotation tooling and changes to set up and to allow the quick rollout of configuration improvements, utilizing more portable facilities. Developing emergency roll-out testing and practice examples with Google Voice interface applications and settings.

Google is committed to improving our technology and operations efficiently and consistently to avoid service disruptions. They said that “We thank your patience and excuse your company for any effects. For your company, we appreciate you.”

NSA Issues Guidelines for Eliminating Obsolete TLS Protocols

 

The National Security Agency is a US-based agency on which America highly relies on to collect and process foreign signals, understand them and share them with US Officials, and to take any action against dubious acts. These signals are not comprehensible by common men instead a team of mathematicians, technical experts, or analysts is required to decode the encrypted signals to comprehensible format. 

The NSA has distinctly recommended replacing antiquated protocols configuration of TLS (Transport Layer Security). This has been done because of the obsolete protocols that were harming the sensitive information of those using it. With time new deleterious dimensions of the TLS authentication and configuration have been discovered by the NSA. Such flaws are not acceptable as they breach the wall of privacy between the client and the server by incapacitating the encrypted data that is easily accessible by the hackers. 

The exchange of communication between the server and the client is sensitive information and valuable data that needs protection and for this purpose, strong protection channels and electronic systems like TLS and Secure Sockets Layer (SSL) were developed. 

Considering TLS, it’s a protocol to secure communication between the client and the server. It uses encrypted signals and authentication to protect the information. Nevertheless recently some new attacks against TLS and its authentication have been discovered. Network connections employing obsolete protocols are at an elevated risk of exploitation by the opponents. For the aforementioned sitch, the NSA has issued strict guidelines that need to be enforced as soon as possible. They claimed that the obsolete and incapacitated TLS protocol implementation was being observed recently, which is a threat to the country’s intelligence. Furthermore, they stated, “nation-state of sufficiently resourced actors are able to exploit these weak communications”. 

As a solution, the NSA recommended that only TLS 1.2 and TLS 1.3 should be used and that SSL 2.O , SSL 3.0 , TLS 1.0, and YLS 1.1 should not be used. They said that all the TLS implementations should be up to date and configuration should be in accordance with the CNSS and NIST guidelines. 

NSA urged the public to follow the guidelines and implement the new TLS protocol as they are familiar with the dangerous consequences of using obsolete encryptions which includes delivering a false feeling of security because of a distorted sense of trust we have in the functioning of the system. However, updating the TLS protocols and configuration will be in our best interests as it will now provide stronger encryption and authentication.