screensharingd - Random Ip connections?

[h1kar1]

Good day guys.

I installed Little snitch today.
And noticed that the service "screensharingd" is trying to connect out so far 9 different ip's when I do whois on the ip's they don't look so legit...

Has anyone run into this?
Any thoughts?

I've enclosed an image with the IP's

 

[east85]

Good day guys.

I installed Little snitch today.
And noticed that the service "screensharingd" is trying to connect out so far 9 different ip's when I do whois on the ip's they don't look so legit...

Has anyone run into this?
Any thoughts?

I've enclosed an image with the IP's

If you don't need screen sharing you can always disable it in Sharing under System Preferences.. better to be safe than sorry.

 

[h1kar1]

I use the service a lot it's my office computer so that's not an option

And FYI I use remote management with ARD not screen sharing it self

This had me stump I'm just worried abit if it's mailware trying to call out on screensharings default port 5900

But don't know how it would infect a core service with root permissions if it is

 

[stanton]

RE: screensharingd - Random Ip connections?

Since you have it open to the public, you will get random people trying to log on.

My solution would be to install DenyHosts if you use Apple's VNC program.
http://denyhosts.sourceforge.net/

Basically it's just a Python Daemon that scans "/var/log/system.log" (used to be "/var/log/secure.log" in Lion) for invalid attempts at SSH or anything else that you would like and adds the entries to hosts.deny.

