By continuing to use the site or forum, you agree to the use of cookies, find out more by reading our GDPR policy

Although some people might worry about the National Security Agency itself spying on their phones, the NSA has some sage advice for iPhone and android users concerned about zero-click exploits and the like: turn it off and on again once per week. How often do you turn off your iPhone or android device? Completely turn it off and then reboot it, rather than just going into standby mode, that is. I suspect that the answer for many people is only when a security or operating system update requires it. That, according to the NSA, could be a big mistake. In a document detailing several mobile device best practices, the NSA recommends users turn their devices off and then back on once every week to protect against zero-click exploits, which attackers often use to eavesdrop on and collect data from phones. Users can mitigate the threat of spear-phishing, which can lead to the installation of yet more malware and spyware, by the same simple action. However, the NSA document does warn that the turn it off and on again advice will only sometimes prevent these attacks from being successful. “Threats to mobile devices are more prevalent and increasing in scope and complexity,” the NSA said while warning that some smartphone features “provide convenience and capability but sacrifice security.” As such, doing something is always better than doing nothing when it comes to being proactive about your device and data security. The advice given is not some silver bullet that will solve all your security ills, it must be noted. Indeed, the NSA document includes a chart that shows how effective each tactic is against different threats. While good general advice, turning it off and on again will not help you against many of the more advanced malware and spyware threats that are programmed to reload on reboot. The NSA also advises Phone users to disable Bluetooth when not using it, update the device as soon as possible when operating system and application updates become available and disable location services when not needed. The small matter of security over convenience comes into play for much of the advice given, as you can tell already. Throw in not using public Wi-Fi networks and not using public charging stations, despite plenty of security experts considering the risk to be low in most real-world use cases, and many smartphone users are likely to roll the dice. When it comes to public Wi-Fi there’s a difference between the risks that can be present and an individual actually being at risk. While it is possible for a determined criminal to use unsecured networks for nefarious purposes, this usually involves tricking an unsuspecting user into connecting to their Wi-Fi hotspot rather than one being provided by the railway company, airport, or coffee shop. A recently disclosed vulnerability that can lead to something called an SSID Confusion Attack is a good example of how this can work. Without going into the technical details, read the article for that; it can disable your VPN in certain circumstances and make it appear that you have connected to a secure network when you haven’t. But, again, most unsecured public WiFi networks are safe to use for general activity. The U.K. National Cyber Security Centre suggests that users instead connect by way of their mobile 4G or 5G network as these “will have built-in security and you can also use the tethering feature of most such devices to connect your laptop to your smartphone’s network. This makes sense when performing sensitive activities such as online banking, for example. The Federal Communications Commission, an independent agency of the U.S. government, also offers some pertinent security advice for smartphone users. There is a lot of overlap in the advice offered by differing government and law enforcement agencies, some of the FCC advice is worth mentioning here. Not modifying the security settings of your smartphone, for example. “Tampering with your phone’s factory settings, jailbreaking, or rooting your phone undermines the built-in security features offered by your wireless service and smartphone,” the FCC advises, “while making it more susceptible to an attack.” The mantra of not disabling security settings for the sake of convenience is one I agree with, but I acknowledge this is likely to go ignored by the general user, for whom convenience is everything until a security incident impacts them personally. The FCC also warns that understanding app permissions is important as these can be used to bypass certain security functionality by a malicious app developer. Luckily, modern mobile operating systems have made such permission granting more transparent than ever, but it still pays to be alert to the danger. “You should be cautious about granting applications access to personal information on your phone or otherwise letting the application have access to perform functions on your phone,” the FCC said. Learn more by visiting OUR FORUM.

