{ "id": "a57857a4-5482-42b5-86b2-408c4980ac8f", "created_at": "2026-04-06T00:19:51.255793Z", "updated_at": "2026-04-10T03:21:23.595168Z", "deleted_at": null, "sha1_hash": "4777843d41d1af3daea169a2996bfa3facaded47", "title": "Detecting macOS High Sierra root account without authentication", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 345576, "plain_text": "Detecting macOS High Sierra root account without authentication\r\nBy Nick Miles\r\nPublished: 2017-11-30 · Archived: 2026-04-05 15:02:29 UTC\r\nYesterday, Tenable™ released two plugins to detect macOS High Sierra installs which allow a local user to login\r\nas root without a password after several login attempts. Both plugins require authentication, however, there was\r\none scenario where a user could log in over VNC protocol with the root account and no password if screen sharing\r\nwas enabled. Today, we are releasing a plugin to remotely detect the vulnerability without authentication.\r\nConfirming the Vulnerability\r\nOne of my colleagues initially reported that exploitation was possible remotely over VNC after trying against his\r\npersonal laptop. To confirm the report, I fired up tightVNC (an open source VPN server/client) and tried to exploit\r\nthe issue on an lab box with “Screen Sharing” enabled (see screenshot below). I ran into a problem were\r\ntightVNC couldn't connect to OSX (more on this later). I then tried another VNC client, realVNC, and was able to\r\nsuccessfully exploit the issue. After two attempted logins with root and a blank password, the VNC client drops\r\nyou to a desktop on the remote host, as root. Now it’s time to look into the VNC protocol, and figure out how we\r\ncan write a remote check for this!\r\nhttps://www.tenable.com/blog/detecting-macos-high-sierra-root-account-without-authentication\r\nPage 1 of 6\n\nDelving into the VNC Protocol\r\nAnytime you want to learn a new protocol, a good place to start is the RFC. The RFC for VNC can be found here:\r\nhttps://tools.ietf.org/html/rfc6143\r\nThe RFC refers to the protocol as RFB (remote frame buffer). In order to exploit the vulnerability, we need to\r\nfigure out how to perform authentication over the VNC protocol. The first step is to connect to the host and\r\nreceive a banner, which looks something like this:\r\nRFB protocol version = 3.889\r\nNext, we send a similar banner string to the server (ending in a new line), and receive a response for the server\r\nthat contains the supported authentication types (response decoded below):\r\nServer Auth Types:\r\n30,33,36,35\r\nThe RFC doesn’t mention anything about these authentication types. I needed to figure out what these were, so I\r\nloaded up the debug log for realVNC and saw the following:\r\nhttps://www.tenable.com/blog/detecting-macos-high-sierra-root-account-without-authentication\r\nPage 2 of 6\n\n15\u003e 2017-11-30T00:45:25.175Z TNS5872L vncviewer[13452]: Child: 12148: CProtoPreV5: processing security types me\r\n15\u003e 2017-11-30T00:45:25.175Z TNS5872L vncviewer[13452]: Child: 12148: CProtoPreV5: Server offers security type A\r\n15\u003e 2017-11-30T00:45:25.175Z TNS5872L vncviewer[13452]: Child: 12148: CProtoPreV5: Server offers security type [\r\n15\u003e 2017-11-30T00:45:25.175Z TNS5872L vncviewer[13452]: Child: 12148: CProtoPreV5: Server offers security type [\r\n15\u003e 2017-11-30T00:45:25.175Z TNS5872L vncviewer[13452]: Child: 12148: CProtoPreV5: Server offers security type [\r\nSo realVNC didn’t know what any of these types were, other than type 30, which they have labeled as Ard. A few\r\nGoogle searches later and we found that Ard stands for “Apple Remote Desktop”. No wonder tightVNC didn’t\r\nwork, as the application only supports the RFC standard authentication types.\r\nTo use that type, we send security type 30 (0x1E) to the server, and extract the response which contains\r\nparameters for the authentication. Here is this response in wireshark:\r\nLooks like Diffie Hellman! The generator value is always two bytes and is first in the packet. The key length is\r\nnext and is a two byte integer. The prime modulus and public key follow and are the same size as the key length.\r\nSo far, the debugging output of the plugin outputs this:\r\nRFB protocol version = 3.889\r\nServer Auth Types:\r\nhttps://www.tenable.com/blog/detecting-macos-high-sierra-root-account-without-authentication\r\nPage 3 of 6\n\n30,33,36,35\r\nDoing apple auth!\r\nARD Material:\r\n Generator : 0002\r\n Key Length : 128\r\n Prime Modulus : ffffffffffffffffc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404\r\n Public Key : a1ef2769ecfa51e2913751a3c51e3fabde0732466915fe0f65cf0aa61f468a929850717f4258a9449da3ba92e3a7ab\r\nSo, the obvious thing we need to do is generate our own DH key-pair and calculate the shared secret. What’s next?\r\nAfter a bit more Googling and wireshark analysis, we learn that the username and password are sent using AES\r\nencryption (using ECB mode), with the key being the MD5 value of the shared secret. The username/password are\r\nsent in a 128 byte blob. The first 64 bytes is for the username, the last 64 is for the password. The username and\r\npassword are null terminated and the remaining space is padded with random bytes. Here is an example of the\r\nblob with username admin, password FooBar12 (before we encrypt the data):\r\nTo complete the authentication, we need to send the AES encrypted password blob, plus our public DH key and\r\nthe server will send a four byte integer to indicate success/failure. 0 is success, 1 is failure. Now we can write our\r\nremote check!\r\nExploiting the Vulnerability\r\nExploiting the vulnerability is easy. We try to log in using root and a blank password multiple times (four times\r\nmax) using the process described above. If we are successful logging in, then the remote host is vulnerable.\r\nThe Nessus® Plugin\r\nPlugin 104885 was created to exploit the issue remotely over VNC. You must have “safe checks” disabled in order\r\nfor this run to plugin. This is because successful exploitation will enable the root account, so there is a bit of\r\ncleanup involved afterward if you find any affected boxes with the plugin. You need to both disable the root\r\naccount, and patch the underlying vulnerability.\r\nhttps://www.tenable.com/blog/detecting-macos-high-sierra-root-account-without-authentication\r\nPage 4 of 6\n\nWrap-up\r\nApple has already released a patch for this vulnerability. This is a critical vulnerability by any standard, so please\r\ntake all necessary steps to patch your systems as soon as possible. If the patch can’t be applied for some reason,\r\nplease disable screen sharing if it's not needed. If it is needed, then enable the root account and set a strong\r\npassword.\r\nNick Miles\r\nhttps://www.tenable.com/blog/detecting-macos-high-sierra-root-account-without-authentication\r\nPage 5 of 6\n\nNicholas Miles, Staff Research Engineer, Tenable\r\nNick Miles has worked for Tenable Research since 2011. He has written hundreds of Nessus plugins, and has\r\npublished research on multiple vulnerabilities, with a focus on IoT / OT devices. He now works on Tenable's Zero\r\nDay research team, where he researches industrial control systems. Nick has a Master's Degree in Computer\r\nEngineering, and is an inventor with several patents to his credit.\r\nSource: https://www.tenable.com/blog/detecting-macos-high-sierra-root-account-without-authentication\r\nhttps://www.tenable.com/blog/detecting-macos-high-sierra-root-account-without-authentication\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://www.tenable.com/blog/detecting-macos-high-sierra-root-account-without-authentication" ], "report_names": [ "detecting-macos-high-sierra-root-account-without-authentication" ], "threat_actors": [], "ts_created_at": 1775434791, "ts_updated_at": 1775791283, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/4777843d41d1af3daea169a2996bfa3facaded47.pdf", "text": "https://archive.orkl.eu/4777843d41d1af3daea169a2996bfa3facaded47.txt", "img": "https://archive.orkl.eu/4777843d41d1af3daea169a2996bfa3facaded47.jpg" } }