Config file should have something like this:
SSHD_FORMAT_REGEX=.* (sshd.*:|\[sshd\]|AppleVNCServer\[\d+\]🙂 (?P<message>.*)
USERDEF_FAILED_ENTRY_REGEX=Authentication: FAILED :: User Name: (?P<user>\S+) :: Viewer Address: (?P<host>\S+) .*

Taken from: http://www.mail-archive.com/denyhosts-user@lists.sourceforge.net/msg00844.html

After it's setup just add a plist in /System/Library/LaunchDaemons and load it with launchctl.

 

[h1kar1]

stanton,

thank you for your reply.
I do have a hardware firewall installed and its setup only to allow specific Mac address through that port.

That being said we are not talking about connections in.
Little snitch only show out going connections.

You can use the terminal command
lsof -i

That will show you all listening or established connections

Now there are no incoming connections on that port.
Just the occasional outgoing from that service when it's running

 

[stanton]

h1kar1,

You know the program causing the traffic: screensharingd.
I'm not sure if it's Active or Passive sockets, in that both connections send/recieve on that single port 5900 or the return port varies on screensharingd selecting an upper level port. Either case, this should be blocked by the firewall since you've limited down to certain IPs?

Since the daemon is calling the connection, I would think this would be inbound traffic, instead of the client:
/System/Library/CoreServices/Screen Sharing.app/Contents/MacOS/Screen Sharing

You could try off porting... Looking at the plist, it might just be changing the port listed.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Disabled</key>
<true/>
<key>EnableTransactions</key>
<true/>
<key>GroupName</key>
<string>wheel</string>
<key>Label</key>
<string>com.apple.screensharing</string>
<key>MachServices</key>
<dict>
<key>com.apple.screensharing.server</key>
<dict>
<key>HideUntilCheckIn</key>
<true/>
<key>ResetAtClose</key>
<true/>
</dict>
</dict>
<key>ProgramArguments</key>
<array>
<string>/System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/MacOS/screensharingd</string>
</array>
<key>Sockets</key>
<dict>
<key>Listener</key>
<dict>
<key>Bonjour</key>
<string>rfb</string>
<key>SockServiceName</key>
<string>vnc-server</string>🙂
</dict>
</dict>
<key>UserName</key>
<string>root</string>
<key>SHAuthorizationRight</key>
<string>system.preferences</string>
</dict>
</plist>

 

[Jeff Chen]

I hope you are not still hooking up your computer directly to a DSL/cable without a router. Doing so can be dangerous, even with a Mac.

So, if you don't mind being exposed to danger anyway, you might wanna change the port number of your screensharingd to something else, a number that only you would know. That way, you can use <IP>:<port> to connect, while these shady sniffers won't be able to find out anything anymore.

 

[stanton]

@Jeff Chen
Properly locked down with ipfw and security programs, you can put a server directly on the Internet. Look at all the VPS solutions out there without managed firewall services that are working fine. IMHO, Apple doesn't push patches fast enough, but that is just a personal opinion.

He stated he does have a hardware firewall though so it might just be misconfigured, and that is my guess at the current time.

 

[h1kar1]

Hey guys.

Yes I have a dedicated box running Untangle.
And I am a Director of IT by trade so it's set up correctly

I really do see this as being some kind of Trojan somewhere at this point.
I can not reproduce this on any other computer on the same network

My latest IP that it is trying to connect to is 216.164.203.22

Doing a whois points to a dsl provider however doing some searching on the internet I found this...

http://riskyinternet.com/what-is/ip/216.164.203.22/

For the better part of the day things were going fine no popup's even ran some ARD to and from the computer watching screensharingd start and close without any connections trying to be made.

I'm not sure what is infected at this point however itunes is running now and wasn't all day.

need to do a bit more investigating.

 

[stanton]

Here's the major issue, imho. Unless they replaced the screensharingd service, plist, etc, it shouldn't get through the untangle box unless specified by the ACLs listed on the router. IE they would have to guess your ACLs that allowed public access to the server, so for example modify screensharingd to use both 80 and 5900. I'm not super familiar with Untangle, but know it's a linux distro with a GUI that pretty well used. The odds of someone random doing this is pretty slim, and would break other things like Apache so you would probably notice.

My first suggestion would be simply run nmap right now on a off-network computer, and find the available ports open on the router.

If vnc is open on a known blacklisted IP, then you've found an issue. If it's closed, then test every port open to find out how they are getting to the screensharingd service, and put in some blocks while you reinstall ML. This could be from an upgrade from Lion that you just didn't notice, so you might have to do some forensics on the logs.

 

[h1kar1]

Stan,

Heres the thing.
I don't see this as someone trying to connect from outside.
I see this as something on my machine trying to connect to a server using port 5900. Which if you ask my is prob why it would be connected to something with a vnc.

That being said I see no logs of those IP's on my router coming in on any port from the outside.

 

[stanton]

Stan,

Heres the thing.
I don't see this as someone trying to connect from outside.
I see this as something on my machine trying to connect to a server using port 5900. Which if you ask my is prob why it would be connected to something with a vnc.

That being said I see no logs of those IP's on my router coming in on any port from the outside.

screensharingd is a service, ie it can't normally initiate a connection. There are some exceptions, such as an echoserver, but it would require a total rewrite of the binaries involved. Thus in order to do this, they would have to have complete root access since you've upgraded to ML, since looking at my files all have been modified since upgrading to ML. I'm not saying it's impossible since they could of had root access before the upgrade, but it would take either a dedicated person, or an inside job to rewrite the binaries to accomplish the task.

Other option would be to use a socks proxy or vpn to gain access to the network and bypass the ACLs on the router, this would show up on the logs though as coming from that IP address that is compromised and not the external address.

Either case, the best option is to say, take all relevant log files for forensics and a legal team, and start with a fresh slate. Most likely it will also involve changing all password on the AD or LDAP as well.

 

[chrismartinphd]

Same Problem and concern

@h1kar1: I have the exact same issue after installing the newest Little Snitch. I also recently upgraded to Mountain Lion. I am not sure what has changed. I too get little snitch pop-ups saying that screensharingd.bundle wants to accept incoming connections from (insert random IP#)...on port ####. Shortly thereafter little snitch puts "terminated" over the pop-up and it goes away.

Note that it is saying that screensharing is being "poked" to allow incoming, not outgoing. I don't recall this sort of behavior in Little Snitch before. I thought it only looked at outgoing stuff... Or, is it something different in Mountain Lion?

I have port #### open on my router so that I can access my mac using VNC. Perhaps I should rethink that?

It seems to me that this is just people or bots sniffing around. It's probably always been happening. Something recently has changed so that Little Snitch is alerting when these happen now. Just to be sure I ran a virus scan and ddin't find anything.

For now, I've just been forever denying them when i see them...

Let me know if anyone has ideas...😕

 

[ElectricSheep]

For what its worth, Little Snitch 3 does filter incoming connections, and these are precisely what you are seeing with screensharingd: A series of incoming connections which have been denied. The small icon next to the IP address indicates that the connections where incoming, not outgoing.

 

[MacgyverNH]

Little Snitch - screensharingd

I'm also getting hits from these addresses.
141.101.237.41
216.19.230.115
207.237.187.100
212.43.129.8
195.122.213.118
107.22.99.30

 

[ardpbub]

@h1kar1: I have the exact same issue after installing the newest Little Snitch. I also recently upgraded to Mountain Lion. I am not sure what has changed. I too get little snitch pop-ups saying that screensharingd.bundle wants to accept incoming connections from (insert random IP#)...on port ####. Shortly thereafter little snitch puts "terminated" over the pop-up and it goes away.

Note that it is saying that screensharing is being "poked" to allow incoming, not outgoing. I don't recall this sort of behavior in Little Snitch before. I thought it only looked at outgoing stuff... Or, is it something different in Mountain Lion?

I have port #### open on my router so that I can access my mac using VNC. Perhaps I should rethink that?

It seems to me that this is just people or bots sniffing around. It's probably always been happening. Something recently has changed so that Little Snitch is alerting when these happen now. Just to be sure I ran a virus scan and ddin't find anything.

For now, I've just been forever denying them when i see them...

Let me know if anyone has ideas...😕

I am experiencing the same. Started getting these alerts after upgrading to Mountain Lion and a new version of Little Snitch.

I also have screen sharing enabled and a port open on my router for VNC.

The IP's I'm getting are:
222.66.209.181
113.118.97.114
220.178.30.232

I'm also getting requests from IMRemoteURLConnectionAgent
23.73.180.121
23.73.180.169

Any advice on a course of action for those of us with limited knowledge of IT?

 

[Riot Nrrrd]

Any advice on a course of action for those of us with limited knowledge of IT?

DenyHosts seems to be the best solution I can find right now.

[Edit: It looks like Little Snitch 3.0 can filter incoming connections now. I am still on 2.3.6 which cannot do it.]

The problem is that Apple's flimsy "Firewall" only allows connections on a per-app basis. There doesn't seem to be any option to filter by IP address in a particular app.

In other words, you want "AppleVNCServer.bundle" to be able to accept incoming port 5900 (VNC port) connections; but you don't want bad guys to be able to connect to that port. Firewall doesn't give you fine-grained control over it like it should.

Mac OS X also has the UNIX-standard ipfw command installed, but Firewall doesn't seem to use it "under the hood":

[13:54] mymacpro:/var/log % sudo ipfw list
65535 allow ip from any to any

which is ironic since I'm pretty sure that's what Mac OS X Server uses under the hood for its firewalling.

Meanwhile I am getting barraged with connections to the VNC port every day:

[13:51] mymacpro:/var/log % grep "VNC DES" secure.log | wc -l
    1537

despite the fact that Firewall is running and allowing VNC/ScreenSharing connections.

I'm astounded that Apple's server is not, say, linked against TCP Wrappers so that you could set up /etc/hosts.allow entries to only allow certain IP addresses/subnets to connect to port 5900. 😱

 

[noctographer]

tickling AppleVNCServer causes display wake

I run an OS X Server (Leopard) that never sleeps. I can "sleep" the display with ctl-shift-eject but it always lights up again within minutes. It's been going on for years causing LCD burn and general irritation... until solved today!

Every screen wake coincides with a /var/log/secure.log entry as above for VNC DES from various foreign ip addresses.

I tried to block the VNC port for any but LAN addrs, thinking I could VPN in to manage the server with VNC or ARD. (I believe Apple Remote Desktop also uses VNC port 5900).

The OS X Server firewall is apparently overridden by the ARD client. Attempting to block port 5900 (which I had tried in the past) does nothing. There is still an early rule listed in ipfw that passes port 5900.

So, I used ipfw to remove the default remote sharing access. In my case:
sudo ipfw delete 01030

Whew, relief!

I wonder what the cumulative power bill is for keeping the displays constantly lit for years on so many Macs?
...
This particular iMac 24 server uses an additional 50 to 80 Watts with the display lit, depending on the brightness setting. 50W costs me $75/yr. That's about $500 this bug has bitten off me alone. 😱

I'm looking forward to having a dark apartment at night, now.

 

[almo2001]

Does this have anything to do with Find My Mac? I started getting this after the upgrade to Mountain Lion and Little Snitch 3. But when installing ML, I allowed "Find My Mac" which supposedly lets you find and lock or erase your mac remotely.

 

[Birck]

Currently running OS X 10.10.5 with screen sharing on. My log/pass was 1 letter (very easy).

Someone took control of my mac in the middle of the night, logged in to my amazon account. My credit card info was saved so they transfered 500$ gift cards. @#$%^&*

They even trashed my transactions confirmation emails from amazon...

Beware of screen sharing on mac. Make sure you have protection.