Tag Archives: Apple

Apple Silicon Support on Insight Agent

Post Syndicated from Eugenia Barkova original https://blog.rapid7.com/2021/07/08/apple-m1-support-on-insight-agent/

Apple Silicon Support on Insight Agent

We are pleased to announce the general availability of native support of Apple Silicon chips for the Rapid7 Insight Agent!

The Insight Agent has been fully validated and tested to run on the new Apple Silicon systems natively, and does not require Rosetta 2 to install or operate. This ensures optimal performance for our customers, in contrast to utilizing the Rosetta 2 emulation layer.

Apple announced the first generation Apple Silicon chip—the M1 processor—in November 2020, an 8-core CPU based on the ARM64 architecture. This chip is the new standard on all MacBooks starting with the 2020 releases, and Apple plans to transition completely to Apple Silicon chips over the next two years. For more information, please see Apple’s official release announcement here.

The new Mac installer specifically designed for the Apple Silicon can be accessed right from Agent Management in the platform, in the download section:

Apple Silicon Support on Insight Agent

If customers would like to test the new version of the Agent on select machines before rolling out across their environment, they may do so through the Agent Test Set feature.

We look forward to continually supporting our customers and gathering feedback on this new release!

Apple Will Offer Onion Routing for iCloud/Safari Users

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/06/apple-will-offer-onion-routing-for-icloud-safari-users.html

At this year’s Apple Worldwide Developer Conference, Apple announced something called “iCloud Private Relay.” That’s basically its private version of onion routing, which is what Tor does.

Privacy Relay is built into both the forthcoming iOS and MacOS versions, but it will only work if you’re an iCloud Plus subscriber and you have it enabled from within your iCloud settings.

Once it’s enabled and you open Safari to browse, Private Relay splits up two pieces of information that — when delivered to websites together as normal — could quickly identify you. Those are your IP address (who and exactly where you are) and your DNS request (the address of the website you want, in numeric form).

Once the two pieces of information are split, Private Relay encrypts your DNS request and sends both the IP address and now-encrypted DNS request to an Apple proxy server. This is the first of two stops your traffic will make before you see a website. At this point, Apple has already handed over the encryption keys to the third party running the second of the two stops, so Apple can’t see what website you’re trying to access with your encrypted DNS request. All Apple can see is your IP address.

Although it has received both your IP address and encrypted DNS request, Apple’s server doesn’t send your original IP address to the second stop. Instead, it gives you an anonymous IP address that is approximately associated with your general region or city.

Not available in China, of course — and also Belarus, Colombia, Egypt, Kazakhstan, Saudi Arabia, South Africa, Turkmenistan, Uganda, and the Philippines.

Mysterious Macintosh Malware

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/03/mysterious-macintosh-malware.html

This is weird:

Once an hour, infected Macs check a control server to see if there are any new commands the malware should run or binaries to execute. So far, however, researchers have yet to observe delivery of any payload on any of the infected 30,000 machines, leaving the malware’s ultimate goal unknown. The lack of a final payload suggests that the malware may spring into action once an unknown condition is met.

Also curious, the malware comes with a mechanism to completely remove itself, a capability that’s typically reserved for high-stealth operations. So far, though, there are no signs the self-destruct feature has been used, raising the question of why the mechanism exists.

Besides those questions, the malware is notable for a version that runs natively on the M1 chip that Apple introduced in November, making it only the second known piece of macOS malware to do so. The malicious binary is more mysterious still because it uses the macOS Installer JavaScript API to execute commands. That makes it hard to analyze installation package contents or the way that package uses the JavaScript commands.

The malware has been found in 153 countries with detections concentrated in the US, UK, Canada, France, and Germany. Its use of Amazon Web Services and the Akamai content delivery network ensures the command infrastructure works reliably and also makes blocking the servers harder. Researchers from Red Canary, the security firm that discovered the malware, are calling the malware Silver Sparrow.

Feels government-designed, rather than criminal or hacker.

Another article. And the Red Canary analysis.

New iMessage Security Features

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/01/new-imessage-security-features.html

Apple has added added security features to mitigate the risk of zero-click iMessage attacks.

Apple did not document the changes but Groß said he fiddled around with the newest iOS 14 and found that Apple shipped a “significant refactoring of iMessage processing” that severely cripples the usual ways exploits are chained together for zero-click attacks.

Groß notes that memory corruption based zero-click exploits typically require exploitation of multiple vulnerabilities to create exploit chains. In most observed attacks, these could include a memory corruption vulnerability, reachable without user interaction and ideally without triggering any user notifications; a way to break ASLR remotely; a way to turn the vulnerability into remote code execution;; and a way to break out of any sandbox, typically by exploiting a separate vulnerability in another operating system component (e.g. a userspace service or the kernel).

Impressive iPhone Exploit

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2020/12/impressive-iphone-exploit.html

This is a scarily impressive vulnerability:

Earlier this year, Apple patched one of the most breathtaking iPhone vulnerabilities ever: a memory corruption bug in the iOS kernel that gave attackers remote access to the entire device­ — over Wi-Fi, with no user interaction required at all. Oh, and exploits were wormable­ — meaning radio-proximity exploits could spread from one nearby device to another, once again, with no user interaction needed.


