Daily Archives: August 19, 2021

How to Stop Apple From Scanning Your iPhone Photos Before iOS 15 Arrives – disable photo backups. No alternative offered, sorry.

Posted on by

Photos that are sent in messaging apps like WhatsApp or Telegram aren’t scanned by Apple. Still, if you don’t want Apple to do this scanning at all, your only option is to disable iCloud Photos. To do that, open the “Settings” app on your iPhone or iPad, go to the “Photos” section, and disable the “iCloud Photos” feature. From the popup, choose the “Download Photos & Videos” option to download the photos from your iCloud Photos library.

Image for article titled How to Stop Apple From Scanning Your iPhone Photos Before iOS 15 Arrives
Screenshot: Khamosh Pathak

You can also use the iCloud website to download all photos to your computer. Your iPhone will now stop uploading new photos to iCloud, and Apple won’t scan any of your photos now.

Looking for an alternative? There really isn’t one. All major cloud-backup providers have the same scanning feature, it’s just that they do it completely in the cloud (while Apple uses a mix of on-device and cloud scanning). If you don’t want this kind of photo scanning, use local backups, NAS, or a backup service that is completely end-to-end encrypted.

Source: How to Stop Apple From Scanning Your iPhone Photos Before iOS 15 Arrives

OK, so you stole $600m-plus from us, how about you be our Chief Security Advisor, Poly Network asks thief

Posted on by

The mysterious thief who stole $600m-plus in cryptocurrencies from Poly Network has been offered the role of Chief Security Advisor at the Chinese blockchain biz.

It’s been a rollercoaster ride lately for Poly Network. The outfit builds software that handles the exchange of crypto-currencies and other assests between various blockchains. Last week, it confirmed a miscreant had drained hundreds of millions of dollars in digital tokens from its platform by exploiting a security weakness in its design.

After Poly Network urged netizens, cryptoexchanges, and miners to reject transactions involving the thief’s wallet addresses, the crook started giving the digital money back – and at least $260m of tokens have been returned. The company said it has maintained communication with the miscreant, who is referred to as Mr White Hat.

“It is important to reiterate that Poly Network has no intention of holding Mr White Hat legally responsible, as we are confident that Mr White Hat will promptly return full control of the assets to Poly Network and its users,” the organization said.

“While there were certain misunderstandings in the beginning due to poor communication channels, we now understand Mr White Hat’s vision for Defi and the crypto world, which is in line with Poly Network’s ambitions from the very beginning — to provide interoperability for ledgers in Web 3.0.”

First, Poly Network offered him $500,000 in Ethereum as a bug bounty award. He said he wasn’t going to accept the money, though the reward was transferred to his wallet anyway. Now, the company has gone one step further and has offered him the position of Chief Security Advisor.

“We are counting on more experts like Mr White Hat to be involved in the future development of Poly Network since we believe that we share the vision to build a secure and robust distributed system,” it said in a statement. “Also, to extend our thanks and encourage Mr White Hat to continue contributing to security advancement in the blockchain world together with Poly Network, we cordially invite Mr White Hat to be the Chief Security Advisor of Poly Network.”

It’s unclear whether so-called Mr White Hat will accept the job offer or not. Judging by the messages embedded in Ethereum transactions exchanged between both parties, it doesn’t look likely at the moment. He still hasn’t returned $238m, to the best of our knowledge, and said he isn’t ready to hand over the keys to the wallet where the funds are stored. He previously claimed he had attacked Poly Network for fun and to highlight the vulnerability in its programming.

“Dear Poly, glad to see that you are moving things to the right direction! Your essays are very convincing while your actions are showing your distrust, what a funny game…I am not ready to publish the key in this week…,” according to one message he sent.

Source: OK, so you stole $600m-plus from us, how about you be our Chief Security Advisor, Poly Network asks thief • The Register

Zoom to pay $85M for lying about encryption and sending data to Facebook and Google

Posted on by

Zoom has agreed to pay $85 million to settle claims that it lied about offering end-to-end encryption and gave user data to Facebook and Google without the consent of users. The settlement between Zoom and the filers of a class-action lawsuit also covers security problems that led to rampant “Zoombombings.”

