Posted on 10/06/2016 12:26:15 PM PDT by Swordmaker
Security researcher and former NSA staffer Patrick Wardle is this afternoon demonstrating a way for Mac malware to tap into live feeds from the built-in webcam and microphone. His presentation is being delivered at the Virus Bulletin conference in Denver later today.
Although any unauthorized access to the webcam will light the green LED – a firmware-level protection that is exceedingly difficult to bypass – Wardle’s presentation shows how a malicious app can tap into the outgoing feed of an existing webcam session, like a FaceTime or Skype call, where the light would already be on …
Wardle was the researcher who previously uncovered a way for malware to bypass Gatekeeper protection to run unsigned apps, as well as pointing out a flaw in Apple’s fix for the Rootpipe vulnerability that allowed an attacker with local access to a Mac to escalate their privileges to root.
The paper is entitled Getting Duped: Piggybacking on Webcam Streams for Surreptitious Recordings.
After examining various ‘webcam-aware’ OS X malware samples, the research will show a new ‘attack’ that would allow such malware to stealthily monitor the system for legitimate user-initiated video sessions, then surreptitious piggyback into this in order to covertly record the session. As there are no visible indications of this malicious activity (as the LED light is already on), the malware can record both audio and video without fear of detection.
Wardle has created an app that monitors webcam and microphone activity, and will alert you when a new process accesses either. A pop-up will alert you, advise the name of the process and ask whether you want to allow or block access.
The app, called Oversight, is a free download from Wardle’s website, objective-see.com.
That's true. But all UNIX commands are available in ROOT if there is a true ROOT user with a password. You just have to know how to access it and create the ROOT user. Without the activated ROOT user, you use the recovery system you describe to disable SIP.
My understanding System Integrity Protection is a limitation in the SUDO command for the Administrator users levels and below. All bets are off is anyone is stupid enough to be running in ROOT.
If I recall correctly, SIP was created because of a problem with an uncorrectable or intractable USB bus standards flaw where a malicious USB device could bring in a malicious auto-running App where a SUDO command could do untold damage to the system on a Mac running in Administrator user mode. By limiting what SUDO could do, the damage would be limited, but still allows SUDO to do normal system operations.
Well, once a company heads off in this direction, they tend to keep going. Macworld readers are alarmed because they they think this is only the beginning, and that more restrictions will be added in the future.
That does not mean it is not fully functional UNIX™ when one needs it to be.
There are always "Chicken Littles" willing to run around in circles claiming the sky is falling about almost anything, Proxy. There were a lot of Macworld readers who were panicking, making hyperbolic predictions about how the Mac was going to be turned into a big iPhone clone four or five years ago. It never happened.
There are good and well thought out reasons for locking this attack vector down.
I mentioned the USB bus problem but I also recall that problem also spilled over into Thunderbolt and other port issues. Essentially any usable port had the same early flaw that was a huge problem allowing a malicious actor a means of injecting a sudo command into a UNIX or LINUX operating system running in Administrator mode. This flaw would require re-writing the standards for the bus from the ground up, something that was NOT going to happen until the ports themselves are replaced by a new port someday in the future. There were just too many legacy ports out there to fix on systems too old to update. It would break too much for the risk involved.
There is only one root user, and, in El Capitan, said root user cannot do certain things without modifying the kernel first:
cynwoody:~$ whoami cynwoody cynwoody:~$ python -c "import os;print os.getuid()" 501 cynwoody:~$ sudo bash Password: bash-3.2# whoami root bash-3.2# python -c "import os;print os.getuid()" 0 bash-3.2# csrutil status System Integrity Protection status: enabled. bash-3.2# touch /System/fubar touch: /System/fubar: Operation not permitted bash-3.2# csrutil disable csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS. bash-3.2# exit exit cynwoody:~$ whoami cynwoody cynwoody:~$
I go from cynwoody, uid 501 to root, uid 0, but I still can't create a file in /System, even as root. SIP is on, but I can't turn it off, even as root. Instead, I'm told I have to reboot into the Recovery OS. The SIP status is recorded in NVRAM, and no facility is provided for modifying it, except in the Recovery OS.
However, SIP is enforced by the kernel, and if we can modify the kernel's memory, we can turn it on or off at will. Blogger @osxreverser (Pedro Vilaça) claims to have done it, but his method uses a kernel extension, and those have to be signed, so you need to be an official Apple Developer.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.