Beer’s attack worked by exploiting a buffer overflow bug in a driver for AWDL, an Apple-proprietary mesh networking protocol that makes things like Airdrop work. Because drivers reside in the kernel — ­one of the most privileged parts of any operating system­ — the AWDL flaw had the potential for serious hacks. And because AWDL parses Wi-Fi packets, exploits can be transmitted over the air, with no indication that anything is amiss.


Beer developed several different exploits. The most advanced one installs an implant that has full access to the user’s personal data, including emails, photos, messages, and passwords and crypto keys stored in the keychain. The attack uses a laptop, a Raspberry Pi, and some off-the-shelf Wi-Fi adapters. It takes about two minutes to install the prototype implant, but Beer said that with more work a better written exploit could deliver it in a “handful of seconds.” Exploits work only on devices that are within Wi-Fi range of the attacker.

There is no evidence that this vulnerability was ever used in the wild.

EDITED TO ADD: Slashdot thread.

Manipulating Systems Using Remote Lasers

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2020/12/manipulating-systems-using-remote-lasers.html

Many systems are vulnerable:

Researchers at the time said that they were able to launch inaudible commands by shining lasers — from as far as 360 feet — at the microphones on various popular voice assistants, including Amazon Alexa, Apple Siri, Facebook Portal, and Google Assistant.


They broadened their research to show how light can be used to manipulate a wider range of digital assistants — including Amazon Echo 3 — but also sensing systems found in medical devices, autonomous vehicles, industrial systems and even space systems.

The researchers also delved into how the ecosystem of devices connected to voice-activated assistants — such as smart-locks, home switches and even cars — also fail under common security vulnerabilities that can make these attacks even more dangerous. The paper shows how using a digital assistant as the gateway can allow attackers to take control of other devices in the home: Once an attacker takes control of a digital assistant, he or she can have the run of any device connected to it that also responds to voice commands. Indeed, these attacks can get even more interesting if these devices are connected to other aspects of the smart home, such as smart door locks, garage doors, computers and even people’s cars, they said.

Another article. The researchers will present their findings at Black Hat Europe — which, of course, will be happening virtually — on December 10.

Hacking Apple for Profit

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2020/10/hacking-apple-for-profit.html

Five researchers hacked Apple Computer’s networks — not their products — and found fifty-five vulnerabilities. So far, they have received $289K.

One of the worst of all the bugs they found would have allowed criminals to create a worm that would automatically steal all the photos, videos, and documents from someone’s iCloud account and then do the same to the victim’s contacts.

Lots of details in this blog post by one of the hackers.

ThiefQuest Ransomware for the Mac

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2020/07/thiefquest_rans.html

There’s a new ransomware for the Mac called ThiefQuest or EvilQuest. It’s hard to get infected:

For your Mac to become infected, you would need to torrent a compromised installer and then dismiss a series of warnings from Apple in order to run it. It’s a good reminder to get your software from trustworthy sources, like developers whose code is “signed” by Apple to prove its legitimacy, or from Apple’s App Store itself. But if you’re someone who already torrents programs and is used to ignoring Apple’s flags, ThiefQuest illustrates the risks of that approach.

But it’s nasty:

In addition to ransomware, ThiefQuest has a whole other set of spyware capabilities that allow it to exfiltrate files from an infected computer, search the system for passwords and cryptocurrency wallet data, and run a robust keylogger to grab passwords, credit card numbers, or other financial information as a user types it in. The spyware component also lurks persistently as a backdoor on infected devices, meaning it sticks around even after a computer reboots, and could be used as a launchpad for additional, or “second stage,” attacks. Given that ransomware is so rare on Macs to begin with, this one-two punch is especially noteworthy.

iPhone Apps Stealing Clipboard Data

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2020/06/iphone_apps_ste.html

iOS apps are repeatedly reading clipboard data, which can include all sorts of sensitive information.

While Haj Bakry and Mysk published their research in March, the invasive apps made headlines again this week with the developer beta release of iOS 14. A novel feature Apple added provides a banner warning every time an app reads clipboard contents. As large numbers of people began testing the beta release, they quickly came to appreciate just how many apps engage in the practice and just how often they do it.

This YouTube video, which has racked up more than 87,000 views since it was posted on Tuesday, shows a small sample of the apps triggering the new warning.

EDITED TO ADD (7/6): LinkedIn and Reddit are doing this.

Приложенията за проследяване на контакти са лоша идея

Post Syndicated from Yovko Lambrev original https://yovko.net/contact-tracing-apps-bad-idea/

Напоследък свикнахме, че едва ли не за всеки проблем около нас може да бъде намерено „високотехнологично“ софтуерно решение. Не искам да влизам в непродуктивни дискусии дали ИТ бизнесът прекрачва границите на почтеността, промотирайки се като всемогъщ. Но е факт, че малцина са тези, които признават глупостите, сътворени от същата тази иначе перспективна индустрия. Няма да крия, че като insider, личното ми мнение е, че отдавна са преминати доста граници.

