More than 1,000 celebrities, government employees and politicians who have received honours had their home and work addresses posted on a government website, the Guardian can reveal.
The accidental disclosure of the tranche of personal details is likely to be considered a significant security breach, particularly as senior police and Ministry of Defence staff were among those whose addresses were made public.
Many of the more than a dozen MoD employees and senior counter-terrorism officers who received honours in the new year list had their home addresses revealed in a downloadable list, along with countless others who may believe the disclosure has put them in a vulnerable position.
Others included Jonathan Jones, the permanent secretary of the government’s legal department, and John Manzoni, the Cabinet Office permanent secretary. Less well-known figures included academics, Holocaust survivors, prison staff and community and faith leaders.
It is thought the document seen by the Guardian, which contains the details of 1,097 people, went online at 10.30pm on Friday and was taken down in the early hours of Saturday.
The vast majority of people on the list had their house numbers, street names and postcodes included.
Security camera startup Wyze has confirmed it suffered a data leak this month that may have left the personal information of millions of its customers exposed on the internet. No passwords or financial information were exposed, but email addresses, Wi-Fi network IDs and body metrics were left unprotected from Dec. 4 through Dec. 26, the company said Friday.
More than 2.4 million Wyze customers were affected by the leak, according to cybersecurity firm Twelve Security, which first reported on the leak
The data was accidentally left exposed when it was transferred to a new database to make the data easier to query, but a company employee failed to maintain security protocols during the process, Wyze co-founder Dongsheng Song wrote in a forum post.
“We are still looking into this event to figure out why and how this happened,” he wrote.
In an update Sunday, Song said Wyze discovered a second unprotected database during its investigation of the data leak. It’s unclear what information was stored in this database, but Song said passwords and personal financial data weren’t included.
This week, Twitter confirmed a vulnerability in its Android app that could let hackers see your “nonpublic account information” and commandeer your account to send tweets and direct messages.
According to a Twitter Privacy Center blog posted Friday, the (recently patched) security issue could allow hackers to gain control of an account and access data like location information and protected tweets “through a complicated process involving the insertion of malicious code into restricted storage areas of the Twitter app,” potentially putting the app’s millions of users at risk. A tweet from Twitter support later elaborated that the issue was fixed for Android version 7.93.4 (released in November for KitKat) as well as version 8.18 (released in October for Lollipop and newer).
Security researchers say they found evidence that a Chinese government-linked hacking group has been bypassing two-factor authentication (2FA) in a recent wave of attacks.
The attacks have been attributed to a group the cyber-security industry is tracking as APT20, believed to operate on the behest of the Beijing government, Dutch cyber-security firm Fox-IT said in a report published last week.
The group’s primary targets were government entities and managed service providers (MSPs). The government entities and MSPs were active in fields like aviation, healthcare, finance, insurance, energy, and even something as niche as gambling and physical locks.
Recent APT20 activity
The Fox-IT report comes to fill in a gap in the group’s history. APT20’s hacking goes back to 2011, but researchers lost track of the group’s operations in 2016-2017, when they changed their mode of operation.
Fox-IT’s report documents what the group has been doing over the past two years and how they’ve been doing it.
According to researchers, the hackers used web servers as the initial point of entry into a target’s systems, with a particular focus on JBoss, an enterprise application platform often found in large corporate and government networks.
APT20 used vulnerabilities to gain access to these servers, install web shells, and then spread laterally through a victim’s internal systems.
While on the inside, Fox-IT said the group dumped passwords and looked for administrator accounts, in order to maximize their access. A primary concern was obtaining VPN credentials, so hackers could escalate access to more secure areas of a victim’s infrastructure, or use the VPN accounts as more stable backdoors.
Fox-IT said that despite what appears to be a very prodigious hacking activity over the past two years, “overall the actor has been able to stay under the radar.”
They did so, researchers explain, by using legitimate tools that were already installed on hacked devices, rather than downloading their own custom-built malware, which could have been detected by local security software.
APT20 seen bypassing 2FA
But this wasn’t the thing that stood out the most in all the attacks the Dutch security firm investigated. Fox-IT analysts said they found evidence the hackers connected to VPN accounts protected by 2FA.
How they did it remains unclear; although, the Fox-IT team has their theory. They said APT20 stole an RSA SecurID software token from a hacked system, which the Chinese actor then used on its computers to generate valid one-time codes and bypass 2FA at will.
Normally, this wouldn’t be possible. To use one of these software tokens, the user would need to connect a physical (hardware) device to their computer. The device and the software token would then generate a valid 2FA code. If the device was missing, the RSA SecureID software would generate an error.
Image: Fox-IT
The Fox-IT team explains how hackers might have gone around this issue:
The software token is generated for a specific system, but of course this system specific value could easily be retrieved by the actor when having access to the system of the victim.
As it turns out, the actor does not actually need to go through the trouble of obtaining the victim’s system specific value, because this specific value is only checked when importing the SecurID Token Seed, and has no relation to the seed used to generate actual 2-factor tokens. This means the actor can actually simply patch the check which verifies if the imported soft token was generated for this system, and does not need to bother with stealing the system specific value at all.
In short, all the actor has to do to make use of the 2 factor authentication codes is to steal an RSA SecurID Software Token and to patch 1 instruction, which results in the generation of valid tokens.
Image: Fox-IT
Wocao
Fox-IT said it was able to investigate APT20’s attacks because they were called in by one of the hacked companies to help investigate and respond to the hacks.
More on these attacks can be found in a report named “Operation Wocao.”
A database containing more than 267 million Facebook user IDs, phone numbers, and names was left exposed on the web for anyone to access without a password or any other authentication.
Comparitech partnered with security researcher Bob Diachenko to uncover the Elasticsearch cluster. Diachenko believes the trove of data is most likely the result of an illegal scraping operation or Facebook API abuse by criminals in Vietnam, according to the evidence.
[…]
Diachenko immediately notified the internet service provider managing the IP address of the server so that access could be removed. However, Diachenko says the data was also posted to a hacker forum as a download.
Timeline of the exposure
The database was exposed for nearly two weeks before access was removed.
[…]
In total 267,140,436 records were exposed. Most of the affected users were from the United States. Diachenko says all of them seem to be valid. Each contained:
The log-in credentials for 3,672 Ring camera owners were compromised this week, exposing log-in emails, passwords, time zones, and the names people give to specific Ring cameras, which are often the same as camera locations, such as “bedroom” or “front door.”
Using the log-in email and password, an intruder could access a Ring customer’s home address, telephone number, and payment information, including the kind of card they have, and its last four digits and security code. An intruder could also access live camera footage from all active Ring cameras associated with an account, as well as a 30- to 60-day video history, depending on the user’s cloud storage plan.
It’s not so much being watched. It’s that I don’t really know if I’m being watched or not.
From across the other side of the world, a colleague has just accessed my Ring account, and in turn, a live-feed of a Ring camera in my apartment. He sent a screenshot of me stretching, getting ready for work. Then a second colleague accessed the camera from another country, and started talking to me through the Ring device.
“Joe can you tell I’m watching you type,” they added in a Slack message. The blue light which signals someone is watching the camera feed faded away. But I still couldn’t shake the feeling of someone may be tuning in. I went into another room.
[…]
Last week a wave of local media reports found hackers harassed people through Ring devices. In one case a hacker taunted a child in Mississippi, in another someone hurled racist insults at a Florida family. Motherboard found hackers have made dedicated software for more swiftly gaining access to Ring cameras by churning through previously compromised email addresses and passwords, and that some hackers were live-streaming the Ring abuse on their own so-called podcast dubbed “NulledCast.”
In response to the hacks, Ring put much of the blame for these hacks on its users in a blog post Thursday.
“Customer trust is important to us, and we take the security of our devices and service extremely seriously. As a precaution, we highly encourage all Ring users to follow security best practices to ensure your Ring account stays secure,” it said. To be clear, a user who decides to use a unique password on their Ring device and two-factor authentication is going to be safer than one who is reusing previously hacked credentials from another website. But rather than implementing its own safeguards, Ring is putting this onus on users to deploy security best practices; time and time again we’ve seen that people using mass-market consumer devices aren’t going to know or implement robust security measures at all times.
Ring is not offering basic security precautions, such as double-checking whether someone logging in from an unknown IP address is the legitimate user, or providing a way to see how many users are currently logged in—entirely common security measures across a wealth of online services.
[…]
A Ring account is not a normal online account. Rather than a username and password protecting messages or snippets of personal information, such as with, say, a video game account, breaking into a Ring account can grant access to exceptionally intimate and private parts of someone’s life and potentially puts their physical security at risk. Some customers install these cameras in their bedrooms or those of their children. Through an issue in the way a Ring-related app functions, Gizmodo found these cameras are installed all across the country. Someone with access can hear conversations and watch people, potentially without alerting the victims that they are being spied on. The app displays a user-selected address for the camera, and the live feed could be used to determine whether the person is home, which could be useful if someone were, for example, planning a robbery. Once a hacker has broken into the account, they can watch not only live streams of the camera, but can also silently watch archived video of people—and families—going about their days.
A preponderance of weak keys is leaving IoT devices at risk of being hacked, and the problem won’t be an easy one to solve.
This was the conclusion reached by the team at security house Keyfactor, which analyzed a collection of 75 million RSA certificates gathered from the open internet and determined that number combinations were being repeated at a far greater rate than they should, meaning encrypted connections could possibly be broken by attackers who correctly guess a key.
Comparing the millions of keys on an Azure cloud instance, the team found common factors were used to generate keys at a rate of 1 in 172 (435,000 in total). By comparison, the team also analyzed 100 million certificates collected from the Certificate Transparency logs on desktops, where they found common factors in just five certificates, or a rate of 1 in 20 million.
The team believes that the reason for this poor entropy is down to IoT devices. Because the embedded gear is often based on very low-power hardware, the devices are unable to properly generate random numbers.
The result is keys that could be easier for an attacker to break, leaving the device and all of its users vulnerable.
“The widespread susceptibility of these IoT devices poses a potential risk to the public due to their presence in sensitive settings,” Keyfactor researchers Jonathan Kilgallin and Ross Vasko noted.
“We conclude that device manufacturers must ensure their devices have access to sufficient entropy and adhere to best practices in cryptography to protect consumers.”
Academics from three universities across Europe have disclosed today a new attack that impacts the integrity of data stored inside Intel SGX, a highly-secured area of Intel CPUs.
The attack, which researchers have named Plundervolt, exploits the interface through which an operating system can control an Intel processor’s voltage and frequency — the same interface that allows gamers to overclock their CPUs.
Academics say they discovered that by tinkering with the amount of voltage and frequency a CPU receives, they can alter bits inside SGX to cause errors that can be exploited at a later point after the data has left the security of the SGX enclave.
They say Plundervolt can be used to recover encryption keys or introduce bugs in previously secure software.
De persoonsgegevens van mogelijk 29.000 klanten van energiebedrijven Budget Energie en NLE liggen op straat. Naast namen en adressen is er kans dat er ook telefoonnummers en bankrekeningnummers zijn gelekt. De data is niet per ongeluk gelekt, het gaat volgens het bedrijf om een moedwillige diefstal.
Moederbedrijf Nuts Groep heeft klanten van Budget Energie en NLE vanmorgen per e-mail op de hoogte gebracht van het datalek. Volgens het bedrijf gaat het niet om een softwarelek maar om ‘ongeautoriseerde toegang’ tot contractgegevens.
Politie-onderzoek
Het gaat om mogelijk 29.000 van de in totaal 700.000 klanten van de energiebedrijven. “Er is een onderzoek gestart door de politie. Zo lang dat loopt, doen wij geen uitspraken over de oorzaak van het lek en het aantal betrokkenen”, zegt Babette Huberts, manager legal van Nuts Groep tegen RTL Z. Ook wil Huberts niet kwijt hoe het lek is ontdekt.
Later op de dag heeft Huberts laten weten dat het gaat om een moedwillige actie.
A vulnerability in millions of fully patched Android phones is being actively exploited by malware that’s designed to drain the bank accounts of infected users, researchers said on Monday.
The vulnerability allows malicious apps to masquerade as legitimate apps that targets have already installed and come to trust, researchers from security firm Promon reported in a post. Running under the guise of trusted apps already installed, the malicious apps can then request permissions to carry out sensitive tasks, such as recording audio or video, taking photos, reading text messages or phishing login credentials. Targets who click yes to the request are then compromised.
Researchers with Lookout, a mobile security provider and a Promon partner, reported last week that they found 36 apps exploiting the spoofing vulnerability. The malicious apps included variants of the BankBot banking trojan. BankBot has been active since 2017, and apps from the malware family have been caught repeatedlyinfiltrating the Google Play Market.
The vulnerability is most serious in versions 6 through 10, which (according to Statista) account for about 80% of Android phones worldwide. Attacks against those versions allow malicious apps to ask for permissions while posing as legitimate apps. There’s no limit to the permissions these malicious apps can seek. Access to text messages, photos, the microphone, camera, and GPS are some of the permissions that are possible. A user’s only defense is to click “no” to the requests.
An affinity for multitasking
The vulnerability is found in a function known as TaskAffinity, a multitasking feature that allows apps to assume the identity of other apps or tasks running in the multitasking environment. Malicious apps can exploit this functionality by setting the TaskAffinity for one or more of its activities to match a package name of a trusted third-party app. By either combining the spoofed activity with an additional allowTaskReparenting activity or launching the malicious activity with an Intent.FLAG_ACTIVITY_NEW_TASK, the malicious apps will be placed inside and on top of the targeted task.
“Thus the malicious activity hijacks the target’s task,” Promon researchers wrote. “The next time the target app is launched from Launcher, the hijacked task will be brought to the front and the malicious activity will be visible. The malicious app then only needs to appear like the target app to successfully launch sophisticated attacks against the user. It is possible to hijack such a task before the target app has even been installed.”
Promon said Google has removed malicious apps from its Play Market, but, so far, the vulnerability appears to be unfixed in all versions of Android. Promon is calling the vulnerability “StrandHogg,” an old Norse term for the Viking tactic of raiding coastal areas to plunder and hold people for ransom. Neither Promon nor Lookout identified the names of the malicious apps. That omission makes it hard for people to know if they are or were infected.
[…]
Suspicious signs include:
An app or service that you’re already logged into is asking for a login.
Permission popups that don’t contain an app name.
Permissions asked from an app that shouldn’t require or need the permissions it asks for. For example, a calculator app asking for GPS permission.
Typos and mistakes in the user interface.
Buttons and links in the user interface that do nothing when clicked on.
Led by Noam Rotem and Ran Locar, vpnMentor’s research team discovered a breached database belonging to the American communications company, TrueDialog.
TrueDialog provides SMS texting solutions to companies in the USA and the database in question was linked to many aspects of their business. This was a huge discovery, with a massive amount of private data exposed, including tens of millions of SMS text messages.
Aside from private text messages, our team discovered millions of account usernames and passwords, PII data of TrueDialog users and their customers, and much more.
By not securing their database properly, TrueDialog compromised the security and privacy of millions of people across the USA.
[…]
Millions of email addresses, usernames, cleartext passwords, and base64 encoded passwords (which are easy to decrypt) were easily accessible within the database.
[…]
We were able to find tens of millions of entries from messages sent via TrueDialog and conversations hosted on the platform. The sensitive data contained in these SMS messages included, but was not limited to:
Full Names of recipients, TrueDialog account holders, & TrueDialog users
Content of messages
Email addresses
Phone numbers of recipients and users
Dates and times messages were sent
Status indicators on messages sent, like Read receipts, replies, etc.
TrueDialog account details
The data exposed was a mix of TrueDialog account holders, users, and tens of millions of American citizens.
[…]
There were hundreds of thousands of entries with details about users, including full names, phone numbers, addresses, emails and more.
A standard used by phone carriers around the world can leave users open to all sorts of attacks, like text message and call interception, spoofed phone numbers, and leaking their coarse location, new research reveals.
The Rich Communication Services (RCS) standard is essentially the replacement for SMS. The news shows how even as carriers move onto more modern protocols for communication, phone network security continues to be an exposed area with multiple avenues for attack in some implementations of RCS.
“I’m surprised that large companies, like Vodafone, introduce a technology that exposes literally hundreds of millions of people, without asking them, without telling them,” Karsten Nohl from cybersecurity firm Security Research Labs (SRLabs) told Motherboard in a phone call.
SRLabs researchers Luca Melette and Sina Yazdanmehr will present their RCS findings at the upcoming Black Hat Europe conference in December, and discussed some of their work at security conference DeepSec on Friday.
RCS is a relatively new standard for carrier messaging and includes more features than SMS, such as photos, group chats, and file transfers. Back in 2015, Google announced it would be adopting RCS to move users away from SMS, and that it had acquired a company called Jibe Mobile to help with the transition. RCS essentially runs as an app on your phone that logs into a service with a username and password, Nohl explained.
SRLabs estimated RCS is already implemented by at least 100 mobile operators, with many of the deployments being in Europe. SRLabs said that all the major U.S. carriers—AT&T, T-Mobile, Sprint, and Verizon—were using RCS.
SRLabs didn’t find an issue in the RCS standard itself, but rather how it is being implemented by different telecos. Because some of the standard is undefined, there’s a good chance companies may deploy it in their own way and make mistakes.
“Everybody seems to get it wrong right now, but in different ways,” Nohl said. SRLabs took a sample of SIM cards from a variety of carriers and checked for RCS-related domains, and then looked into particular security issues with each. SRLabs didn’t say which issues impacted which particular telecos.
Some of those issues include how devices receive RCS configuration files. In one instance, a server provides the configuration file for the right device by identifying them by their IP address. But because they also use that IP address, “Any app that you install on your phone, even if you give it no permissions whatsoever, it can request this file. So now every app can get your username and password to all your text messages and all your voice calls. That’s unexpected,” Nohl said.
The ransom note that NextCry victims receive reads ““READ_FOR_DECRYPT”, and demands 0.025 BTC for a victim’s files to be unlocked.
One NextCloud user, xact64, shared his experience with the malware on a Bleeping Computer forum in an effort to find a way to decrypt personal files which had been instantaneously locked in a NextCry attack: “I realized immediately that my server got hacked and those files got encrypted. “The first thing I did was pull the server to limit the damage that was being done (only 50% of my files got encrypted).” He added, “I have my own Linux server (an old thin client I gave a second life) with NGINX reverse-proxy”.
This statement provides insight into how hackers may have been able to access his system. On October 24, NextCloud disclosed a remote code execution vulnerability (CVE-2019-11043) which has been exploited to compromise servers with the default Nextcloud NGINX configuration.
NextCloud recommends that administrators upgrade their PHP packages and NGINX configuration file to the latest version to protect against NextCry attacks.
In October, dark web researcher Vinny Troia found one such trove sitting exposed and easily accessible on an unsecured server, comprising 4 terabytes of personal information—about 1.2 billion records in all.
While the collection is impressive for its sheer volume, the data doesn’t include sensitive information like passwords, credit card numbers, or Social Security numbers. It does, though, contain profiles of hundreds of millions of people that include home and cell phone numbers, associated social media profiles like Facebook, Twitter, LinkedIn, and Github, work histories seemingly scraped from LinkedIn, almost 50 million unique phone numbers, and 622 million unique email addresses.
“It’s bad that someone had this whole thing wide open,” Troia says. “This is the first time I’ve seen all these social media profiles collected and merged with user profile information into a single database on this scale. From the perspective of an attacker, if the goal is to impersonate people or hijack their accounts, you have names, phone numbers, and associated account URLs. That’s a lot of information in one place to get you started.”
Some users noticed the hash of the binaries they downloaded did not match the expected one: https://github.com/monero-project/monero/issues/6151
It appears the box has been indeed compromised and different CLI binaries served for 35 minutes. Downloads are now served from a safe fallback source.
Always check the integrity of the binaries you download!
If you downloaded binaries in the last 24h, and did not check the integrity of the files, do it immediately. If the hashes do not match, do NOT run what you downloaded. If you have already run them, transfer the funds out of all wallets that you opened with the (probably malicious) executables immediately, using a safe version of the Monero wallet (the one online as we speak is safe — but check the hashes).
More information will be posted as several people are currently investigating to get to the bottom of this.
According to an investigation by Checkmarx security researchers, some Android devices may have an unpatched security flaw that an app could use to record you without your knowledge using your device’s camera and mic.
No attacks that exploit the bug have been reported so far, thankfully. Still, the Checkmarx researchers were able to successfully create and execute commands that could remotely record phone calls; capture photos, video, and audio; access GPS metadata from photos; and even check whether the phone was facing down—meaning hackers may one day create their own clever attacks for devices running an unpatched version of a device’s default camera apps.
Google and Samsung released patches for impacted smartphones earlier this year, but Checkmarx’s report suggests that many other Android smartphones may still be affected. Fortunately, there are ways you can check if your device has been patched.
Check for the bug on Pixel phones
Pay attention to the “Last Updated” date
Screenshot: Brendan Hesse
Pixel users can check for the patch easily: simply open your device’s settings then go to Apps & Notifications > See All Apps > Camera > Advanced > App details to open the app’s Google Play Store page. If the app has been updated since July 2019, you’re in the clear.
Check for the bug on other Android devices (manually)
If you’re not sure whether your smartphone’s manufacturer has issued an update for your phone’s camera app that fixes this bug, one way to find out is to try exploiting the bug yourself (which comes care of Ars Technica).
You’ll need:
A PC (this will work on Windows, Mac, and Linux).
Your Android device.
A USB cable to connect them.
Once you have those materials, here’s what you need to do:
First, you’ll need to install and configure ADB tools on your PC. All the necessary files and instructions for installing ADB for your PC’s OS can be found on the XDA Developer Forums.
After ADB is installed and configured, plug your Android phone into your PC with the USB cable. Next, we’re going to try to use codes to force the phone to take videos and photos without accessing the phone’s camera app.
Open your PC’s command terminal. On Windows: Press “Windows Key+R,” then type “cmd” and hit “run.” On Mac: Press “Command+Space” to open the Finder, then type “Terminal” and double click the Terminal icon to run.
In the command prompt window, run the following commands one at a time:
adb
shell am start-activity
-ncom.google.android.GoogleCamera/com.android.camera.CameraActivity
—ezextra_turn_screen_on true -a android.media.action.VIDEO_CAMERA
—ezandroid.intent.extra.USE_FRONT_CAMERA true
Then:
adb
shell am start-activity
-ncom.google.android.GoogleCamera/com.android.camera.CameraActivity
—ezextra_turn_screen_on true -a android.media.action.STILL_IMAGE_CAMERA
—ez android.intent.extra.USE_FRONT_CAMERA true
—eiandroid.intent.extra.TIMER_DURATION_SECONDS 3
Open your phone’s camera app and go to your photo/video library to check if the commands worked. If you find a new photo or video, then the bug is present on your device.
If you haven’t updated your device’s camera app in awhile, try checking for updates via the Google Play Store. Once you’ve installed anything that’s available for your phone’s default camera app, try the above ADB commands again. If they still work, you should report the issue to your device’s manufacturer as soon as possible. In addition, stay away from unknown camera, video, or audio recording apps, since this is the most likely method for hackers to slip malicious code onto your device and take a few photos.
A notice (PDF) posted by the long-operating department store chain said that, between October 7 and October 15 of this year, a Magecart script was running on the checkout page of its retail website.
The script was able to capture payment card details in two different ways: as it was being entered through the checkout page when placing an order, or if it was stored in the “wallet” page on the Macy’s website and then used to place an order.
“On October 15, 2019, we were alerted to a suspicious connection between macys.com and another website,” the retailer told exposed punters.
“Our security teams immediately began an investigation. Based on our investigation, we believe that on October 7, 2019 an unauthorized third party added unauthorized computer code to two pages on macys.com.”
Unfortunately for Macy’s customers, the script got pretty much everything needed for card fraud: card number, security code, and expiration date. Additionally, the malware was able to collect customer names as well as email and mailing addresses and phone numbers.
Macy’s notes that only the webpage was compromised: users who made purchases with the mobile app were not exposed. Experts say that the attack appears to be a rather bog-standard Magecart operation, albeit an extremely successful one.
Security company Onapsis estimates that roughly half of all companies using the Oracle EBS software have not yet patched CVE-2019-2648 and CVE-2019-2633, despite Big Red having pushed out fixes for both bugs back in April.
The two vulnerabilities are found in the Thin Client Framework API and are described as reflected SQL injections. An attacker who could remotely access the EBS server via HTTPS would be able to exploit the bug and send arbitrary commands to the vulnerable machine.
While this flaw is dangerous to EBS as a whole, it is particularly bad for servers that use the Payments module included with the suite. The Payments tool allows companies to set up and schedule direct deposits and automatic money transfers to suppliers or partners as well as handle invoices and orders. The bank routing and account numbers for transfer orders are kept on the server as text files and automatically loaded when needed.
You can guess where this is going.
An attacker who exploited either of the SQL injection flaws would be able to remotely modify those transfer order files to include instructions to move cash to an account of their choosing. Instant bank fraud.
Indian officials acknowledged on October 30th that a cyberattack occurred at the country’s Kudankulam nuclear power plant. An Indian private cybersecurity researcher had tweeted about the breach three days earlier, prompting Indian authorities to initially deny that it had occurred before admitting that the intrusion had been discovered in early September and that efforts were underway to respond to it.
According to last Monday’s Washington Post, Kudankulam is India’s biggest nuclear power plant, “equipped with two Russian-designed and supplied VVER pressurized water reactors with a capacity of 1,000 megawatts each. Both reactor units feed India’s southern power grid. The plant is adding four more reactor units of the same capacity, making the Kudankulam Nuclear Power Plant one of the largest collaborations between India and Russia.”
While reactor operations at Kudankulam were reportedly unaffected, this incident should serve as yet another wake-up call that the nuclear power industry needs to take cybersecurity more seriously. There are worrying indications that it currently does not: A 2015 report by the British think tank Chatham House found pervasive shortcomings in the nuclear power industry’s approach to cybersecurity, from regulation to training to user behavior. In general, nuclear power plant operators have failed to broaden their cultures of safety and security to include an awareness of cyberthreats. (And by cultures of safety and security, those in the field—such as the Fissile Materials Working Group—refer to a broad, all-embracing approach towards nuclear security, that takes into account the human factor and encompasses programs on personnel reliability and training, illicit trafficking interception, customs and border security, export control, and IT security, to name just a few items. The Hague Communiqué of 2014 listed nuclear security culture as the first of its three pillars of nuclear security, the other two being physical protection and materials accounting.)
This laxness might be understandable if last week’s incident were the first of its kind. Instead, there have been over 20 known cyber incidents at nuclear facilities since 1990.
Trusted Platform Module (TPM) serves as a root of trust for the operating system. TPM is supposed to protect our security keys from malicious adversaries like malware and rootkits.
Most laptop and desktop computers nowadays come with a dedicated TPM chip, or they use the Intel firmware-based TPM (fTPM) which runs on a separate microprocessor inside the CPU. Intel CPUs support fTPM since the Haswell generation (2013). TPM chips are also used in other computing devices such as cellphones and embedded devices.
We discovered timing leakage on Intel firmware-based TPM (fTPM) as well as in STMicroelectronics’ TPM chip. Both exhibit secret-dependent execution times during cryptographic signature generation. While the key should remain safely inside the TPM hardware, we show how this information allows an attacker to recover 256-bit private keys from digital signature schemes based on elliptic curves.
[…]
here is a high chance that you are affected. This depends if any of your computing devices (laptop, tablet, desktop, etc.) use Intel fTPM or STMicroelectronics TPM chips.
IT guru Bob Gendler took to Medium last week to share a startling discovery about Apple Mail. If you have the application configured to send and receive encrypted email—messages that should be unreadable for anyone without the right decryption keys—Apple’s digital assistant goes ahead and stores your emails in plain text on your Mac’s drive.
More frustrating, you can have Siri completely disabled on your Mac, and your messages will still appear within a Mac database known as snippets.db. A process known as suggested will still comb through your emails and dump them into this plaintext database. This issue, according to Gendler, is present on multiple iterations of macOS, including the most recent Catalina and Mojave builds.
“I discovered this database and what’s stored there on July 25th and began extensively testing on multiple computers with Apple Mail set up and fully confirming this on July 29th. Later that week, I confirmed this database exists on 10.12 machines up to 10.15 and behaves the same way, storing encrypted messages unencrypted. If you have iCloud enabled and Siri enabled, I know there is some data sent to Apple to help with improving Siri, but I don’t know if that includes information from this database.”
Consider keeping Siri out of your email
While Apple is currently working on a fix for the issues Gendler raised, there are two easy ways you can ensure that your encrypted emails aren’t stored unencrypted on your Mac. First, you can disable Siri Suggestions for Mail within the “Siri” section of System Preferences.
Screenshot: David Murphy
Second, you can fire up Terminal and enter this command:
Regardless of which option you pick, you’ll want to delete the snippets.db file, as disabling Siri’s collection capabilities doesn’t automatically remove what’s already been collected (obviously). You’ll be able to find this by pulling up your Mac’s drive (Go > Computer) and doing a quick search for “snippets.db.”
Screenshot: David Murphy
Apple also told The Verge that you can also limit which apps are allowed to have Full Disk Access on your Mac—via System Preferences > Security & Privacy > Privacy tab—to ensure that they can’t access your snippets.db file. You can also turn on FileVault, which will prevent your emails from appearing as plaintext within snippets.db.
Ubiquiti Networks is fending off customer complaints after emitting a firmware update that caused its UniFi wireless routers to quietly phone HQ with telemetry.
It all kicked off when the US-based manufacturer confirmed that a software update released this month programmed the devices to establish secure connections back to Ubiquiti servers and report information on Wi-Fi router performance and crashes.
Ubiquiti told customers all of the information is being handled securely, and has been cleared to comply with GDPR, Europe’s data privacy rules. Punters are upset they weren’t warned of the change.
“We have started to gather crashes and other critical events strictly for the purpose of improving our products,” the hardware maker said. “Any data collected is completely anonymized, GDPR compliant, transmitted using end-to-end encryption and encrypted at rest. The collection of this data does not and should not ever impact performance of devices.”
The assurance was of little consolation to UniFi owners who bristled at the idea of any of their data being collected, particularly without any notification nor permission. In particular, enterprise customers were less than thrilled to learn diagnostic data was being exfiltrated off their network.
“Undisclosed backdooring of my network is completely unacceptable and will result in no longer recommending, using, or selling of Ubiquiti gear,” remarked one netizen using the alias Private_.
“I realize that UBNT is too big to care about the few tens of $K per year that I generate for them, but I want to formally and clearly disclose my privacy policy/EULA, so that we understand each other. This is a stealth network intrusion and I don’t/won’t accept it.”
Security researchers have discovered a vulnerability in Ring doorbells that exposed the passwords for the Wi-Fi networks to which they were connected.
Bitdefender said the Amazon-owned doorbell was sending owners’ Wi-Fi passwords in cleartext as the doorbell joins the local network, allowing nearby hackers to intercept the Wi-Fi password and gain access to the network to launch larger attacks or conduct surveillance.
“When first configuring the device, the smartphone app must send the wireless network credentials. This takes place in an unsecure manner, through an unprotected access point,” said Bitdefender. “Once this network is up, the app connects to it automatically, queries the device, then sends the credentials to the local network.”
But all of this is carried out over an unencrypted connection, exposing the Wi-Fi password that is sent over the air.
Amazon fixed the vulnerability in all Ring devices in September, but the vulnerability was only disclosed today.
A number of popular “camgirl” sites have exposed millions of sex workers and users after the company running the sites left the back-end database unprotected.
The sites, run by Barcelona-based VTS Media, include amateur.tv, webcampornoxxx.net, and placercams.com. Most of the sites’ users are based in Spain and Europe, but we found evidence of users across the world, including the United States.
The database, containing months-worth of daily logs of the site activities, was left without a password for weeks. Those logs included detailed records of when users logged in — including usernames and sometimes their user-agents and IP addresses, which can be used to identify users. The logs also included users’ private chat messages with other users, as well as promotional emails they were receiving from the various sites. The logs even included failed login attempts, storing usernames and passwords in plaintext. We did not test the credentials as doing so would be unlawful.
None of the data was encrypted.
The exposed data also revealed which videos users were watching and renting, exposing kinks and private sexual preferences.
In all, the logs were detailed enough to see which users were logging in, from where, and often their email addresses or other identifiable information — which in some cases we could match to real-world identities.
Not only were users affected, the “camgirls” — who broadcast sexual content to viewers — also had some of their account information exposed.
