retsl · HackerTrans

5 個月前discuss

> A lot of phone manufacturers "save on memory" and use the same memory chips for the baseband processor and the central cpu. Which means that it's a little bit cheaper ... and the baseband has access to all the phone memory and all peripherals connected through the memory bus (which is all of them in any recent phone).

This can be mitigated e.g. via an IOMMU: https://grapheneos.org/faq#baseband-isolation

> It may even be the case that these chips are integrated in the cpu (which I believe is the case for recent Apple chips).

I don't know whether it's true or not that they use the same RAM chips. But either way it doesn't change the fact that they can still be properly segregated via the IOMMU.

retsl

5 個月前discuss

> [...] The baseband implements other functionality such as Wi-Fi and GPS functionality [...] https://grapheneos.org/faq

It doesn't need to ask the OS, it can just get the coordinates and send them off.

retsl

5 個月前discuss

This is true but there's automatic restart which will automatically restart the phone to get it back into BFU state:

> Automatic Restart is a security mechanism in iOS 18.1 iPadOS 18.1 and or later that leverages the Secure Enclave to monitor device unlock events. If a device remains locked for a prolonged period, it automatically restarts, transitioning from an After First Unlock state to a Before First Unlock state. During the restart, the device purges sensitive security keys and transient data from memory.

https://help.apple.com/pdf/security/en_US/apple-platform-sec...

> [...] inactivity reboot triggers exactly after 3 days (72 hours). [...]

https://naehrdine.blogspot.com/2024/11/reverse-engineering-i...

GrapheneOS also has this (https://grapheneos.org/features#auto-reboot) with a default of 18 hours.

Maybe one could try to force restart (https://support.apple.com/en-gb/guide/iphone/iph8903c3ee6/io...) to quickly get to BFU. But I could imagine that it'd be hard to remember and then execute the right steps in a stressful situation.

retsl

6 個月前discuss

Yes, afaik macOS apps could theoretically be sandboxed as well (or close to) as iOS apps are. You can find the policies for many first-party apps and deamons in /System/Library/Sandbox/Profiles. But in practice most third-party apps aren't.

https://bdash.net.nz/posts/tcc-and-the-platform-sandbox-poli... and https://bdash.net.nz/posts/sandboxing-on-macos/ are good introductory articles.

retsl

9 個月前discuss

Not without approval, see https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_A... or https://web.dev/articles/async-clipboard#security_and_permis.... But that is not relevant here.

Instead of the .torrent files, the compromised website served a .zip file, which contained a .exe. When opened, it shows a GUI to select a Xubuntu version and a button to generate the link. When that button was clicked, the malware showed a download link to the user and, in the background, deployed a second stage to %APPDATA%\osn10963\elzvcf.exe and executed it.

The second stage monitors the clipboard for cryptocurrency addresses which it will replace with attacker-controlled ones. The second stage is also added to HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ to ensure it is run whenever the user logs in.

Both stages have some limited anti-debugging and anti-VM functionality.

retsl

9 個月前discuss

the malware's main function seems to be to check the clipboard for crypto wallet addresses and then replace them with attacker addresses:

  Bitcoin (bc1): bc1qrzh7d0yy8c3arqxc23twkjujxxaxcm08uqh60v
  Litecoin (ltc1/L/M): LQ4B4aJqUH92BgtDseWxiCRn45Q8eHzTkH
  Ethereum (0x): 0x10A8B2e2790879FFCdE514DdE615b4732312252D
  Dogecoin (D): DQzrwvUJTXBxAbYiynzACLntrY4i9mMs7D
  Tron (T): TW93HYbyptRYsXj1rkHWyVUpps2anK12hg
  Ripple (r): r9vQFVwRxSkpFavwA9HefPFkWaWBQxy4pU
  Cardano (addr1): addr1q9atfml5cew4hx0z09xu7mj7fazv445z4xyr5gtqh6c9p4r6knhlf3jatwv7y72deah9un6yettg92vg8gskp04s2r2qren6tw

can't guarantee it doesn't do anything else.

comments