Поредната много опасна идея със съмнителни ползи, но пък безспорни рискове, е проследяването на контактите между хората чрез приложения на „умните“ им телефони. Още по-опасно е, че зад нея застанаха и двете гигантски компании Apple и Google, които в момента притежават 99,5% от пазара на мобилни операционни системи.

Идеята дойде в отговор на очакванията (а не е изключен и политически натиск), че с помощта на технологично проследяване на контактите между хората може да се контролира по-бързо или по-ефективно разпространението на новия коронавирус сред тях. На първо четене една изключително хуманна идея. Проблемът е, че технооптимистите обикновено създават и тестват идеите си в контролирана лабораторна среда. Но когато се окаже, че пусната в реалния живот, същата идея носи повече вреди, отколкото ползи, те свиват рамене и отказват да носят отговорност. Пикльото Зукърбърг е класически пример.

Ползвателите на Android са си по презумпция прецакани, защото благодарение на телефоните си така или иначе отдавна са се превърнали в донори на данни за Google. Ползвателите на iOS досега имаха някакви основания да допускат, че може би водят една идея по-защитено съществуване на уютния остров на Apple. Но след няколко дни (когато излезе iOS 13.5) и те ще трябва да се разделят с тази илюзия. При това „ябълковата“ компания ще го направи по най-свинския възможен начин – забавяйки критична поправка в сигурността, за да я комбинира с новото API за проследяване на контактите в едно обновление. Иначе казано, Apple оставя потребителите си без особен избор, без чиста корекция на пробитата версия 13.4.1.

Какво възнамеряват да направят Apple и Google, при това заедно и съгласувано?

Всъщност те няма да пускат приложения за проследяване на контактите, както масово неправилно се твърди. Това, което ще добавят към операционните си системи, е т.нар. приложен програмен интерфейс (API), който ще може да бъде използван от разработчиците за създаване на приложения. Програмните интерфейси обслужват различни цели – чрез тях програмистите могат да реализират едни или други функционалности в своите приложения, използвайки възможностите на телефона, операционната система или външни услуги. Например могат да „питат“ GPS-а на телефона за географската му локация, да я покажат на картата, да я добавят към снимка, която камерата прави, и други такива неща.

Новият програмен интерфейс е замислен да прави следното: Нали сте обръщали внимание как когато пуснете bluetooth-а на своя телефон (за да закачите слушалките си например), обикновено виждате една купчина други устройства, които са близо до вас в момента? Обикновено bluetooth работи едва до няколко метра. Напоследък той използва пренебрежимо малко енергия от батерията и за удобство е пуснат по подразбиране на повечето съвременни телефони. Е, това стои в основата на идеята да проследяваме разпространението на вируса, причиняващ COVID-19.

Докато се разхождаме с телефоните си, те ще „подслушват“ кои други телефони около нас са в достатъчна близост за достатъчно дълго време и ще си обменят анонимни (или анонимизирани) идентификатори. Тук има две важни думички – едната е анонимни, другата е идентификатори. Чувствате ли иронията в словосъчетанието анонимни идентификатори? Но нека засега останем хладнокръвни и добронамерени към тази идея за спасяване на човечеството с апове.

Та, значи, вие си ходите по улицата или на работа, или другаде, срещате се с някакви хора, и когато вашето телефонче „чуе“ наблизо bluetooth-а на друг телефон, той си записва този факт. Важно е да уточним, че ни обещават, че няма да се записва локацията, телефонния номер или „айфона на Пешо Михайлов“, а вместо това ще запамети само някакво (да кажем) число, което има за цел да съответства на въпросния телефон, и така едновременно имаме следа, но сме анонимизирали притежателя. Телефоните на всички останали около нас, също си водят бележки, че сме се срещали.

Наричаме тези „числа“ анонимизирани идентификатори, защото ако ги погледнем разписани, няма как да разберем кое на чий телефон съответства. Списъците с такива числа се пазят само в телефона, който ги е събрал. Не се изпращат никъде (засега). Това поредно обещание е важен елемент от идеята, което има за цел да ни успокои, че всъщност са взети мерки цялото това нещо да не изглежда толкова страшно, колкото в действителност е. Или поне да не изглежда твърде лесно да се стигне до извода, че Мишо се е срещнал с Мими посреднощ миналата сряда и… нали…

Всъщност Apple и Google „водиха битка“ с нагласите на няколко правителства (вкл. европейски), които искаха тези данни да се изпращат централизирано към някакви национални сървъри и да се споделят (уж само) със здравните служби, но евентуално и с полицията, ако се налага да се издирват хора. Дори само последното е безумно потвърждение по колко тънък лед се движим с напъните да се реализират такива идеи.

Но как използваме това, че телефоните ни знаят с кои други телефони сме били наблизо?

