Search This Blog

Showing posts with label Credentials Leak. Show all posts

Japanese City Worker Loses USB Containing Resident's Personal Data

 

A Japanese city has been compelled to apologise after a contractor admitted to losing a USB memory stick holding the personal data of over 500,000 inhabitants following an alcohol-fueled night out. 

Amagasaki, western Japan, officials claimed the man – an unidentified employee of a private contractor hired to administer Covid-19 compensation payments to local homes – had taken the flash drive from the city's offices to transfer the data to a contact centre in neighbouring Osaka. 

After spending Tuesday evening drinking at a restaurant, he realised on his way home that the bag holding the drive, as well as the personal information of all 460,000 Amagasaki residents, had gone missing. The next morning, he reported the loss to the police. 

According to the Asahi Shimbun, the information contained the residents' names, residences, and dates of birth, as well as data on their residence tax payments and the bank account numbers of those receiving child benefits and other welfare payments. There have been no complaints of data leaks because all of the information is encrypted and password secured. 

“We deeply regret that we have profoundly harmed the public’s trust in the administration of the city,” an Amagasaki official told reporters. The city told in a statement that it would “ensure security management when handling electronic data. We will work to regain our residents’ trust by heightening awareness of the importance of protecting personal information.” 

Not a new affair 

Last month, a man in Abu was handed £279,000/US$343,000 in Covid-19 relief payments meant for 463 low-income people. Local officials said this week that they had recovered all of the money via internet payment services after the individual claimed he had gambled it all away. 

The Amagasaki event highlights worries about some Japanese organisations' ongoing usage of obsolete technologies. According to media reports last week, dozens of businesses and government agencies were rushing to transition away from Internet Explorer before Microsoft retired the browser at midnight on Wednesday. 

According to Nikkei Asia, a sense of "panic" seized businesses and government organisations who were slow to abandon their dependency on IE before Microsoft formally ceased support services, leaving surviving users susceptible to flaws and hacks.

Misconfigured Apache Airflow Servers Expose Thousands of Credentials

 

Researchers from the security firm Intezer uncovered a slew of misconfigured Apache Airflow servers that were exposing sensitive information, including credentials, from a number of IT organizations. 

Apache Airflow is an open-source workflow management software that is used by numerous businesses across the world to automate business and IT activities. 

The post published by Intezer stated, “These unsecured instances expose sensitive information of companies across the media, finance, manufacturing, information technology (IT), biotech, e-commerce, health, energy, cybersecurity, and transportation industries. In the vulnerable Airflows, we see exposed credentials for popular platforms and services such as Slack, PayPal, AWS and more.” 

Researchers examined the dangers of misconfiguration for companies and their customers, as well as the most frequent reasons for data leakage from vulnerable cases. According to Intezer researchers, the majority of the stolen credentials are disclosed due to unsafe coding techniques, with many of the compromised instances having hardcoded passwords inside the Python DAG Code. 

Other misconfigured installations examined by Intezer included a publicly available configuration file (airflow.cfg) containing confidential information such as passwords and keys. 

Malicious actors may potentially alter the settings, resulting in unforeseen behaviour. Other misconfigured installations examined by Intezer included a publicly available configuration file (airflow.cfg) containing confidential information such as passwords and keys.  

Threat actors may also alter the settings, resulting in unforeseen behaviour. The credentials might likewise be exposed via the Airflow "variables" used in DAG scripts. 

As per experts,  it is quite common to find hardcoded passwords stored in these variables. Threat actors could also exploit Airflow plugins or features to execute malware that could be injected into variables. 

“There is also the possibility that Airflow plugins or features can be abused to run malicious code. An example of how an attacker can abuse a native “Variables” feature in Airflow is if any code or images placed in the variables form is used to build evaluated code strings.” 

“Variables are able to be edited by any visiting user which means that malicious code could be injected. One entity we observed was using variables to store internal container image names to execute. These container image variables could be edited and swapped out with an image containing and running unauthorized or malicious code.” 

