Search This Blog
Powered by Blogger.

Blog Archive

Labels

Load More
Trendy Right Now

Popular Posts

Showing posts with label TLS. Show all posts
Unauthorized access
Cyber Security Data Privacy Google Microsoft Phishing Attacks Protocol Spoofing TLS Unauthorized access

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.




Read more »
User Privacy
API Cyber Crime HTTP Attacks IoT Logs SSL TLS User Privacy

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.
Read more »
TrickBot
BazarLoader Conti Ransomware DNS Flaw IMAP Linux malware PowerShell RaaS TLS TrickBot

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.
Read more »
vulnerable servers
Cyber Attacks Java SSRF TLS vulnerable servers

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.
Read more »
VoIP
Google Google Voice Technology TLS VoIP

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.”
Read more »
TLS
Cyber Security encrypted NSA Protocol TLS

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. 
Read more »
Subscribe to: Posts (Atom)