Те ще пазят списъка от идентификатори, с които сме се срещали за някакъв период от време (две седмици). Ако междувременно някой от хората, с които сме били в близост, се разболее или си направи тест, който се окаже положителен, той/тя може да отбележи това чрез своето приложение, а неговият телефонен идентификатор (т.е. онова число) ще бъде обявено за обвързано със заразен човек и разпространено до всички устройства в системата. Така ако останалите телефони открият такъв идентификатор в своя локален списък от последните две седмици, ще алармират притежателите си, че са били в близък контакт с болен или заразен, и ще им препоръчат да си направят тест. Без да им казват кой точно е този контакт, защото не знаят това.

Всичко изглежда като умно и работещо решение, което пък може би наистина би помогнало за по-ефективно и бързо проследяване на пътя на заразата и евентуалното ѝ контролиране, без твърде много да заплашва личната неприкосновеност на хората. И щеше да е така при следните условия:

  • ако наистина всичко се случва точно по този начин, както ни го обещават и си го представяме;
  • ако можехме да вярваме, че Apple и Google наистина реализират този алгоритъм добронамерено, без никакви неволни или нарочни грешки в реализацията, или скрити функционалности за други цели;
  • ако bluetooth технологията нямаше несъвършенства, част от които ще разгледаме след малко;
  • ако всички ползватели са добронамерени и коректни, не подават грешна информация или не спестяват такава;
  • ако можеше да се вярва на правителствата, че няма да притискат гражданите си да използват системата против тяхното желание… или че няма да притиснат Google и Apple да променят реализацията си в бъдеще;
  • ако не съществуваха рискове събирането на други данни (напр. от телекомите) да се комбинира по начин, който да разкрива самоличността на хората;
  • ако знаехме повече за механизма на заразяване, който все още е обвит в мъгла от допускания;
  • ако…

Разбира се, че е съблазняваща идеята да използваме модерните технологии, за да намерим изход от ситуацията, в която попаднахме. Евентуално да спасим човешки животи и по-бързо да се започне с възстановяване на икономиката на целия свят.

Само че идеята на Google и Apple крие много подводни камъни и рискове, които неутрализират повечето ползи

Основният проблем е свързан с това, че още не знаем колко точно време един заразен човек може да заразява други здрави хора. Нито сме сигурни за началния или крайния момент на този период. Което прави трудно преценяването доколко е вероятно да сме пипнали вируса, ако сме били в непосредствена близост с човек, който се е оказал заразен няколко дни след нашата среща. Учените още не са напълно сигурни и дали заразата се предава чрез повърхности и предмети или само по въздушно-капков път. Предполага се, че трябва да се позастоим около заразен човек, но не знаем колко точно е това време. Също логично е и да е по-вероятно да се заразим в затворено помещение, отколкото на открито, но… все още и за това няма категорично потвърждение.

И на фона на тези неясноти нека добавим несъвършенствата на bluetooth технологията. Можем да правим обосновани допускания за разстоянието между две устройства, които се „чуват“ по bluetooth, съдейки по затихването на сигнала, понеже силата му намалява пропорционално на разстоянието между тях. Само че сигналът затихва различно, ако телефонът е в ръката, в джоба, в дамска чанта или между двете устройства има стена или някаква друга преграда. Това прави опитът да преценим колко близо са две такива устройства в безбройните възможни делнични ситуации доста условен.

В добавка към това, различните устройства ползват различни като качество чипове – т.е. някои ще си общуват по-добре от други. Някои от по-евтините модели понякога пък трудно се „разбират“ със себеподобни. Отново в зависимост от несъвършенствата на конкретни модели някои остават „свързани“ далеч след като това отдавна не е така. Други пък имат нужда от много дълго време да „открият“, че са във връзка.

Всичко това би изкривило изключително много преценката колко точно време и в каква реална близост сме били с телефона на един или друг човек. И не на последно място – няма как чрез bluetooth да преценим дали сме на закрито и открито. А на опашка на открито при спазване на изискваната дистанция от 1,5-2 метра е много вероятно телефоните ви да решат, че сте достатъчно дълго време и достатъчно близо един до друг.

Нека към това да добавим човешкия фактор. Това, че нашият телефон е регистрирал близост с друг, не означава по никакъв начин, че настина самите хора са били наблизо. Простички ситуации, които са напълно реални:

  • Домът ви или офисът ви са в непосредствена близост до оживен тротоар или още по-зле – до друг офис или магазин. Почти сигурно е, че телефонът ви, оставен на бюрото или на прозореца, ще регистрира множество други устройства на хора, преминаващи по улицата, пазаруващи в магазина или работещи през една стена от вас в съседния офис, с които обаче вие реално може никога да не сте имали никакъв контакт. Дори да филтрираме твърде краткотрайните взаимодействия (преминаващите по тротоара например), пак остават достатъчно поводи да получите фалшиви предупреждения, че сте били в контакт със заразен. Хайде сега си представете, че живеете в съседство на чакалня пред лекарски кабинет, на баничарница или на местната данъчна служба.
  • Имаме и обратната възможна ситуация – куриер ви носи пратка на петия етаж, но си е оставил телефона в буса долу на улицата. Реално имате контакт, особено ако допуснем, че зараза чрез предмети е възможна, но телефоните ви ще пропуснат да регистрират този факт.