The research focused on earlier versions of Apache Airflow and emphasised the hazards associated with using out-of-date software. The majority of the problems highlighted in the study were affected servers using Airflow v1.x; however, subsequent versions of Airflow incorporate security measures that address the aforementioned concerns. 

“In light of the major changes made in version 2, it is strongly recommended to update the version of all Airflow instances to the latest version. Make sure that only authorized users can connect.” concludes the report. “Exposing customer information can also lead to violation of data protection laws and the possibility of legal action.” 

The security firm advised, "Disruption of clients' operations through poor cybersecurity practices can also result in legal action such as class action lawsuits."

Mozilla: Maximum Breached Accounts had Superhero and Disney Princes Names as Passwords

 

The passwords that we make for our accounts are very similar to a house key used to lock the house. The password protects the online home (account) of personal information, thus possessing an extremely strong password is just like employing a superhero in a battle of heroes and villains. 

However, according to a new blog post by Mozilla, superhero-themed passwords are progressively popping up in data breaches. Though it may sound absurd - following the research done by Mozilla using the data from haveibeenpwned.com, it was evident that most frequent passwords discovered in data breaches were created on either the names of superheroes or Disney princesses. Such obvious passwords make it easier for hackers to attack and hijack any account or system. 

While analyzing the data it was seen that 368,397 breaches included Superman, 226,327 breaches included Batman, and 160,030 breaches had Spider-Man as their passwords. Further, thousands of breaches featured Wolverine and Ironman as well. And not only this research from 2019 showed that 192,023 breached included Jasmine and 49,763 breached included Aurora as their password.

There were 484,4765 breached that had password as ‘princess’ and some Disney + accounts had password as ‘Disney’. This is one of the biggest reasons that support data breaches by hackers and boost their confidence.

With the increasing frequency of compromised account credentials on the dark web, a growing number of businesses are turning to password-less solutions. Microsoft has expanded its password-less sign-in option from Azure Active Directory (AAD) commercial clients to use Microsoft accounts on Windows 10 and Windows 11 PCs. 

Almost all of Microsoft's employees are passwordless, according to Vasu Jakkal, corporate vice president of the Microsoft Security, Compliance, Identity, and Management group.

"We use Windows Hello and biometrics. Microsoft already has 200 million passwords fewer customers across consumer and enterprise," Jakkal said. "We are going completely passwordless for Microsoft accounts. So you don't need a password at all," he further added. 

Though it's common to reuse passwords, it is highly dangerous, yet it's all too frequently because it's simple and people aren't aware of the consequences. Credential stuffing exploits take advantage of repeated passwords by automating login attempts targeting systems utilizing well-known email addresses and password pairings. One must keep changing their passwords from time to time and try to create a strong yet not so obvious password.

Exchange/Outlook Autodiscover Bug Exposed $100K Email Passwords

 

Guardicore Security Researcher, Amit Serper identified a critical vulnerability in Microsoft's autodiscover- the protocol, which permits for the automatic setup of an email account with only the address and password needed. 

The vulnerability allows attackers who buy domains containing the word "autodiscover," such as autodiscover.com or autodiscover.co.uk, to capture the clear-text login details of users experiencing network issues (or whose admins incorrectly configured DNS). 

From April 16 through August 25 of this year, Guardicore purchased many similar domains and used them as proof-of-concept credential traps: 
  •  Autodiscover.com.br 
  •  Autodiscover.com.cn 
  •  Autodiscover.com.co 
  •  Autodiscover.es 
  •  Autodiscover.fr 
  •  Autodiscover.in 
  •  Autodiscover.it 
  •  Autodiscover.sg 
  •  Autodiscover.uk 
  •  Autodiscover.xyz 
  •  Autodiscover.online 
A web server linked to these domains got hundreds of thousands of email credentials in clear text, most of which also operated as Windows Active Directory domain credentials. 

The credentials are sent from clients who request the URL /Autodiscover/autodiscover.xml with an HTTP Basic authentication header that already contains the unfortunate user's Base64-encoded credentials. 

