In three years or so, the Wi-Fi specification is scheduled to get an upgrade that will turn wireless devices into sensors capable of gathering data about the people and objects bathed in their signals.
“When 802.11bf will be finalized and introduced as an IEEE standard in September 2024, Wi-Fi will cease to be a communication-only standard and will legitimately become a full-fledged sensing paradigm,” explains Francesco Restuccia, assistant professor of electrical and computer engineering at Northeastern University, in a paper summarizing the state of the Wi-Fi Sensing project (SENS) currently being developed by the Institute of Electrical and Electronics Engineers (IEEE).
SENS is envisioned as a way for devices capable of sending and receiving wireless data to use Wi-Fi signal interference differences to measure the range, velocity, direction, motion, presence, and proximity of people and objects.
It may come as no surprise that the security and privacy considerations of Wi-Fi-based sensing have not received much attention.
As Restuccia warns in his paper, “As yet, research and development efforts have been focused on improving the classification accuracy of the phenomena being monitored, with little regard to S&P [security and privacy] issues. While this could be acceptable from a research perspective, we point out that to allow widespread adoption of 802.11bf, ordinary people need to trust its underlying technologies. Therefore, S&P guarantees must be provided to the end users.”
[…]
“Indeed, it has been shown that SENS-based classifiers can infer privacy-critical information such as keyboard typing, gesture recognition and activity tracking,” Restuccia explains. “Given the broadcast nature of the wireless channel, a malicious eavesdropper could easily ‘listen’ to CSI [Channel State Information] reports and track the user’s activity without authorization.”
And worse still, he argues, such tracking can be done surreptitiously because Wi-Fi signals can penetrate walls, don’t require light, and don’t offer any visible indicator of their presence.
Restuccia suggests there needs to be a way to opt-out of SENS-based surveillance; a more privacy-friendly stance would be to opt-in, but there’s not much precedent for seeking permission in the technology industry.
News that Ubiquiti’s cloud servers had been breached emerged on January 11, 2021, when the company emailed customers the text found in this support forum post. That missive stated: “We recently became aware of unauthorized access to certain of our information technology systems hosted by a third-party cloud provider.”
That announcement continued, “We have no indication that there has been unauthorized activity with respect to any user’s account,” but also recommended customers change their passwords because if their records had been accessed, hashed and salted passwords, email addresses, and even physical addresses and phone numbers could be at risk.
An update on Wednesday this week stated an investigation by outside experts “identified no evidence that customer information was accessed, or even targeted,” however.
Crucially, the update also revealed that someone “unsuccessfully attempted to extort the company by threatening to release stolen source code and specific IT credentials.” The update does not suggest the extortion attempt was fanciful.
Ubiquiti has not said when the external experts decided customer data was untouched. Which leaves the company in the interesting position of perhaps knowing its core IP has leaked, and not disclosing that, while also knowing that customer data is safe and not disclosing that, either.
The update contains another scary nugget in this sentence: “Please note that nothing has changed with respect to our analysis of customer data and the security of our products since our notification on January 11.”
But the January 11 notification makes no mention of “the security of our products.”
The update on Wednesday was published two days after Krebs On Securityreported that it has seen a letter from a whistleblower to the European Data Protection Supervisor that alleges Ubiquiti has not told the whole truth about the incident.
Krebs said the letter described the attack on Ubiquiti as “catastrophically worse than reported.”
“The breach was massive, customer data was at risk, access to customers’ devices deployed in corporations and homes around the world was at risk,” the letter reportedly claimed, adding that Ubiquiti’s legal team “silenced and overruled efforts to decisively protect customers.”
The whistleblower separately claimed that whoever was able to break into Ubiquiti’s Amazon-hosted servers, they could have swiped cryptographic secrets for customers’ single sign-on cookies and remote device access, internal source code, and signing keys – far more than the Wi-Fi box maker disclosed in January. The intruder, it is said, obtained a Ubiquiti IT worker’s privileged credentials, got root access to the business’s AWS systems, and thus had a potential free run of its cloud-hosted storage and databases.
Backdoors were apparently stashed in the servers, too, and, as Ubiquiti acknowledged this week, a ransom was demanded to keep quiet about the break-in.
[…]
The update ends with another call for customers to refresh their passwords and enable two-factor authentication. The Register fancies some readers may also consider refreshing their Wi-Fi supplier. ®
PS: It’s not been a great week for Ubiquiti: it just promised to remove house ads it added to the web-based user interface of its UniFi gear.
OpenSSL, the most widely used software library for implementing website and email encryption, has patched a high-severity vulnerability that makes it easy for hackers to completely shut down huge numbers of servers.
[…]
On Thursday, OpenSSL maintainers disclosed and patched a vulnerability that causes servers to crash when they receive a maliciously crafted request from an unauthenticated end user. CVE-2021-3449, as the denial-of-server vulnerability is tracked, is the result of a null pointer dereference bug. Cryptographic engineer Filippo Valsorda said on Twitter that the flaw could probably have been discovered earlier than now.
“Anyway, sounds like you can crash most OpenSSL servers on the Internet today,” he added.
Hackers can exploit the vulnerability by sending a server a maliciously formed renegotiating request during the initial handshake that establishes a secure connection between an end user and a server.
“An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client,” maintainers wrote in an advisory. “If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack.”
The maintainers have rated the severity high. Researchers reported the vulnerability to OpenSSL on March 17. Nokia developers Peter Kästle and Samuel Sapalski provided the fix.
Certificate verification bypass
OpenSSL also fixed a separate vulnerability that, in edge cases, prevented apps from detecting and rejecting TLS certificates that aren’t digitally signed by a browser-trusted certificate authority. The vulnerability, tracked as CVE-2021-3450, involves the interplay between a X509_V_FLAG_X509_STRICT flag found in the code and several parameters.
Thursday’s advisory explained:
If a “purpose” has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named “purpose” values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application.
In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose.
Working from home, whether as a permanent option or as part of hybrid models, may become standard, and so the corporate world needs to consider how best to keep their networks protected whilst also catering to a remote workforce.
To this end, Cloudflare has contributed a new zero-trust solution for browser sessions. On Tuesday, the web security firm launched Cloudflare Browser Isolation, software that creates a “gap” between browsers and end-user devices in the interests of safety.
Instead of employees launching local browser sessions to access work-related resources or collaborative tools, the service runs the original, requested web page in the cloud and streams a replica to the end-user.
Cloudflare says that tapping into the firm’s global network to run browser sessions circumvents the usual speed downgrades and potential lag caused by typical, pixel-based streaming.
As there is no direct browser link, this can mitigate the risk of exploits, phishing, and cyberattacks. In addition, Cloudflare automatically blocks high-risk websites based on existing threat intelligence.
The solution has now been made available through Cloudflare for Teams.
Data of visitors to Diergaarde Blijdorp, Apenheul, Dierenpark Amersfoort and dozens of other theme parks are on the street. Ticket seller Ticketcounter is also extorted for 3 tons.
An employee accidentally posted data online where they didn’t have to. As a result, the data could be found there for months (from 5 August 2020 to 22 February 2021). The data is then offered for sale on the dark web.
This mainly concerns data of people who have purchased day tickets via the website.
It turns out they kept all this data they shouldn’t have.
The database contained the data of 1.5 million people who had purchased a ticket through Ticketcounter. These include their names, email addresses, telephone numbers, dates of birth and address details. If people with iDEAL have paid for their entrance ticket, their bank account number (IBAN) has also fallen into the wrong hands.
Why did they keep all this data? And why wasn’t it encrypted?
It was leaked when someone made a backup which a) wasn’t encrypted and b) was placed somewhere stunningly easy to find. Now they are being extorted to the tune of 7 BTC which they are not planning to give.
Ticketcounter makes it sound like they are some kind of victim in this but their security practices are abysmal and hopefully they will be fined a serious amount.
A serious flaw in Zoom’s Keybase secure chat application left copies of images contained in secure communications on Keybase users’ computers after they were supposedly deleted.
A security researcher has recommended against using the LastPass password manager Android app after noting seven embedded trackers. The software’s maker says users can opt out if they want.
[…]
The Exodus report on LastPass shows seven trackers in the Android app, including four from Google for the purpose of analytics and crash reporting, as well as others from AppsFlyer, MixPanel, and Segment. Segment, for instance, gathers data for marketing teams, and claims to offer a “single view of the customer”, profiling users and connecting their activity across different platforms, presumably for tailored adverts.
LastPass has many free users – is it a problem if its owner seeks to monetise them in some way? Kuketz said it is. Typically, the way trackers like this work is that the developer compiles code from the tracking provider into their application. The gathered information can be used to build up a profile of the user’s interests from their activities, and target them with ads.
Even the app developers do not know what data is collected and transmitted to the third-party providers, said Kuketz, and the integration of proprietary code could introduce security risks and unexpected behaviour, as well as being a privacy risk. These things do not belong in password managers, which are security-critical, he said.
Kuketz also investigated what data is transmitted by inspecting the network traffic. He found that this included details about the device being used, the mobile operator, the type of LastPass account, the Google Advertising ID (which can connect data about the user across different apps). During use, the data also shows when new passwords are created and what type they are. Kuketz did not suggest that actual passwords or usernames are transmitted, but did note the absence of any opt-out dialogs, or information for the user about the data being sent to third parties. In his view, the presence of the trackers demonstrates a suboptimal attitude to security. Kuketz recommended changing to a different password manager, such as the open-source KeePass.
Do all password apps contain such trackers? Not according to Exodus. 1Password has none. KeePass has none. The open-source Bitwarden has two for Google Firebase analytics and Microsoft Visual Studio crash reporting. Dashlane has four. LastPass does appear to have more than its rivals. And yes, lots of smartphone apps have trackers: today, we’re talking about LastPass.
[…]
“All LastPass users, regardless of browser or device, are given the option to opt-out of these analytics in their LastPass Privacy Settings, located in their account here: Account Settings > Show Advanced Settings > Privacy.
Looking for this option was definitely not easy to find.
I just bought a year’s subscription as I thought the $2.11 / month price point was OK. They added on a few cents and then told me this price was excl VAT. Not doing very well on the trustworthyness scale here.
Here in France, we’ve just experienced the country’s biggest ever data breach of customer records, involving some half a million medical patients. Worse, the data wasn’t even sold or held to ransom by dark web criminals: it was just given away so that anyone could download it.
Up to 60 fields of personal data per patient are now blowing around in the internet winds. Full name, address, email, mobile phone number, date of birth, social security number, blood group, prescribing doctor, reason for consultation (such as “pregnancy”, “brain tumour”, “deaf”, “HIV positive”) and so on – it’s all there, detailed across 491,840 lines of plain text.
Data journalism couldn’t be easier, and indeed the newspaper hacks have been on the beat, contacting the doctors listed in the file and phoning up some of the patients on their mobile numbers to ask how they feel about the data breach. The doctors knew nothing about it, and of course the patients whose personal info had been stolen – including Hervé Morin, ex-Minister of Defence, as it turns out – hadn’t the faintest idea.
According to an investigation by daily newspaper Libération, warning signs that something was afoot were first reported on 12 February in a blog by Damien Bancal at security outfit Zataz. Some dark web spivs began discussing in Turkish-language channels on Telegram about how to sell some medical records stolen from a French hospital. Some of them then tried independently to put the data on the market and got into an argument that spilled over into Russian-language channels.
One of them, it seems, got pissed off and decided to take revenge by posting an extract of the data publicly. This was rapidly spread around Telegram’s other lesser spivlet channels and soon afterwards ended up being shared on conventional social media.
A closer look at the file reveals that it didn’t come from a hospital after all. It turns out the various dates on the patient records refer not to doctors’ appointments but to when patients had to submit a test specimen: in other words, the data is likely to have been stolen from French bio-medical laboratories conducting the specimen analysis.
Further probing by Libé revealed that the hack may relate to data stored using a system called Mega-Bus from Medasys, a company since absorbed into Dedalus France. Dating back to 2009, Mega-Bus hasn’t been updated and laboratories have been abandoning it for other solutions over the last couple of years. No patient records entered into these newer systems can be found in the stolen file, only pre-upgrade stuff entered into Mega-Bus, apparently.
Whether you’re looking to make a change in your password management just because, or you’re a LastPass user annoyed with the service’s recent changes to its free tier, switching to the much-loved (and free) Bitwarden service is a good choice. Bitwarden is now the best free password manager for most people—since it works across all of your devices to add convenience and security to your logins—and setting it up is quick and easy.
To get started, head to Bitwarden’s site and create an account. It’s free to do, and all you need to worry about is giving yourself a solid master password. Make it a good one, and one that you don’t use anywhere else, because it’ll be one of the gatekeepers for all of your other passwords that you’ll store on the service. Once you’ve created your account and logged in, make sure you verify your email address using the option in the upper-right corner.
As the U.S. continues to chart the damage from the sweeping “SolarWinds” hack, France has announced that it too has suffered a large supply chain cyberattack. The news comes via a recently released technical report published by the Agence Nationale de la sécurité des systèmes d’information—or simply ANSSI—the French government’s chief cybersecurity agency. Like the U.S., French authorities have implied that Russia is probably involved.According to ANSSI, a sophisticated hacker group has successfully penetrated the Centreon Systems products, a French IT firm specializing in network and system monitoring that is used by many French government agencies, as well as some of the nation’s biggest companies (Air France, among others). Centreon’s client page shows that it partners with the French Department of Justice, Ecole Polytechnique, and regional public agencies, as well as some of the nation’s largest agri-food production firms.Illustration for article titled France Just Suffered a SolarWinds-Style CyberattackThe SolarWinds Hack Just Keeps Getting More WildNow the Chinese are involved. That’s one of the newest allegations to emerge in the SolarWinds…Read moreWhile ANSSI did not officially attribute the hack to any organization, the agency says the techniques used bear similarities to those of the Russian military hacker group “Sandworm” (also known as Unit 74455). The intrusion campaign, which dates back at least to 2017, allowed the hackers to breach the systems of a number of French organizations, though ANSSI has declined to name the victims or say how many were affected.
Now that Apple has officially begun the transition to Apple Silicon, so has malware.
Security researcher Patrick Wardle published a blog detailing that he’d found a malicious program dubbed GoSearch22, a Safari browser extension that’s been reworked for Apple’s M1 processor. (The extension is a variant of the Pirrit adware family, which is notorious on Macs.) Meanwhile, a new report from Wired also quotes other security researchers as finding other, distinct instances of native M1 malware from Wardle’s findings.
The GoSearch22 malware was signed with an Apple developer ID on Nov. 23, 2020—not long after the first M1 laptops were first unveiled. Having a developer ID means a user downloading the malware wouldn’t trigger Gatekeeper on macOS, which notifies users when an application they’re about to download may not be safe. Developers can take the extra step of submitting apps to Apple to be notarized for extra confirmation. However, Wardle notes in his writeup that it’s unclear whether Apple ever notarized the code, as the certificate for GoSearch22 has since been revoked. Unfortunately, he also writes that since this malware was detected in the wild, regardless of whether Apple notarized it, “macOS users were infected.”
Personal information of more than 243 million Brazilians was exposed for more than six months thanks to weakly encoded credentials stored in the source code of the Brazilian Ministry of Health’s website. The data leak exposed both living and deceased Brazilians’ medical records to possible unauthorized access. The incident was the second reported by Brazilian publication Estadão and among several others recently affecting South America’s largest nation’s healthcare system.
Sistema Único de Saúde data leak exposed patients’ medical records
For more than six months, personal data belonging to anyone registered with Sistema Único de Saúde (SUS), Brazil’s national health system, could be viewed.
The data leak exposed people’s full names, addresses, phone numbers, and full medical records of Brazilians that signed up for the government’s public-funded healthcare system.
Approximately 32 million medical records belonged to deceased Brazilians, given that the country’s population was 211 million in 2019.
The database login credentials were encoded using Base64 encoding, which could be easily decoded. Anybody could have viewed the website’s source code and the database credentials using the F12 keyboard shortcut or the “View Source Code” option from the browser’s menu.
Subsequently, the exposed database logins could have allowed anybody access to Brazilians’ medical records.
Just last month, Estadão also reported another data leak exposing more than 16 million Brazilian COVID-19 patients’ medical records. The breach occurred after an employee uploaded on GitHub a spreadsheet containing usernames, passwords, and the E-SUS-VE system access keys.
German software designer Jonas Strehle has published a proof of concept on GitHub that he says demonstrates a method in which the favicon’s cache can be used to store a unique identifier for a user that is readable “in the browser’s incognito mode and is not cleared by flushing the cache, closing the browser or restarting the system, using a VPN or installing AdBlockers.”As Motherboard points out, Strehle started building the project after reading a research paper from the University of Illinois at Chicago that describes the technique. The basic gist of the method starts with the fact that favicon’s get cached in your browser the first time you visit a website. When you return to the site, the browser checks to see if the favicon has been stored in its own special home on your machine that’s called the F-Cache. If the data is out of date or missing, the browser requests data from the website’s servers. Strehle explained what happens next in a write up on his website: A web server can draw conclusions about whether a browser has already loaded a favicon or not: So when the browser requests a web page, if the favicon is not in the local F-cache, another request for the favicon is made. If the icon already exists in the F-Cache, no further request is sent. By combining the state of delivered and not delivered favicons for specific URL paths for a browser, a unique pattern (identification number) can be assigned to the client. When the website is reloaded, the web server can reconstruct the identification number with the network requests sent by the client for the missing favicons and thus identify the browser.
Mozilla has released Firefox 85 ending support for Adobe Flash Player plugin and has brought in ways to block supercookies to enhance a user’s privacy. Mozilla, in a blog post, noted that supercookies are store user identifiers, and are much more difficult to delete and block. It further noted that the changes it is making through network partitioning in Firefox 85 will “reduce the effectiveness of cache-based supercookies by eliminating a tracker’s ability to use them across websites.”
“Trackers can abuse caches to create supercookies and can use connection identifiers to track users. But by isolating caches and network connections to the website they were created on, we make them useless for cross-site tracking,” Mozilla noted.
It explained that the network partitioning works by splitting the Firefox browser cache on a per-website basis, a technical solution that prevents websites from tracking users as they move across the web. Mozilla also noted that by removing support for Flash, there was not much impact on the page load time. The development was first reported by ZDNet.
Do you have an iPhone or iPad? You should update your device right now to iOS 14.4. No, not later today or after lunch or whatever. Update now.Why is it so crucial to update your iOS software as soon as possible? As TechCrunch first reported, Apple is reporting three security vulnerabilities that “may have been actively exploited” by hackers.We don’t have any real details yet, but Apple rarely has to admit such stunning vulnerabilities. The researchers who reported the security flaws have been granted anonymity by Apple.As Apple explains: Kernel Available for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation) Impact: A malicious application may be able to elevate privileges. Apple is aware of a report that this issue may have been actively exploited. Description: A race condition was addressed with improved locking. CVE-2021-1782: an anonymous researcher WebKit Available for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation) Impact: A remote attacker may be able to cause arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited. Description: A logic issue was addressed with improved restrictions. CVE-2021-1871: an anonymous researcher CVE-2021-1870: an anonymous researcher
Security researchers from Qualys have identified a critical heap buffer overflow vulnerability in sudo that can be exploited by rogue users to take over the host system.
Sudo is an open-source command-line utility widely used on Linux and other Unix-flavored operating systems. It is designed to give selected, trusted users administrative control when needed.
The bug (CVE-2021-3156) found by Qualys, though, allows any local user to gain root-level access on a vulnerable host in its default configuration. Qualys is disclosing its findings in a coordinated release with operating systems vendors, and has bestowed the errant code with the memorable name of the mythical mischief-maker Baron Samedi.
The following versions of sudo are affected: 1.8.2 through 1.8.31p2 and 1.9.0 through 1.9.5p1. Qualys developed exploits for several Linux distributions, including Ubuntu 20.04 (Sudo 1.8.31), Debian 10 (Sudo 1.8.27), and Fedora 33 (Sudo 1.9.2), and the security biz believes other distributions are vulnerable, too.
Ubuntu and Red Hat have already published patches, and your distro may have as well, so get to it.
In their write-up, Qualys researchers explain, “set_cmnd() is vulnerable to a heap-based buffer overflow, because the out-of-bounds characters that are copied to the ‘user_args’ buffer were not included in its size.”
[…]
The bug was introduced in July 2011 (commit 8255ed69) and has persisted unfixed until now.
Dutch police have arrested two individuals on Friday for allegedly selling data from the Dutch health ministry’s COVID-19 systems on the criminal underground.
The ads consisted of photos of computer screens listing data of one or more Dutch citizens.
The reporter said he tracked down the screengrabs to two IT systems used by the Dutch Municipal Health Service (GGD) — namely CoronIT, which contains details about Dutch citizens who took a COVID-19 test, and HPzone Light, one of the DDG’s contact-tracing systems.
Verlaan said the data had been sold online for months for prices ranging from €30 to €50 per person.
Buyers would receive details such as home addresses, emails, telephone numbers, dates of birth, and a person’s BSN identifier (Dutch social security number).
Two men arrested in Amsterdam within a day
In a press release today, Dutch police said they started an investigation last week when they learned of the ads and arrested two suspects within 24 hours of the complaint.
Both men were arrested in Amsterdam on Friday, and were identified as a 21-year-old man from the city of Heiloo and a 23-year-old man from the city of Alblasserdam. Their homes were also searched, and their computers seized, police said.
According to Verlaan, the two suspects worked in DDG call centers, where they had access to official Dutch government COVID-19 systems and databases.
It also turns out that the GGD was warned repeatedly of their poor security measures over the years and nothing was done about it. Andre Rouwvoet, the boss of the GGD was also warned and says it’s one of those things that couldn’t be helped. This is simply not true. The most obvious questions are:
Why wasn’t the data deleted after no longer being relevant (it’s kept for traceability of other people exposed and so loses relevance after 10 – 14 days)
Why could helpdesk people access all of this huge database?
Why wasn’t there a system op alarms in place to shout out when people were bulk exporting data?
The JSOF research labs are reporting 7 vulnerabilities found in dnsmasq, an open-source DNS forwarding software in common use. Dnsmasq is very popular, and we have identified approximately 40 vendors whom we believe use dnsmasq in their products, as well as major Linux distributions.
The DNS protocol has a history of vulnerabilities dating back to the famous 2008 Kaminsky attack. Nevertheless, a large part of the Internet still relies on DNS as a source of integrity, in the same way it has for over a decade, and is therefore exposed to attacks that can endanger the integrity of parts of the web.
DNSpooq
The Dnspooq vulnerabilities include DNS cache poisoning vulnerabilities as well as a potential Remote code execution and others. The list of devices using dnsmasq is long and varied. According to our internet-based research, prominent users of dnsmasq seem to include Cisco routers, Android phones, Aruba devices, Technicolor, and Red-Hat, as well as Siemens, Ubiquiti networks, Comcast, and others listed below. Depending on how they use dnsmasq, devices may be more or less affected, or not affected at all.
[…]
The DNSpooq vulnerability set divides into 2 types of vulnerabilities:
DNS cache poisoning attacks, similar to the Kaminsky attack, but different in some aspects.
Buffer overflow vulnerabilities that could lead to remote code execution.
[…]
The DNSpooq cache poisoning vulnerabilities are labeled: CVE-2020-25686, CVE-2020-25684, CVE-2020-25685
[…]
These [buffer overflow] vulnerabilities are labeled: CVE-2020-25687, CVE-2020-25683, CVE-2020-25682, CVE-2020-25681
WhatsApp groups are showing up on Google search yet again. As a result, anyone could discover and join a private WhatsApp group by simply searching on Google. This was first discovered in 2019, and was apparently fixed last year after becoming public. Another old issue, which also appeared to have been fixed but seems to be cropping up again, is user profiles showing up through search results. People’s phone numbers and profile pictures could be surfaced through a simple a Google search, because of the issue.
By allowing the indexing of group chat invites, WhatsApp is making several private groups available across the Web as their links can be accessed by anyone using a simple search query on Google — although we are not sharing the exact details, this was verified by Gadgets 360. Someone who finds these links can join the groups and would also be able to see the participants and their phone numbers alongside the posts being shared within those groups.
Update:WhatsApp replied to say, “Since March 2020, WhatsApp has included the ‘noindex’ tag on all deep link pages which, according to Google, will exclude them from indexing.” Gadgets 360 was able to confirm that the search results are no longer visible on Google anymore; however, WhatsApp’s statement did not mention this fix. The full statement is at the end of this story. Rajshekhar Rajaharia, who informed about the indexing issue, commented on the statement given by WhatsApp and said, “Adding the ‘noindex’ tag is not a proper solution as links surface again on search results in a a few months. Big tech companies like WhatsApp should look for a proper solution if they really care users’ privacy.”
Private groups on WhatsApp are usually only accessible by those who have been sent an invite link by a moderator. However, these links were indexed by Google, making them discoverable by everyone. The same issue was exposed in February last year.
Following the latest privacy breach, WhatsApp said it has resolved the problem with Google.
“Since March 2020, WhatsApp has included the “noindex” tag on all deep link pages which, according to Google, will exclude them from indexing. We have given our feedback to Google to not index these chats,” the Facebook-owned messaging app said in a statement.
WhatsApp also warned users not to post group chat invite links on publicly accessible websites.
Cybersecurity researcher Rajshekhar Rajaharia tweeted that WhatsApp Web users’ data was being indexed on Google again, pointing out that this was the third time the issue had occurred.
When information is indexed, it can be found in a search engine and made public. As such, companies generally take measures to prevent private data from being indexed.
He had pointed out a similar issue earlier on Jan 11, where users’ profiles and invitations to join group chats were exposed on Google, which enabled strangers to potentially find users’ phone numbers or even join chats.
[…]
In regards to the latest leak, Rajshekhar noted that WhatsApp was using a “Robots.txt” file and a “disallow all” setting, to instruct Google not to index anything.
Though a Robots.txt, or robots exclusion protocol, is generally used to instruct web crawlers (which index pages) to stay away, Google was still indexing WhatsApp user data.
Rajshekhar explained why this was still occurring: Google requires page owners not to use Robots.txt when using the “noindex” tag, as stated in its search indexing help page.
This is because the features clash, with Google unable to detect the “noindex” tag if it was being stopped by Robot.txt.
High-flying and rapidly growing Chinese social media management company Socialarks has suffered a huge data leak leading to the exposure of over 400GB of personal data including several high-profile celebrities and social media influencers.
The company’s unsecured ElasticSearch database contained personally identifiable information (PII) from at least 214 million social media users from around the world, using both populist consumer platforms such as Facebook and Instagram, as well as professional networks such as LinkedIn.
The Elastic instance was discovered as part of Safety Detectives’ cybersecurity mission of discovering online vulnerabilities that could potentially pose risks to the general public. Once the owner of the data is identified, our team then informs the affected parties as soon as possible to mitigate the risk of any cybersecurity breaches and server leaks.
In Socialarks’ case, our team found the ElasticSearch server to be publicly exposed without password protection or encryption, during routine IP-address checks on potentially unsecured databases.
The lack of security apparatus on the company’s server meant that anyone in possession of the server IP-address could have accessed a database containing millions of people’s private information.
According to Anurag Sen, head of the Safety Detectives cybersecurity team, the affected database contained a “huge trove” of sensitive personal information to the tune of 408GB and more than 318 million records in total.
Given the sheer size of the data leak, it has been severely challenging for our team to unravel the full extent of the potential damage caused.
Our research team was able to determine that the entirety of the leaked data was “scraped” from social media platforms, which is both unethical and a violation of Facebook’s, Instagram’s and LinkedIn’s terms of service.
Moreover, it is important to note that Socialarks suffered a similar data breach in August 2020 leading to data from 150 million LinkedIn, Facebook and Instagram users being exposed.
Almost as a carbon-copy, August’s database breach revealed reams of personal data from 66 million LinkedIn users, 11.6 million Instagram accounts and 81.5 million Facebook accounts.
From the leaked data we discovered, it was possible to determine people’s full names, country of residence, place of work, position, subscriber data and contact information, as well as direct links to their profiles.
[…]
The database contained more than 408GB of data and more than 318 million records.
Without any protection whatsoever, our research team discovered the following:
11,651,162 Instagram user profiles
66,117,839 LinkedIn user profiles
81,551,567 Facebook user profiles
a further 55,300,000 Facebook profiles which were summarily deleted within a few hours after our team first discovered the server and its vulnerability.
What was surprising, that the numbers of profiles affected in the data leak found by our team are the same as the numbers mentioned in the August data leak. However, there were big differences, such as size of a database, the companies hosting those servers and the amount of indices.
The affected server, hosted by Tencent, was segmented into indices in order to store data obtained from each social media source. Our team discovered records from 3 major social media platforms: Instagram, Facebook and LinkedIn.
Instagram data
The Instagram index contained various popular personalities and online celebrities.
Our team discovered several high-profile influencers in the exposed database, including prominent food bloggers, celebrities and other social media influencers.
Celebrity Instagram profile including phone number and email address.
Every record contained public data scraped from influencer Instagram accounts, including their biographies, profile pictures, follower totals, location settings as well as personal information such as contact details in the form of email addresses and phone numbers.
The Instagram records exposed the following details:
Full name
Phone numbers for 6+ million users
Email addresses for all 11+ million users
Profile link
Username
Profile picture
Profile description
Average comment count
Number of followers and following count
Country of location
Specific locality in some cases
Frequently used hashtags
Facebook data
As mentioned above, the leak exposed 81.5 million Facebook user profiles with over 40 million exposed phone numbers and a further 32 million email address entries. Notably, most of the phone numbers our team discovered originated from pages and not individuals.
The Facebook records exposed the following details:
Full name
‘About’ text
Email addresses
Phone numbers
Country of location
Like, Follow and Rating count
Messenger ID
Facebook link with profile pictures
Website link
Profile description
LinkedIn data
Finally, our team discovered 66.1 million LinkedIn user profiles with as many as 31 million leaked email addresses (not disclosed in the profile but obtained through other, as yet unknown, sources).
The LinkedIn records exposed the following details:
Full name
Email addresses
Job profile including job title and seniority level
LinkedIn profile link
User tags
Domain name
Connected social media account login names e.g., Twitter
Company name and revenue margin
Database search showing 66 million LinkedIn profile results including personal information such as job title, name and email address.
The chart below shows a sample breakdown of user-profiles, sorted by country, from a sample of 42 million records.
Unexplained presence of Instagram and LinkedIn personal data
Socialarks’ database contained scraped data including personal information, albeit user data was partially completed.
However, according to our findings, Socialarks’ database stored personal data for Instagram and LinkedIn users such as private phone numbers and email addresses for users that did not divulge such information publicly on their accounts. How Socialarks could possibly have access to such data in the first place remains unknown.
Also, the fact that such a large, active, and data-rich database was left completely unsecured (probably for a second time) is astonishing.
It remains unclear how the company managed to obtain private data from multiple secure sources.
Instagram profile showing email and phone number despite information not being provided to Instagram.
It is also worth noting that Socialarks is based in China and was founded with private venture capital in 2014, while the vulnerable server is located in Hong Kong.
Neighbors is Ring’s online forum where users can share public safety information about what’s going on in their communities. It’s basically a more dystopian version of Nextdoor. Posts on Neighbors are public but supposedly anonymous, with a poster’s full name and location obscured. Yet, due to the recently discovered security bug, a savvy web explorer would’ve been able to access information about the home addresses, as well as the exact latitude and longitude, of a poster’s location, TechCrunch reports.
Similarly, every time a user posted on Neighbors, Ring servers generated a unique number for the post. These numbers increased incrementally with each post, making it easy to tie the identifying number to other information about the poster, including geographical data, according to TechCrunch. All of this was invisible to the app user, however.
TL;DR: If you have a Zyxel USG, ATP, VPN, ZyWALL or USG FLEX you should update to the latest firmware version today. You can find the full list of affected devices here and the Zyxel advisory here.
Zyxel is a popular brand for firewalls that are marketed towards small and medium businesses. Their Unified Security Gateway (USG) product line is often used as a firewall or VPN gateway. As a lot of us are working from home, VPN-capable devices have been quite selling well lately.
When doing some research (rooting) on my Zyxel USG40, I was surprised to find a user account ‘zyfwp’ with a password hash in the latest firmware version (4.60 patch 0). The plaintext password was visible in one of the binaries on the system. I was even more surprised that this account seemed to work on both the SSH and web interface.
$ ssh zyfwp@192.168.1.252
Password: Pr*******Xp
Router> show users current
No: 1
Name: zyfwp
Type: admin
(...)
Router>
The user is not visible in the interface and its password cannot be changed. I checked the previous firmware version (4.39) and although the user was present, it did not have a password. It seemed the vulnerability had been introduced in the latest firmware version. Even though older versions do not have this vulnerability, they do have others (such as this buffer overflow) so you should still update.
As SSL VPN on these devices operates on the same port as the web interface, a lot of users have exposed port 443 of these devices to the internet. Using publicly available data from Project Sonar, I was able to identify about 3.000 Zyxel USG/ATP/VPN devices in the Netherlands. Globally, more than 100.000 devices have exposed their web interface to the internet.
Spotify said it has reset an undisclosed number of user passwords after blaming a software vulnerability in its systems for exposing private account information to its business partners.
In a data breach notification filed with the California attorney general’s office, the music streaming giant said the data exposed “may have included email address, your preferred display name, password, gender, and date of birth only to certain business partners of Spotify.” The company did not name the business partners, but added that Spotify “did not make this information publicly accessible.”
Spotify said the vulnerability existed as far back as April 9 but wasn’t discovered until November 12. But like most data breach notices, Spotify did not say what the vulnerability was or how user account data became exposed.
“We have conducted an internal investigation and have contacted all of our business partners that may have had access to your account information to ensure that any personal information that may have been inadvertently disclosed to them has been deleted,” the letter read.
Spotify spokesperson Adam Grossberg confirmed that a “small subset” of Spotify users are affected, but did not provide a specific figure. Spotify has more than 320 million users, and 144 million subscribers.
It’s the second time in as many months that the company has reset user passwords.
Last month security researchers found an unsecured database, likely operated by hackers, allegedly containing around 300,000 stolen user passwords. The database was probably used to launch credential stuffing attacks, in which lists of stolen passwords are matched against different websites that use the same password.
Although in that case the exposed data did not come from Spotify, the company reset the passwords on affected user accounts.
The personal information of more than 243 million Brazilians, including alive and deceased, has been exposed online after web developers left the password for a crucial government database inside the source code of an official Brazilian Ministry of Health’s website for at least six months.
The security snafu was discovered by reporters from Brazilian newspaper Estadao, the same newspaper that last week discovered that a Sao Paolo hospital leaked personal and health information for more than 16 million Brazilian COVID-19 patients after an employee uploaded a spreadsheet with usernames, passwords, and access keys to sensitive government systems on GitHub.
Estadao reporters said they were inspired by a report filed in June by Brazilian NGO Open Knowledge Brasil (OKBR), which, at the time, reported that a similar government website also left exposed login information for another government database in the site’s source code.
Since a website’s source code can be accessed and reviewed by anyone pressing F12 inside their browser, Estadao reporters searched for similar issues in other government sites.
They found a similar leak in the source code of e-SUS-Notifica, a web portal where Brazilian citizens can sign up and receive official government notifications about the COVID-19 pandemic
Bumble, the dating app behemoth that’s allegedly headed to a major IPO as soon as next year, apparently took over half a year to deal with major security flaws that left sensitive information its millions of users vulnerable.
That’s according to new research posted over the weekend by cybersecurity firm Independent Security Evaluators (ISE) detailing how a bad actor—even one that was banned from Bumble—could exploit a vulnerability in the app’s underlying code to pull the rough location data for any Bumbler within their city, as well as additional profile data like photos and religious views. Despite being informed about this vulnerability in mid-March, the company didn’t patch the issues until November 12—roughly six and a half months later.
Pre-patch, anyone with a Bumble account could query the app’s API in order to figure out roughly how many miles away any other user in their city happened to be. As the blog’s author, Sanjana Sarda, explained, if a certain creepy someone really wanted to figure out the location of a given Bumble user, it wouldn’t be too hard to set up a handful of accounts, figure out the user’s basic distance from each one, and use that collection of data to triangulate a Bumbler’s precise location.
Bumble isn’t the first company to accidentally leave this sort of data freely available. Last year, cybersecurity sleuths were able to create to glean precise locations of people using LGBT-centric dating apps like Grindr and Romeo and collate them into a user location map. And those location-data leaks are on top of the deliberate data sharing these sorts of dating apps typically already engage in with a bevy third-party partners. You would think that an app purporting to be a feminist haven like Bumble might extend its idea of user safety to its data practices.
While some of the issues described by Sarda have been resolved, the belated patch apparently didn’t tackle one of the other major API-based issues described in the blog, which allowed ISE to get unlimited swipes (or “votes” in Bumble parlance), along with access to other premium features like the ability to unswipe or to see who might have swiped right on them. Typically, accessing these features cost a given Bumbler roughly $10 dollars per week.