Към това нека добавим човешката злонамереност. Какво, мислите, ще възпрепятства някакъв кретен да се разхожда активно насам-натам и да се отбележи след няколко дни като заразен, без това да е вярно? Нищо, разбира се. Само веднъж да го направи, ще провокира фалшива тревожност и ще засили мнозина към самоизолация или тестващи центрове, където не е изключена вероятността да се заразят наистина при евентуална среща с други заразени (или да последва вторична вълна от предупреждения след срещата с техните телефони, които също са били наблизо).

Представяте ли си изживяването, когато един ден се събуждате и на телефона ви изгрява съобщението: „Предупреждаваме ви, че през последните дни сте били в непосредствена близост с човек, който е потвърдил, че е заразен/болен от COVID-19. Съветваме ви да се самоизолирате и/или да се тествате.“ Пожелавам ви спокойни няколко следващи дни… и нощи!

А сега си представете, че това започне да ви се случва през 2-3 дни. Не е изключено – например ако работите на гише в банка, а телефонът ви е бил до вас зад преградата и е насъбрал… „контакти“. Колко пъти ще излезете в неплатен отпуск за самоизолация или ще се тествате? И след колко случая ще започнете да пренебрегвате предупрежденията? А ако точно някое от следващите предупреждения е вярно?

Всъщност при евентуално неблагоприятно развихряне на заразата такава система може да ви подлуди с фалшиви тревоги (окей, може и с истински).

И отново имаме обратния проблем – при непрецизна реализация (а всичко по-горе е изписано, за да обясни, че не е лесно да бъде прецизна) по-опасно от фалшивите тревоги може да е фалшивото спокойствие. Нека не забравяме, че не всички хора ще участват в тази платформа – и не за всички въпросът дали да го направят е свързан единствено с тяхното желание. Някои може и да нямат възможност.

Миналата година излязоха доста оптимистични резултати от проучване, според което 97% от българите имат мобилен телефон, а 74% от тях пък ползват смартфон (доколко го ползват наистина като смартфон, е друга тема). Има един закон на Metcalfe, с който се оценява т.нар. „мрежови ефект“ на една комуникационна мрежа – той гласи, че този ефект е пропорционален на квадрата на броя на свързаните устройства. В резюме от него следва, че дори всички, които имат смартфони, да си инсталират приложението и то да работи перфектно, не можем да достигнем дори до 50-60% от събитията, при които е възможно да е прескочила зараза.

Човешката злонамереност е проблем, но да не забравяме и човешката немарливост. Каква би била мотивацията на някого да признае пред някакво приложение, че е заразен или болен от COVID-19? Грижата за другите? А ако това е свързано с притеснения за стигматизиране или реална заплаха да загуби прехраната си? А ако просто е твърде уплашен и изобщо не му е до другите, или се престраши да рапортува чак 5-6 или 10 дни след теста си, а междувременно данните за близостта с неговия телефон в голяма част от телефоните на останалите вече са заличени, защото е изминало критично време?

Вирусът е коварен – няма две мнения. Но колкото и да изглежда страшно, че коефицентът му на препредаване е висок, все пак засега изглежда, че един болен не заразява средно повече от двама-трима други и при отсъствие на мерки за дистанциране (това всъщност е адски много, но и за реалния коефициент също не сме напълно сигурни, понеже данните, с които се борави към момента, не са прецизни). Има анализи, които твърдят, че среднодневните контакти на средностатистически човек са около 12. Т.е. е много вероятно да срещнем заразен в ежедневието си, но далеч по-малко вероятно е наистина да се заразим при тази среща. Иначе казано, системата за проследяване е предварително дефинирана като такава, която с цел превенция ще прекалява с фалшивите предупреждения.

Вероятните злоупотреби с тази технология никак не са малко. Първо на Apple, а особено на Google няма никаква причина да се има каквото и да било доверие. Те обещават, че ще забраняват на разработчиците, които ползват тази технология, да я комбинират с други, съчетанието между които би могло да разкрие самоличността на хората, но… и това е заобиколимо. Простичък и относително лесно осъществим подход е да монтираме на оживено място, примерно до касата на един магазин два телефона – единият е в анти-COVID-19 системата и събира „контакти“, а другият е с пусната камера и прави снимки или записва видео.

Колко е трудно да се съпоставят лицата на хората пред касата със събраните идентификатори от другия телефон на база на времето, в което са били там? Ами елементарно е. Ако пък са ползвали карта за лоялност и отстъпка, даже имената, адресът и мобилният им телефон ще са в базата на магазина. Да, да… знам че това би било нарушение на закона и злоупотреба с GDPR, но идете го доказвайте, ако ви се случи. На мен ми отне цяла година за институционално признание, че някой очевидно е фалшифицирал мой подпис.

Ако се върнем към възможните злоупотреби, може и да поразсъждваме колко лесно е да се създаде чрез манипулация на системата „огнище на зараза“ в заведението или магазина на конкурент?