The proposed settlement would generally give Zoom users $15 or $25 each and was filed Saturday at US District Court for the Northern District of California. It came nine months after Zoom agreed to security improvements and a “prohibition on privacy and security misrepresentations” in a settlement with the Federal Trade Commission, but the FTC settlement didn’t include compensation for users.

As we wrote in November, the FTC said that Zoom claimed it offers end-to-end encryption in its June 2016 and July 2017 HIPAA compliance guides, in a January 2019 white paper, in an April 2017 blog post, and in direct responses to inquiries from customers and potential customers. In reality, “Zoom did not provide end-to-end encryption for any Zoom Meeting that was conducted outside of Zoom’s ‘Connecter’ product (which are hosted on a customer’s own servers), because Zoom’s servers—including some located in China—maintain the cryptographic keys that would allow Zoom to access the content of its customers’ Zoom Meetings,” the FTC said. In real end-to-end encryption, only the users themselves have access to the keys needed to decrypt content.

[…]

Source: Zoom to pay $85M for lying about encryption and sending data to Facebook and Google | Ars Technica

>83 million Web Cams, Baby Monitor Feeds and other IoT devices using Kalay backend Exposed

Posted on by

a vulnerability is lurking in numerous types of smart devices—including security cameras, DVRs, and even baby monitors—that could allow an attacker to access live video and audio streams over the internet and even take full control of the gadgets remotely. What’s worse, it’s not limited to a single manufacturer; it shows up in a software development kit that permeates more than 83 million devices, and over a billion connections to the internet each month.

The SDK in question is ThroughTek Kalay, which provides a plug-and-play system for connecting smart devices with their corresponding mobile apps. The Kalay platform brokers the connection between a device and its app, handles authentication, and sends commands and data back and forth. For example, Kalay offers built-in functionality to coordinate between a security camera and an app that can remotely control the camera angle. Researchers from the security firm Mandiant discovered the critical bug at the end of 2020, and they are publicly disclosing it today in conjunction with the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency.

“You build Kalay in, and it’s the glue and functionality that these smart devices need,” says Jake Valletta, a director at Mandiant. “An attacker could connect to a device at will, retrieve audio and video, and use the remote API to then do things like trigger a firmware update, change the panning angle of a camera, or reboot the device. And the user doesn’t know that anything is wrong.”

The flaw is in the registration mechanism between devices and their mobile applications. The researchers found that this most basic connection hinges on each device’s “UID,” a unique Kalay identifier. An attacker who learns a device’s UID—which Valletta says could be obtained through a social engineering attack, or by searching for web vulnerabilities of a given manufacturer—and who has some knowledge of the Kalay protocol can reregister the UID and essentially hijack the connection the next time someone attempts to legitimately access the target device. The user will experience a few seconds of lag, but then everything proceeds normally from their perspective.

The attacker, though, can grab special credentials—typically a random, unique username and password—that each manufacturer sets for its devices. With the UID plus this login the attacker can then control the device remotely through Kalay without any other hacking or manipulation. Attackers can also potentially use full control of an embedded device like an IP camera as a jumping-off point to burrow deeper into a target’s network.

By exploiting the flaw, an attacker could watch video feeds in real time, potentially viewing sensitive security footage or peeking inside a baby’s crib. They could launch a denial of service attack against cameras or other gadgets by shutting them down. Or they could install malicious firmware on target devices. Additionally, since the attack works by grabbing credentials and then using Kalay as intended to remotely manage embedded devices, victims wouldn’t be able to oust intruders by wiping or resetting their equipment. Hackers could simply relaunch the attack.

“The affected ThroughTek P2P products may be vulnerable to improper access controls,” CISA wrote in its Tuesday advisory. “This vulnerability can allow an attacker to access sensitive information (such as camera feeds) or perform remote code execution. … CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.”

[…]

To defend against exploitation, devices need to be running Kalay version 3.1.10, originally released by ThroughTek in late 2018, or higher. But even the current Kalay SDK version (3.1.5) does not automatically fix the vulnerability. Instead, ThroughTek and Mandiant say that to plug the hole manufacturers must turn on two optional Kalay features: the encrypted communication protocol DTLS and the API authentication mechanism AuthKey.

[…]