Police and federal agencies are responding to a massive breach of personal data linked to a facial recognition scheme that was implemented in bars and clubs across Australia. The incident highlights emerging privacy concerns as AI-powered facial recognition becomes more widely used everywhere from shopping malls to sporting events. The affected company is Australia-based Outabox, which also has offices in the United States and the Philippines. In response to the COVID-19 pandemic, Outabox debuted a facial recognition kiosk that scans visitors and checks their temperature. The kiosks can also be used to identify problem gamblers who enrolled in a self-exclusion initiative. This week, a website called “Have I Been Outaboxed” emerged, claiming to be set up by former Outabox developers in the Philippines. The website asks visitors to enter their names to check whether their information had been included in a database of Outabox data, which the site alleges had lax internal controls and was shared in an unsecured spreadsheet. It claims to have more than 1 million records. The incident has rankled privacy experts who have long set off alarm bells over the creep of facial recognition systems in public spaces such as clubs and casinos. “Sadly, this is a horrible example of what can happen as a result of implementing privacy-invasive facial recognition systems,” Samantha Floreani, head of policy for Australia-based privacy and security nonprofit Digital Rights Watch, tells WIRED. “When privacy advocates warn of the risks associated with surveillance-based systems like this, data breaches are one of them.” According to the Have I Been Outaboxed website, the data includes “facial recognition biometric, driver license [sic] scan, signature, club membership data, address, birthday, phone number, club visit timestamps, slot machine usage?” It claims Outabox exported the “entire membership data” of IGT, a supplier of gambling machines. IGT vice president of global communications Phil O’Shaughnessy tells WIRED that “the data affected by this incident has not been obtained from IGT,” and that the firm would work with Outabox and law enforcement. The website’s owners posted a photo, signature, and redacted driver license belonging to one of Outabox’s founders, as well as a redacted screenshot of the alleged internal spreadsheet. WIRED was unable to independently verify the identity of the website’s owners or the authenticity of the data they claimed to have. An email sent to an address on the website was not returned. "Outabox is aware and responding to a cyber incident potentially involving some personal information,” an Outabox spokesperson tells WIRED. “We have been in communication with a group of our clients to inform them and outline our strategy to respond. Due to the ongoing Australian police investigation, we are not able to provide further information at this time.” The New South Wales police force confirmed to WIRED that it was investigating a data breach on Wednesday, but a spokesperson declined to share further details. On Thursday, the force announced that it, working alongside federal and state agencies, had arrested an unnamed 46-year-old man in a Sydney suburb. He is expected to be charged with blackmail. Clubs that used Outabox’s technology posted announcements about the incident and notified clients this week. One person who posted a breach notification from a club they visited recounted their experience with the facial recognition system. “My fondest memory of this system is visiting a club and having it confidently match my face to a member that was 20+ years older than me, and looked nothing like me,” they wrote in a post on X. The club did not respond to a request for comment. The Have I Been Outaboxed website, which is still online at the time of writing, alleges that Outabox stopped paying its developers in the Philippines. AI companies frequently employ low-cost overseas labor, including in the Philippines, to power their systems. The website encourages anybody whose data is included in the breach to contact venues and ask that they remove Outabox’s system. The site, which was set up last week according to online records, lists 19 venues. WIRED searched the database for prominent Australians including politicians, and it returned redacted results listing their name and the venues they allegedly attended. Further details are posted on OUR FORUM.

Some ​Google Chrome users report having issues connecting to websites, servers, and firewalls after Chrome 124 was released last week with the new quantum-resistant X25519Kyber768 encapsulation mechanism enabled by default. Google started testing the post-quantum secure TLS key encapsulation mechanism in August and has now enabled it in the latest Chrome version for all users. The new version utilizes the Kyber768 quantum-resistant key agreement algorithm for TLS 1.3 and QUIC connections to protect Chrome TLS traffic against quantum cryptanalysis. "After several months of experimentation for compatibility and performance impacts, we're launching a hybrid postquantum TLS key exchange to desktop platforms in Chrome 124," the Chrome Security Team explains. "This protects users' traffic from so-called 'store now decrypt later' attacks, in which a future quantum computer could decrypt encrypted traffic recorded today." Store now, decrypt later attacks are when attackers collect encrypted data and store it for the future when there may be new decryption methods, such as using quantum computers or encryption keys become available. To protect against future attacks, companies have already started to add quantum-resistant encryption to their network stack to prevent these types of decryption strategies from working in the future. Some companies that have already introduced quantum-resistant algorithms include Apple, Signal, and Google. However, as system admins have shared online since Google Chrome 124 and Microsoft Edge 124 started rolling out on desktop platforms last week, some web applications, firewalls, and servers will drop connections after the ClientHello TLS handshake. The issue also affects security appliances, firewalls, networking middleware, and various network devices from multiple vendors (e.g., Fortinet, SonicWall, Palo Alto Networks, AWS). "This appears to break the TLS handshake for servers that do not know what to do with the extra data in the client hello message," one admin said. "Same problem here since version 124 of Edge, it seems to go wrong with the SSL decryption of my palo alto," said another admin. These errors are not caused by a bug in Google Chrome but instead caused by web servers failing to properly implement Transport Layer Security (TLS) and not being able to handle larger ClientHello messages for post-quantum cryptography. This causes them to reject connections that use the Kyber768 quantum-resistant key agreement algorithm rather than switching to classic cryptography if they don't support X25519Kyber768. A website named tldr.fail was created to share additional information on how large post-quantum ClientHello messages can break connections in buggy web servers, with details on how developers can fix the bug. Website admins can also test their own servers by manually enabling the feature in Google Chrome 124 using the chrome://flags/#enable-tls13-kyber flag. Once enabled, admins can connect to their servers and see if the connection causes an "ERR_CONNECTION_RESET" error. Affected Google Chrome users can mitigate the issue by going to chrome://flags/#enable-tls13-kyber and disabling the TLS 1.3 hybridized Kyber support in Chrome. Administrators can also disable it by toggling off the PostQuantumKeyAgreementEnabled enterprise policy under Software > Policies > Google > Chrome or contacting the vendors to get an update for servers or middleboxes on their networks that aren't post-quantum-ready. Microsoft has also released information on how to control this feature via the Edge group policies. However, it's important to note that long-term, post-quantum secure ciphers will be required in TLS, and the Chrome enterprise policy allowing disabling it will be removed in the future. "Devices that do not correctly implement TLS may malfunction when offered the new option. For example, they may disconnect in response to unrecognized options or the resulting larger messages," Google says. "This policy is a temporary measure and will be removed in future versions of Google Chrome. It may be Enabled to allow you to test for issues, and may be Disabled while issues are being resolved." Following this and other developing stories on OUR FORUM.