Apple и Google обещават, че всеки ще може да активира или деактивира тази функционалност. Проблемът е, че в една от предварителните бета-версии на следващото обновление на iOS бе забелязано, че това е включено по подразбиране. Макар и да е нужно допълнително оторизирано приложение, за да се събират данни, това задава лош наклон на пързалката. (Точно преди малко Apple коригираха това и сега е изключено по подразбиране.) Никой не би могъл да гарантира, че тази технология няма да „остане“ в телефоните и след края на кризата с новия коронавирус. Или че няма да се измисли друго нейно приложение с още по-неприятни ефекти върху личната неприкосновеност. Със сигурност никой не следва да бъде принуждаван да го ползва.

Затова хайде по-внимателно с технооптимизма! Проследяването на контактите по класическия начин може да е бавно и да изглежда неефективно, но е прецизно, докато аутсорсването на този ангажимент по неудачен начин на някаква си технология, която по замисъл има съвсем друго предназначение, води до купчина нови проблеми. При това застрашаващи човешки права, личната неприкосновеност на хората и е с повишен риск за тези от малцинствени, стигматизирани или маргинализирани групи. Още повече че тази идея пропълзя от страни като Израел, Южна Корея и Сингапур, никоя от които не може да се посочи за пример по отношение на човешките права.

Технологични идеи и ресурси в момента са нужни на учените, които търсят ваксина и лечение. Има нужда от софтуерни решения за здравните системи по света. У нас например още няма електронни здравни картони, нито електронни рецепти. Те ще са полезни и след пандемията. Технозаигравките с инструменти за проследяване на контактите между хората са опасни по презумпция, съмнително е, че изобщо ще свършат някаква работа и заслужават всяка съпротива срещу тях.

Допълнено на 8 май 2020:

Вчера, сякаш в подкрепа на написаното по-горе беше публикуван кода на приложенията за iOS и Android, които ще се ползват във Великобритания. И какво се вижда на първо четене (via Aral Balkan):

  • Публикуван е изходния код само на мобилните приложения, без този на сървъра, а всъщност е далеч по-важно да се знае какво се случва там. Иначе казано това изглежда като хитър PR ход, който дава възможност на недоклатени бюрократчета да твърдят, че „кодът е публикуван“ и да заблуждават народонаселението, че всичко е прозрачно, а то не е.
  • Всъщност, без допълнителен независим одит не може да се потвърди, че приложенията, които ще бъдат разпространени за използване от хората, наистина ще бъдат компилирани от точно този публикуван код. Може да се публикува едно, а в действителност да се използва друго.
  • От публикувания код личи, че приложенията събират марката, модела и UUID идентификаторите на телефоните, което отваря врати за деанонимизиране на потребителя.
  • Приложенията използват база-данни Firebase на Google в облака. Честито! Данните отиват точно където трябва и където най-лесно могат да бъдат съпоставени с други, деанонимизирани, анализирани, профилирани и т.н.
  • И понеже това не стига, приложенията ползват и Microsoft Analytics, за да може и още един tech-гигант да се отърка. Още веднъж честито! И наздраве!

Допълнено на 13 юни 2020: Ами… не работело добре, споделят британците.

Иначе казано, продължавайте да се предоверявате на технооптимистите и на шибаните правителства!

Contact Tracing COVID-19 Infections via Smartphone Apps

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2020/04/contact_tracing.html

Google and Apple have announced a joint project to create a privacy-preserving COVID-19 contact tracing app. (Details, such as we have them, are here.) It’s similar to the app being developed at MIT, and similar to others being described and developed elsewhere. It’s nice seeing the privacy protections; they’re well thought out.

I was going to write a long essay about the security and privacy concerns, but Ross Anderson beat me to it. (Note that some of his comments are UK-specific.)

First, it isn’t anonymous. Covid-19 is a notifiable disease so a doctor who diagnoses you must inform the public health authorities, and if they have the bandwidth they call you and ask who you’ve been in contact with. They then call your contacts in turn. It’s not about consent or anonymity, so much as being persuasive and having a good bedside manner.

I’m relaxed about doing all this under emergency public-health powers, since this will make it harder for intrusive systems to persist after the pandemic than if they have some privacy theater that can be used to argue that the whizzy new medi-panopticon is legal enough to be kept running.

Second, contact tracers have access to all sorts of other data such as public transport ticketing and credit-card records. This is how a contact tracer in Singapore is able to phone you and tell you that the taxi driver who took you yesterday from Orchard Road to Raffles has reported sick, so please put on a mask right now and go straight home. This must be controlled; Taiwan lets public-health staff access such material in emergencies only.

Third, you can’t wait for diagnoses. In the UK, you only get a test if you’re a VIP or if you get admitted to hospital. Even so the results take 1-3 days to come back. While the VIPs share their status on twitter or facebook, the other diagnosed patients are often too sick to operate their phones.

Fourth, the public health authorities need geographical data for purposes other than contact tracing – such as to tell the army where to build more field hospitals, and to plan shipments of scarce personal protective equipment. There are already apps that do symptom tracking but more would be better. So the UK app will ask for the first three characters of your postcode, which is about enough to locate which hospital you’d end up in.