The various factors contribute to the overall vulnerability like; the Autodiscover protocol's "backoff and escalate" behaviour when authentication fails, its failure to check Autodiscover servers before giving up user credentials, and its readiness to utilise insecure methods such as HTTP Basic in the first place. 

Failing upward with Autodiscover 

The main task of the Autodiscover protocol is to simplify account configuration—one can depend on a normal user to memorise their email address and password, but years of computing have imparted us that asking them to remember and correctly enter details like POP3 or IMAP4, TLS or SSL, TCP 465 or TCP 587, and the addresses of actual mail servers is several bridges too far. 

By keeping all nonprivate elements of account information on publicly available servers, the Autodiscover protocol enables regular users to configure their own email accounts without assistance. 

When the user creates an Exchange account in Outlook, they provide an email address and a password, such as bob@example.com with password Hunter2. With the user's email address in hand, Autodiscover searches for configuration information in a published XML document. It will attempt HTTP and HTTPS connections to the URLs listed below: (Note: contoso is a Microsoftism that refers to a hypothetical domain name rather than a specific domain.)

http(s)://Autodiscover.example.contoso.com/Autodiscover/Autodiscover.xml http(s)://example.contoso.com/Autodiscover/Autodiscover.xml 

Thus so far, it can be fairly believed that anyone permitted to store resources on example.contoso.com or its Autodiscover subdomain has been given explicit trust by the owner of example.contoso.com. 

However, if these initial connection attempts fail, Autodiscover will back off and attempt to locate resources in a higher-level domain. In this case, Autodiscover would seek for /Autodiscover/Autodiscover.xml on both contoso.com and Autodiscover.contoso.com. 

If this fails, Autodiscover will attempt to submit email and password information to autodiscover.com itself. It would be terrible enough if Microsoft controlled autodiscover.com, but the truth is far more complicated. That domain was registered in 2002 and is now held by an unknown individual or organization that is utilizing GoDaddy's WHOIS privacy shield. 

Guardicore’s Analysis 

Guardicore acquired 96,671 distinct sets of email usernames and passwords in clear text over four months while running its test credential trap. These credentials were obtained from a diverse range of businesses, including publicly listed firms, manufacturers, banks, electricity companies, and others. 

When the Autodiscover protocol fails up from Autodiscover.contoso.com.br to Autodiscover.com.br, the security offered by Contoso's ownership of its own SSL cert disappears. Whoever purchased Autodiscover.com.br—in this scenario, Guardicore—merely supplies their own certificate, which fulfills TLS warnings despite not being associated with Contoso at all. 

In many situations, Outlook or a similar client will initially present its user's credentials in a more secure format, such as NTLM. 

Unfortunately, a simple HTTP 401 from the webserver requesting HTTP Basic auth in its place is all that is required, to which the client using Autodiscover will abide (typically without error or warning to the user) and send the credentials in Base64 encoded plain text, completely readable by the web server responding to the Autodiscover request.

Conclusion 
The truly terrible news is that there is no mitigation solution for this Autodiscover issue available to the general public.

If your company's Autodiscover infrastructure has a bad day, your client will "fail upward," possibly revealing your credentials. This issue has yet to be patched; according to Microsoft Senior Director Jeff Jones, Guardicore publicly revealed the flaw before reporting it to Microsoft. 

But Guardicore did offer these protective measures:
  • Make sure that you are actively blocking Autodiscover. domains (such as Autodiscover.com/Autodiscover.com.cn, etc) in your firewall. 
  • When deploying/configuring Exchange setups, make sure that support for basic authentication is disabled – using HTTP basic authentication is the same as sending a password in clear text over the wire.
  • A comprehensive-textual list of all top-level domains can be found in the following url: https://data.iana.org/TLD/tlds-alpha-by-domain.txt 
For developers and vendors, the company offered this tip: 

Make sure that when you are implementing the Autodiscover protocol in your product you are not letting it “fail upwards”, meaning that domains such as “Autodiscover.” should never be constructed by the “back-off” algorithm.