Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple's macOS Screen Sharing Flaw Is Being Exploited in the Wild
- Thread starter MacRumors
- Start date
- Sort by reaction score
CarlJ
Contributor
Keep in mind that routers can be configured (and many are by default) to automatically punch holes through the firewall if UPnP is used by devices. So, ports can be "helpfully" opened for you, without you having explicitly opened it yourself.
ikramerica
macrumors 68030
I’ll be more clear.
I have the cable modem connected to airport extreme and which is set to distribute 10.0.1.100+ addresses via DHCP, with other devices on the network assigned fixed IPs in the .2 to .99 range. Eeros provide the wifi backbone but don’t distribute IPs on the main network, but do on the Guest Network 197.x which leads to Double NAT but I don’t care about that on the Guest network and it doesn’t seem to cause SSL issues for the most part.
So if 10.0.1.1 (the Airport) has 5900 closed, does that mean all the rest of the 10.0.1.X addresses do to?
ikramerica
macrumors 68030
inventor7777
macrumors member
No, the AirPort's port being closed does not indicate anything about devices on your LAN.
That is expected that the AirPort's 5900 is closed - the AirPort does not automatically inherit open ports from your devices on its LAN interface. The real test is to find your public IPv4 / IPv6 address(es) and try to access their port 5900 from cellular/another network (to avoid any kind of loopback NAT).
I don't know enough about AirPorts to know where to check for firewall settings, but that test should reveal it.
If the public port is closed, than you are good. Of course, if any Macs on your home LAN have Screen Sharing, they would be vulnerable to someone else on your LAN (home network) unless you've updated.
However, UPnP can allow devices to automatically open public ports to themselves, but Macs typically do not.
Last edited:
inventor7777
macrumors member
IPv6 allows each device to have its own globally routable IP address.
With IPv4 NAT, your device has a private address. When it connects to Apple, your router translates that connection to its own public IPv4 address and keeps track of which device the traffic belongs to:
Device -> NAT translation -> Apple -> NAT translation -> Device
With IPv6, the device can communicate using its own globally routable address, so the router generally doesn’t need to translate anything:
Device -> router -> Apple -> router -> Device
Modern Apple/Android/Linux devices typically prefer IPv6 because it's faster and more efficient when your ISP's IPv6 is working correctly. So there are not many downsides, but it is a more modern approach to networking. However, if you are behind Carrier-Grade NAT (sharing a public IP with multiple other people) IPv6 might become dramatically more efficient as CGNAT requires an extra translation layer on top of the existing IPv4 NAT.
Howard2k
macrumors 604
It depends how it (the router) configured. UPNP could enable it on the router if it’s enabled by some other application. Screen sharing itself does not.
You may also be using IPv6, and so that’s another attack surface that should be checked.
First thing to check is whether you have the latest update. Or not. Then check whether screen sharing is enabled in settings. Then if it is check the router and see if UPNP is enabled. If it is, check the active ports. It will enable and disable them periodically depending on what’s required. Enabling Screen Sharing doesn’t enable the pass through with UPNP so this seems to rely on another service using UPNP to open 5900 which can then be remotely exploited (using screen sharing).
Apple’s change is about the authentication not the network protocols.
chucker23n1
macrumors G3
In absolute numbers, yes, but a lot of high-profile targets — politicians, wealthy people, etc. — favor iOS.
chucker23n1
macrumors G3
Yep, although I believe macOS has no built-in UPnP client, so it won't ask your router to do that. So I don't think that scenario applies here.
I'm no expert, but it is my understanding that at least on macOS any application can control a router/gateway that has UPnP enabled. You don't need OS support for that. This does not seem to apply here if the Screen Sharing feature does not include a UPnP client.
Steve Adams
macrumors 68020
You missed what I said. the BIGGEST target of them all is using android. IE the pres. Wealthy people use apple for the status symbol and more than likely tim just gave them their phones.
chucker23n1
macrumors G3
Yes, of course a third-party app could implement its own UPnP client. But given that macOS itself doesn't appear to ship with one, and that UPnP is kind of a competing technology with Bonjour, it strikes me as unlikely that screensharingd specifically would use UPnP.
I did not.
Malicious actors don't just go by "biggest" target. They also go by most lucrative target.
One of the reasons so many security issues are found on iOS is that it is extremely lucrative for state actors to find security issues they can use against journalists and dissidents.
Steve Adams
macrumors 68020
Exactly. You are still missing what I am saying. The "president" of the US is using android.
chucker23n1
macrumors G3
Steve Adams
macrumors 68020
Oh god, not this again. Someone makes a comment about apple having issues. Then, said fans come out and state apple has better. Then proven wrong. then the famous comment
"where did I say (insert other product, OS, etc) didn't have said feature.
Got it. have a great day, enjoy your day!
"where did I say (insert other product, OS, etc) didn't have said feature.
Got it. have a great day, enjoy your day!
chucker23n1
macrumors G3
Nah. "There seems to be way more security flaws for Apple these days than any other platform out there" was your assertion, and is up to you to defend.
vegetassj4
macrumors 68020
FYI
Handy tool for checking what ports (IPv4 only) being opened to the interwebs
www.grc.com
Handy tool for checking what ports (IPv4 only) being opened to the interwebs
GRC | ShieldsUP! — Internet Vulnerability Profiling
GRC Internet Security Detection System
Last edited:
Apple_Robert
Contributor
Instead of opening ports, (which is a terrible idea) use Tailscale which doesn't open ports and offers a secure connection.
Steve Adams
macrumors 68020
I have provided many examples of my last 5 years working with all devices at the provider level. Whether someone chooses to not to agree with me is on them not me.
ScooterComputer
macrumors 6502
So for such a late response, but Matter and a lot of newer IoT gear expect IPv6, and won't work properly without it enabled. Also some Apple technologies like AirDrop and Handoff require it. With better 'consumer' gear you can enable local IPv6 without it also getting routed. Like IPv4, there are basically four kinds of IPv6 addresses defined in the RFC: Loopback; Link-Local (LLA; think 169.254.x.y addresses), which are not locally routed and are dynamically determined by individual hosts; Unique Local Addresses (ULA; think 192.168.1.x or 10.x.y.z), which are not globally routable; and Global Unicast Addresses (GUA), a routable globally-unique address. It is the GUAs that ISPs have started enabling recently, and not informing customers it is happening.
Now… your ISP's firewall—even with GUA enabled—should be—should be!—protecting your client devices on your LAN… however… you're now completely at the mercy of quality of that firewall. This is where/why OSes now come with built-in firewalls (Windows, macOS); but they're not always enabled by default. A lot of older devices, like printers and mfcs, either don't have firewalls, don't enable them, or often get things enabled/changed unexpectedly with random firmware updates (like IPv6 on, firewall still off). Additionally, a lot of older devices either had fixed admin passwords or passwords generated from the NIC MAC address… and those generation algorithms are now 'known'… so the passwords can be determined by remote attackers. And they are doing that. And you end up with porn, swastikas, or the entire unabridged version of 'War and Peace' sitting on your printer in the morning. (And probably no longer know the admin password, and it isn't what is printed on the label on the back.) And Network Address Translation, NAT, can and is still used for IPv6… but whether the ISP chooses to use NAT or not is typically up to them, not the customer. (NAT is an extra layer of protection even above a firewall, though only marginally, from a security perspective.)
JosephAW
macrumors 604
Can confirm that macOS Mojave is vulnerable, noticed in my /etc/sudoer.d/ folder was a PWN file that gives sudo -s root access without a password, deleted that file and it returned back to normal where it requests a password but don’t think Apple’s gonna provide any security updates for all the older versions, just another way to push everybody to the new three new macOS versions and hardware.
I’m trying to upgrade to Remote Utilities but they Mojave client is broken, looks like my only fix is to use core patcher and force to a non 32 bit macOS.
Does anybody know any other remote access tools available that are secure?
UPDATE:
I'm using root access in the terminal and I'm more familiar with vi text editor to examine files than using the other ones like nano, but whichever one you're more comfortable with Some of the files I changed I made a back up so it could be reverted if something broke.
After searching for the attack date of August 13 and also the EPOCH date of 1969. I found this as well in the system.
/private/var/root/.ssh added an authorization key put in there so I deleted that
Also in the /Library/LaunchDaemons/com.apple.metadata.fetch.plist
the contents referred to a file located in:
/private/var/tmp/.r
Which was a small perl script that I think it allowed SSH from a IP address, I traced it back to Hong Kong
Cleaned out that directory since it's temp anyway
Don't think they did anything else in any of the other root folders, only that .SSH folder was modified and of course, the parent root folder modification date was changed, I thought other folders were modified, but that was showing the double dot, which is the parent folder. only the .SSH current folder and parent folder dot show the modification date.
Also in
/etc/ was a file named zshenv with a more advanced script for the same IP address addressing again, but also to remove some of the files I described above after sleeping for 10 seconds, but for some reason, it didn't succeed to clean everything up, there was also something going in in the script at
/var/at/tabs/ with a file named _probe
The directory was empty, so it might've cleaned itself out to cover their trail.
I think that's all I could find but the key is when their hack is running. It has a trouble with the dates and so uses the EPOCH date of "Dec 31 1969"
If you search for that date, you might find some other files with a date, but don't panic, they may belong to you when a program had trouble writing a file which I discovered, but the system shouldn't have files with that date unless something majorly was wrong with your original install.
That might be a good starting place if you're looking into your system by searching for the date
I can tell the date and time that they went into my system by the folder modification date of
/private/etc/sudoers.d and /private/var/root
When searching for that modification date of that folder where they added that PWN file, I could not find anything else during that time period in my system, all the hack or extra script files were all dated 1969.
The launchdemons that they set up I suppose that would reactivate when you rebooted your computer, but it doesn't seem to re-copy the files but it make sure that SSH is accessible to that Hong Kong IP address
I don't have SSH turned on, but they may be running some other version in the terminal when they break in
I sent a note to avast, which is my antivirus telling them they need to at least provide some type of alert when these files are created, which are not normal.
Here's the way I found all the modification dates and the locations, I'm sure there's better ways to do it, but I wanted to catch a snapshot of all the files and the dates so this is what I typed in the terminal once I got in there.
sudo ls -laR / > /Users/5900FilesCheck.txt
This file will be located in the parent folder above your home folder, it may take a long time to run so you can monitor the progress by going to that directory in the finder and watch it grow in size. After it’s finished you may have to adjust the permission so that you can read it from your desktop.
You will know it's finished when your cursor reappears after you run the command.
This command will use root access to scan for the times and dates and sizes of all the files and their parent directories and I'll put it to the desktop folder in a file named above don't use any spaces in the phone, but just in the command as displayed above.
I open that file with TextEdit and from there you can search for that EPOCH date and then that might give you a rabbit trail to look at other files and folders using root access sudo -s
Obviously, you have to be careful if you are deleting files in the system folders. You have to really understand what you're doing, I would tell you to do a back up first, but that could contaminate your back up, maybe start another back up or a disk copy using something like carbon copy to another drive.
I'm running a deep scan with the antivirus, but I don't think it's gonna find anything except maybe some email in the home directory from spam. I'll reboot my system afterwards and make sure none of those files reappeared, which I don't think they will.
Hopefully they didn't replace any binaries which they could have but for now that's the best that I can determine at this time. Apple really needs to secure older systems that can't update.
Make sure you disable, remote, desktop or place it behind a firewall with port forwarding or actually edit
/etc/services and change port 5900 to a different number that they can't see and then port forward to that new number you typed in there with your router. When connecting to that computer remotely just place after the IP address of your computer a colon 🙂) and then the new number that you came up with and it should connect like normal where you have to provide credentials.
That's all I have for now. I'll update if there's more.
I’m trying to upgrade to Remote Utilities but they Mojave client is broken, looks like my only fix is to use core patcher and force to a non 32 bit macOS.
Does anybody know any other remote access tools available that are secure?
UPDATE:
I'm using root access in the terminal and I'm more familiar with vi text editor to examine files than using the other ones like nano, but whichever one you're more comfortable with Some of the files I changed I made a back up so it could be reverted if something broke.
After searching for the attack date of August 13 and also the EPOCH date of 1969. I found this as well in the system.
/private/var/root/.ssh added an authorization key put in there so I deleted that
Also in the /Library/LaunchDaemons/com.apple.metadata.fetch.plist
the contents referred to a file located in:
/private/var/tmp/.r
Which was a small perl script that I think it allowed SSH from a IP address, I traced it back to Hong Kong
Cleaned out that directory since it's temp anyway
Don't think they did anything else in any of the other root folders, only that .SSH folder was modified and of course, the parent root folder modification date was changed, I thought other folders were modified, but that was showing the double dot, which is the parent folder. only the .SSH current folder and parent folder dot show the modification date.
Also in
/etc/ was a file named zshenv with a more advanced script for the same IP address addressing again, but also to remove some of the files I described above after sleeping for 10 seconds, but for some reason, it didn't succeed to clean everything up, there was also something going in in the script at
/var/at/tabs/ with a file named _probe
The directory was empty, so it might've cleaned itself out to cover their trail.
I think that's all I could find but the key is when their hack is running. It has a trouble with the dates and so uses the EPOCH date of "Dec 31 1969"
If you search for that date, you might find some other files with a date, but don't panic, they may belong to you when a program had trouble writing a file which I discovered, but the system shouldn't have files with that date unless something majorly was wrong with your original install.
That might be a good starting place if you're looking into your system by searching for the date
I can tell the date and time that they went into my system by the folder modification date of
/private/etc/sudoers.d and /private/var/root
When searching for that modification date of that folder where they added that PWN file, I could not find anything else during that time period in my system, all the hack or extra script files were all dated 1969.
The launchdemons that they set up I suppose that would reactivate when you rebooted your computer, but it doesn't seem to re-copy the files but it make sure that SSH is accessible to that Hong Kong IP address
I don't have SSH turned on, but they may be running some other version in the terminal when they break in
I sent a note to avast, which is my antivirus telling them they need to at least provide some type of alert when these files are created, which are not normal.
Here's the way I found all the modification dates and the locations, I'm sure there's better ways to do it, but I wanted to catch a snapshot of all the files and the dates so this is what I typed in the terminal once I got in there.
sudo ls -laR / > /Users/5900FilesCheck.txt
This file will be located in the parent folder above your home folder, it may take a long time to run so you can monitor the progress by going to that directory in the finder and watch it grow in size. After it’s finished you may have to adjust the permission so that you can read it from your desktop.
You will know it's finished when your cursor reappears after you run the command.
This command will use root access to scan for the times and dates and sizes of all the files and their parent directories and I'll put it to the desktop folder in a file named above don't use any spaces in the phone, but just in the command as displayed above.
I open that file with TextEdit and from there you can search for that EPOCH date and then that might give you a rabbit trail to look at other files and folders using root access sudo -s
Obviously, you have to be careful if you are deleting files in the system folders. You have to really understand what you're doing, I would tell you to do a back up first, but that could contaminate your back up, maybe start another back up or a disk copy using something like carbon copy to another drive.
I'm running a deep scan with the antivirus, but I don't think it's gonna find anything except maybe some email in the home directory from spam. I'll reboot my system afterwards and make sure none of those files reappeared, which I don't think they will.
Hopefully they didn't replace any binaries which they could have but for now that's the best that I can determine at this time. Apple really needs to secure older systems that can't update.
Make sure you disable, remote, desktop or place it behind a firewall with port forwarding or actually edit
/etc/services and change port 5900 to a different number that they can't see and then port forward to that new number you typed in there with your router. When connecting to that computer remotely just place after the IP address of your computer a colon 🙂) and then the new number that you came up with and it should connect like normal where you have to provide credentials.
That's all I have for now. I'll update if there's more.
Last edited:
Hi JosephAW and thanks for sharing. Curious did you have Screen Sharing enabled or did they get in anyway? Was your computer open to the Internet or just local (e.g. via firewalls)?
To your question about remote access, is your need GUI or just command-line?
JosephAW
macrumors 604
This is an older 2012 Mac mini running Mojave, use it at a small church to do some Printing, nothing mission critical.
It’s connected to the DMZ on the router and requires Apple Remote Desktop login and then user login before seeing the desktop. Screen sharing is always turned on with the firewall turned on as well in stealth mode.
Noticed something was fishy when I was doing something in terminal it didn’t request a password, there wasn’t a paper trail in the logs that I could see but somehow one file was injected in that one folder that allowed all users with no password for root Access in the terminal. The file name they used was PWN so it was almost like a joke, the file date was the epoch date of 1969 but the parent folder was modified on August 13 at 9 AM so I searched for that date throughout the system and nothing else was affected that I could see.
I checked all the launch demon folders and root home folders for any scripts or mining programs and for any SSH modifications and hidden files but couldn’t find anything out of place. It’s possible they didn’t gain any additional access because of the two logins required but I doubt it, I would assume they can overwrite a file and then have full access. The disc is formatted to HFS+ but I don’t think that would make any difference, that was the last macOS that supported that.
It could be they’re just running a bot walking every IP address injecting the same code and seeing which one sticks and maybe they would come back later to do something more malicious.
Since then I’ve rename the port number in ETC/services to a new number and eventually will take the entire computer out of DMZ and use port forwarding but who knows how long that will protect it.
Of course Apple solution is just to buy a new computer or run one of the latest three OS’s which I could do using core patcher but I have a lot of legacy software I do not want to re-purchase.
Hopefully for now that will work until we are forced to upgrade to Apple Silicon.
The rest of the computers in their organization are running windows 10 but all those computers are behind the firewall, I would never stick a PC on the DMZ but the days of secure Mac are over. It would be nice if Apple would patch with a security update all affected Intel versions just as Apple has done something similar for iPhones providing updates all the way back to iOS 9 in the past, even if it was just a manual install have a one time installer file.
I have been using Remote Utilities for my PCs there and they do have a Mac version but it’s still in beta but when I try to use it on Mojave which they say they support but it fails.
Running the free version of a avast one but that was a wet paper bag it didn’t alert me of anything malicious going on or files detected.
It would be nice if there was a website or tool that you could run to see if a Remote computer is vulnerable or not that way you could test different things trying to resolve it, I don’t know if it’s possible to copy the libraries and binaries from Intel version of Sequoia of ScreensharingD to downgrade it into an older macOS.
If I notice I’m hacked again with these changes I’ll post something in here.
Last edited:
Okay that's helpful and consistent with Screen Sharing having to be enabled for the vulnerability to be exploited. Of course that is your situation...
A few quick notes / suggestions:
-Would do a clean install of Mojave on that Mac before proceeding
-I would consider implementing a VPN, requiring people to login to a VPN before connecting to that machine from the outside, and blocking access to that machine from outside the network
-If you just needed remote command-line access, I would replace the SSH with the latest SSH (e.g. OpenSSH)
-Since you need Screen Sharing enabled and accessible outside your LAN, I would disable Apple's Screen Sharing software and try an open source VNC implementation (e.g. macVNC/libVNC maybe x11vnc)
I am assuming from your note that you have a lot of legacy software you don't want to buy again is 32-bit software that doesn't run on more recent macOS?
Otherwise you might look at a used Mac Mini 2018 running Sequoia. Still supported (for another year...) and base models run reasonably cheap on eBay. Sequoia is not as smooth as Mojave but still runs reasonably well (assuming your apps are not intense OpenCL or Metal). I will be sharing benchmarks around this soon. Depending on the RAM you had on the 2014, you might want the 16GB configuration for Sequoia.
Agree, at this point I wouldn't make any Mac less than Sonoma directly accessible from the Internet and that goes up to Sequoia soon. Even then I would minimize surface area as much as possible (e.g. firewalls as you've done and even look at VPN, SSH tunneling, etc).
Agree though I can see how Apple doesn't want to go back through 6 or 7 versions to patch the same bug. However I also argue that is self-inflected as Apple put themselves in this corner with their annual macOS major releases (perhaps not accidentally).
Imagine if major versions came every 3 years rather annually. We could still be on Mojave but it would be protected at the Sonoma level. I don't think many people want to be on a 2021 version of macOS. They just don't want a major version every year.
I believe there are open source tools to do this. I think public websites avoid this as such tests would have access patterns would be indistinguishable for malware/hackers and so likely quickly blacklisted.