Fifth, although the cryptographers – and now Google and Apple – are discussing more anonymous variants of the Singapore app, that’s not the problem. Anyone who’s worked on abuse will instantly realise that a voluntary app operated by anonymous actors is wide open to trolling. The performance art people will tie a phone to a dog and let it run around the park; the Russians will use the app to run service-denial attacks and spread panic; and little Johnny will self-report symptoms to get the whole school sent home.

I recommend reading his essay in full. Also worth reading are this EFF essay, and this ACLU white paper.

To me, the real problems aren’t around privacy and security. The efficacy of any app-based contact tracing is still unproven. A “contact” from the point of view of an app isn’t the same as an epidemiological contact. And the ratio of infections to contacts is high. We would have to deal with the false positives (being close to someone else, but separated by a partition or other barrier) and the false negatives (not being close to someone else, but contracting the disease through a mutually touched object). And without cheap, fast, and accurate testing, the information from any of these apps isn’t very useful. So I agree with Ross that this is primarily an exercise in that false syllogism: Something must be done. This is something. Therefore, we must do it. It’s techies proposing tech solutions to what is primarily a social problem.

EDITED TO ADD: Susan Landau on contact tracing apps and how they’re being oversold. And Farzad Mostashari, former coordinator for health IT at the Department of Health and Human Services, on contact tracing apps.

As long as 1) every contact does not result in an infection, and 2) a large percentage of people with the disease are asymptomatic and don’t realize they have it, I can’t see how this sort of app is valuable. If we had cheap, fast, and accurate testing for everyone on demand…maybe. But I still don’t think so.

EDITED TO ADD (4/15): More details from Apple and Google.

Hacking Voice Assistants with Ultrasonic Waves

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2020/03/hacking_voice_a_1.html

I previously wrote about hacking voice assistants with lasers. Turns you can do much the same thing with ultrasonic waves:

Voice assistants — the demo targeted Siri, Google Assistant, and Bixby — are designed to respond when they detect the owner’s voice after noticing a trigger phrase such as ‘Ok, Google’.

Ultimately, commands are just sound waves, which other researchers have already shown can be emulated using ultrasonic waves which humans can’t hear, providing an attacker has a line of sight on the device and the distance is short.

What SurfingAttack adds to this is the ability to send the ultrasonic commands through a solid glass or wood table on which the smartphone was sitting using a circular piezoelectric disc connected to its underside.

Although the distance was only 43cm (17 inches), hiding the disc under a surface represents a more plausible, easier-to-conceal attack method than previous techniques.

Research paper. Demonstration video.

Companies that Scrape Your Email

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2020/02/companies_that_.html

Motherboard has a long article on apps — Edison, Slice, and Cleanfox — that spy on your email by scraping your screen, and then sell that information to others:

Some of the companies listed in the J.P. Morgan document sell data sourced from “personal inboxes,” the document adds. A spokesperson for J.P. Morgan Research, the part of the company that created the document, told Motherboard that the research “is intended for institutional clients.”

That document describes Edison as providing “consumer purchase metrics including brand loyalty, wallet share, purchase preferences, etc.” The document adds that the “source” of the data is the “Edison Email App.”


A dataset obtained by Motherboard shows what some of the information pulled from free email app users’ inboxes looks like. A spreadsheet containing data from Rakuten’s Slice, an app that scrapes a user’s inbox so they can better track packages or get their money back once a product goes down in price, contains the item that an app user bought from a specific brand, what they paid, and an unique identification code for each buyer.

Apple’s Tracking-Prevention Feature in Safari has a Privacy Bug

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2020/02/apples_tracking.html

Last month, engineers at Google published a very curious privacy bug in Apple’s Safari web browser. Apple’s Intelligent Tracking Prevention, a feature designed to reduce user tracking, has vulnerabilities that themselves allow user tracking. Some details:

ITP detects and blocks tracking on the web. When you visit a few websites that happen to load the same third-party resource, ITP detects the domain hosting the resource as a potential tracker and from then on sanitizes web requests to that domain to limit tracking. Tracker domains are added to Safari’s internal, on-device ITP list. When future third-party requests are made to a domain on the ITP list, Safari will modify them to remove some information it believes may allow tracking the user (such as cookies).


The details should come as a surprise to everyone because it turns out that ITP could effectively be used for:

  • information leaks: detecting websites visited by the user (web browsing history hijacking, stealing a list of visited sites)
  • tracking the user with ITP, making the mechanism function like a cookie
  • fingerprinting the user: in ways similar to the HSTS fingerprint, but perhaps a bit better

I am sure we all agree that we would not expect a privacy feature meant to protect from tracking to effectively enable tracking, and also accidentally allowing any website out there to steal its visitors’ web browsing history. But web architecture is complex, and the consequence is that this is exactly the case.

Apple fixed this vulnerability in December, a month before Google published.

If there’s any lesson here, it’s that privacy is hard — and that privacy engineering is even harder. It’s not that we shouldn’t try, but we should recognize that it’s easy to get it wrong.

