<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Is there possibility of theoretical attack where attacker tries to spoofs randomized MAC sniffed from air and central responds as if it was original device?</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/105244/is-there-possibility-of-theoretical-attack-where-attacker-tries-to-spoofs-randomized-mac-sniffed-from-air-and-central-responds-as-if-it-was-original-device</link><description>Hi, 
 
 we are developing nRF52833-based peripheral (and nRF52840 is also used for testing), there will be a large batch when in production. 
 
 Someone asked if following attack is possible on BLE, where peripheral is nRF52833 and central is phone or</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Thu, 02 Nov 2023 01:13:36 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/105244/is-there-possibility-of-theoretical-attack-where-attacker-tries-to-spoofs-randomized-mac-sniffed-from-air-and-central-responds-as-if-it-was-original-device" /><item><title>RE: Is there possibility of theoretical attack where attacker tries to spoofs randomized MAC sniffed from air and central responds as if it was original device?</title><link>https://devzone.nordicsemi.com/thread/453601?ContentTypeID=1</link><pubDate>Thu, 02 Nov 2023 01:13:36 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:21569fd5-3dfa-45e4-b9d2-364d11ae12d1</guid><dc:creator>viktor.kz</dc:creator><description>&lt;p&gt;JFC it deleted both my comments. But in short I figured it out I think and found out that if we have both LESC and internal AES-GCM tunnel, then this attack won&amp;#39;t work. There is also stuff with attacker doing right SN/NESN, making right channel hop and broadcasting to the right channel (I have SDR&amp;nbsp; - HackRF+PortaPack H2 and ADALM PLUTO, so I can just record and replay to test it). With &amp;quot;just works pairing&amp;quot; it would be different.&lt;/p&gt;
&lt;p&gt;I also very much use Nordic BLE Sniffer, amazing tool, thanks for that.&lt;/p&gt;
&lt;p&gt;The attack depends on phase - legit central and peripheral are connected, legit central and peripheral are transmitting, BLE MAC has rolled out after 15 minutes and legit peripheral is no longer connected.&lt;/p&gt;
&lt;p&gt;Attacker wants to insert his packets into radio stream, and/or use social engineering to bond his device with faked MAC to central (but user/victim would have to make forget bonds, so it won&amp;#39;t work as easily). But as I said wih LESC and internal AES-GCM tunnel this attack won&amp;#39;t work.&lt;/p&gt;
&lt;p&gt;Also I have 100% reliable stack smashing attack on iOS via BLE (tested on 16.x and even latest 17.1), it bricks iPhones so you have to reboot (iPad iOS 16.6 tested was broken a bit, BLE stopped working, but no lockup). It&amp;#39;s already reported to Apple, but there is someone with Corellium or dev jailbroken iPhone (you can get it from Apple for $$$ and lot of paperwork) trying to make exploit chain, I bet. The stack smashing attack need less than 30 seconds to work. It works via different messages on Android with custom pictures shown, and also Windows. Seen iOS and Android, didn&amp;#39;t test Windows, but I&amp;#39;d bet it&amp;#39;d work.&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;It&amp;#39;s public already so no need for secrecy, but work 100% reliably as I said, tested on several devices -&amp;nbsp;&lt;a href="https://www.mobile-hacker.com/2023/10/17/spam-ios-android-and-windows-with-bluetooth-pairing-messages-using-flipper-zero-or-android-smartphone/#google_vignette"&gt;www.mobile-hacker.com/.../&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;But I found this - is IRK transmitted in clear text during bonding phase or is it encrypted with LTK or some other key? Because if it&amp;#39;s transmitted in plaintext, then &lt;strong&gt;attacker can forever know IRK follow and resolve the MAC address&lt;/strong&gt;, is this correct, or am I wrong? According to BLE specification?&lt;/p&gt;
&lt;p&gt;&lt;img src="https://i.imgur.com/eg26XD4.png" alt=" " /&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Is there possibility of theoretical attack where attacker tries to spoofs randomized MAC sniffed from air and central responds as if it was original device?</title><link>https://devzone.nordicsemi.com/thread/453499?ContentTypeID=1</link><pubDate>Wed, 01 Nov 2023 12:39:23 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:aaab1e9a-ca3d-4ed0-87f3-c1fa41b689e1</guid><dc:creator>Kenneth</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;This topic is too complex and difficult to cover in any reasonable way in a devzone ticket, what I would like to say is that BT SIG takes security very importantly, and when and if there are weaknesses found by third party&amp;nbsp;then BT SIG (or the manufacturer) follow up immediatly to ensure those weaknesses are handled in any future specifications work. Typically manufacturers of such devices can then implement the solution (e.g. update to a new release of the sdk) and perfom an DFU of their product to ensure it&amp;#39;s closed. But to answer your question is specific:&lt;/p&gt;
[quote user=""]Is this MAC spoofing going to work? What if the attacker uses the replay of saved packet after 15 minutes, when central already has different MAC, is central going to resolve it or deny it?[/quote]
&lt;p&gt;No, the packet will be disregarded. There are random numbers exchanged when an encrypted link is established and counters during connection to ensure that any replayed/injected packet will be fail message integrity check and thereby disregarded (as with any other packet that is failed to be received).&lt;/p&gt;
&lt;p&gt;As a developer I recommend to check release notes of new sdk to check if there are&amp;nbsp;security updates&amp;nbsp;that may be relevant for your product in specific.&lt;/p&gt;
&lt;p&gt;Best regards,&lt;br /&gt;Kenneth&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>