“For the past three years, we have been informing our customers to upgrade their SDK,” ThroughTek’s Chen says. “Some old devices lack OTA [over the air update] function which makes the upgrade impossible. In addition, we have customers who don’t want to enable the DTLS because it would slow down the connection establishment speed, therefore are hesitant to upgrade.”

[…]

Source: Millions of Web Camera and Baby Monitor Feeds Are Exposed | WIRED

TCP Firewalls and middleboxes can be weaponized for gigantic DDoS attacks

Posted on by

Authored by computer scientists from the University of Maryland and the University of Colorado Boulder, the research is the first of its kind to describe a method to carry out DDoS reflective amplification attacks via the TCP protocol, previously thought to be unusable for such operations.

Making matters worse, researchers said the amplification factor for these TCP-based attacks is also far larger than UDP protocols, making TCP protocol abuse one of the most dangerous forms of carrying out a DDoS attack known to date and very likely to be abused in the future.

[…]

“DDoS reflective amplification attack.”

This happens when an attacker sends network packets to a third-party server on the internet, the server processes and creates a much larger response packet, which it then sends to a victim instead of the attacker (thanks to a technique known as IP spoofing).

The technique effectively allows attackers to reflect/bounce and amplify traffic towards a victim via an intermediary point.

[…]

The flaw they found was in the design of middleboxes, which are equipment installed inside large organizations that inspect network traffic.

Middleboxes usually include the likes of firewalls, network address translators (NATs), load balancers, and deep packet inspection (DPI) systems.

The research team said they found that instead of trying to replicate the entire three-way handshake in a TCP connection, they could send a combination of non-standard packet sequences to the middlebox that would trick it into thinking the TCP handshake has finished and allow it to process the connection.

[…]

Under normal circumstances, this wouldn’t be an issue, but if the attacker tried to access a forbidden website, then the middlebox would respond with a “block page,” which would typically be much larger than the initial packet—hence an amplification effect.

Following extensive experiments that began last year, the research team said that the best TCP DDoS vectors appeared to be websites typically blocked by nation-state censorship systems or by enterprise policies.

Attackers would send a malformed sequence of TCP packets to a middlebox (firewall, DPI box, etc.) that tried to connect to pornography or gambling sites, and the middlebox would reply with an HTML block page that it would send to victims that wouldn’t even reside on their internal networks—thanks to IP spoofing.

[…]

Bock said the research team scanned the entire IPv4 internet address space 35 different times to discover and index middleboxes that would amplify TCP DDoS attacks.

In total, the team said they found 200 million IPv4 addresses corresponding to networking middleboxes that could be abused for attacks.

Most UDP protocols typically have an amplification factor of between 2 and 10, with very few protocols sometimes reaching 100 or more.

“We found hundreds of thousands of IP addresses that offer [TCP] amplification factors greater than 100×,” Bock and his team said, highlighting how a very large number of networking middleboxes could be abused for DDoS attacks far larger than the UDP protocols with the best amplification factors known to date.

Furthermore, the research team also found thousands of IP addresses that had amplification factors in the range of thousands and even up to 100,000,000, a number thought to be inconceivable for such attacks.

[…]

Bock told The Record they contacted several country-level Computer Emergency Readiness Teams (CERT) to coordinate the disclosure of their findings, including CERT teams in China, Egypt, India, Iran, Oman, Qatar, Russia, Saudi Arabia, South Korea, the United Arab Emirates, and the United States, where most censorship systems or middlebox vendors are based.

The team also notified companies in the DDoS mitigation field, which are most likely to see and have to deal with these attacks in the immediate future.

“We also reached out to several middlebox vendors and manufacturers, including Check Point, Cisco, F5, Fortinet, Juniper, Netscout, Palo Alto, SonicWall, and Sucuri,” the team said.

[…]

the research team also plans to release scripts and tools that network administrators can use to test their firewalls, DPI boxes, and other middleboxes and see if their devices are contributing to this problem. These tools will be available later today via this GitHub repository.

[…]

Additional technical details are available in a research paper titled “Weaponizing Middleboxes for TCP Reflected Amplification” [PDF]. The paper was presented today at the USENIX security conference, where it also received the Distinguished Paper Award.

Source: Firewalls and middleboxes can be weaponized for gigantic DDoS attacks – The Record by Recorded Future