Apple Abandoned Plans for Encrypted iCloud Backup after FBI Complained

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2020/01/apple_abandoned.html

This is new from Reuters:

More than two years ago, Apple told the FBI that it planned to offer users end-to-end encryption when storing their phone data on iCloud, according to one current and three former FBI officials and one current and one former Apple employee.

Under that plan, primarily designed to thwart hackers, Apple would no longer have a key to unlock the encrypted data, meaning it would not be able to turn material over to authorities in a readable form even under court order.

In private talks with Apple soon after, representatives of the FBI’s cyber crime agents and its operational technology division objected to the plan, arguing it would deny them the most effective means for gaining evidence against iPhone-using suspects, the government sources said.

When Apple spoke privately to the FBI about its work on phone security the following year, the end-to-end encryption plan had been dropped, according to the six sources. Reuters could not determine why exactly Apple dropped the plan.

ToTok Is an Emirati Spying Tool

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2019/12/totok_is_an_emi.html

The smartphone messaging app ToTok is actually an Emirati spying tool:

But the service, ToTok, is actually a spying tool, according to American officials familiar with a classified intelligence assessment and a New York Times investigation into the app and its developers. It is used by the government of the United Arab Emirates to try to track every conversation, movement, relationship, appointment, sound and image of those who install it on their phones.

ToTok, introduced only months ago, was downloaded millions of times from the Apple and Google app stores by users throughout the Middle East, Europe, Asia, Africa and North America. While the majority of its users are in the Emirates, ToTok surged to become one of the most downloaded social apps in the United States last week, according to app rankings and App Annie, a research firm.

Apple and Google have removed it from their app stores. If you have it on your phone, delete it now.

Fooling Voice Assistants with Lasers

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2019/11/fooling_voice_a.html


Siri, Alexa, and Google Assistant are vulnerable to attacks that use lasers to inject inaudible­ — and sometimes invisible­ — commands into the devices and surreptitiously cause them to unlock doors, visit websites, and locate, unlock, and start vehicles, researchers report in a research paper published on Monday. Dubbed Light Commands, the attack works against Facebook Portal and a variety of phones.

Shining a low-powered laser into these voice-activated systems allows attackers to inject commands of their choice from as far away as 360 feet (110m). Because voice-controlled systems often don’t require users to authenticate themselves, the attack can frequently be carried out without the need of a password or PIN. Even when the systems require authentication for certain actions, it may be feasible to brute force the PIN, since many devices don’t limit the number of guesses a user can make. Among other things, light-based commands can be sent from one building to another and penetrate glass when a vulnerable device is kept near a closed window.

Massive iPhone Hack Targets Uyghurs

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2019/09/massive_iphone_.html

China is being blamed for a massive surveillance operation that targeted Uyghur Muslims. This story broke in waves, the first wave being about the iPhone.

Earlier this year, Google’s Project Zero found a series of websites that have been using zero-day vulnerabilities to indiscriminately install malware on iPhones that would visit the site. (The vulnerabilities were patched in iOS 12.1.4, released on February 7.)

Earlier this year Google’s Threat Analysis Group (TAG) discovered a small collection of hacked websites. The hacked sites were being used in indiscriminate watering hole attacks against their visitors, using iPhone 0-day.

There was no target discrimination; simply visiting the hacked site was enough for the exploit server to attack your device, and if it was successful, install a monitoring implant. We estimate that these sites receive thousands of visitors per week.

TAG was able to collect five separate, complete and unique iPhone exploit chains, covering almost every version from iOS 10 through to the latest version of iOS 12. This indicated a group making a sustained effort to hack the users of iPhones in certain communities over a period of at least two years.

Four more news stories.

This upends pretty much everything we know about iPhone hacking. We believed that it was hard. We believed that effective zero-day exploits cost $2M or $3M, and were used sparingly by governments only against high-value targets. We believed that if an exploit was used too frequently, it would be quickly discovered and patched.

None of that is true here. This operation used fourteen zero-days exploits. It used them indiscriminately. And it remained undetected for two years. (I waited before posting this because I wanted to see if someone would rebut this story, or explain it somehow.)

Google’s announcement left out of details, like the URLs of the sites delivering the malware. That omission meant that we had no idea who was behind the attack, although the speculation was that it was a nation-state.

Subsequent reporting added that malware against Android phones and the Windows operating system were also delivered by those websites. And then that the websites were targeted at Uyghurs. Which leads us all to blame China.

So now this is a story of a large, expensive, indiscriminate, Chinese-run surveillance operation against an ethnic minority in their country. And the politics will overshadow the tech. But the tech is still really impressive.

EDITED TO ADD: New data on the value of smartphone exploits:

According to the company, starting today, a zero-click (no user interaction) exploit chain for Android can get hackers and security researchers up to $2.5 million in rewards. A similar exploit chain impacting iOS is worth only $2 million.

EDITED TO ADD (9/6): Apple disputes some of the claims Google made about the extent of the vulnerabilities and the attack.

EDITED TO ADD (9/7): More on Apple’s pushbacks.