User Enumeration Vulnerability in the deprecated macOS Server
I wanted to come up with some catchy title, some fun story, with some good takeaways around the discovery of this vulnerability. However, I am a little loss for words, probably because I‘m not a great writer and don’t very much enjoy it. I prefer the research aspect of things and jotting down stuff on sticky notes, on my white board desk, or in the random text documents that I leave open all over my computer (just like all the tons of open Chrome tabs). Even though there is a community that still uses and loves macOS Server, old deprecated software past its prime, Apple’s VDP response highlights the issue when dealing with vulnerabilities in deprecated software.
Honestly, I don’t blame Apple for their response. I actually expected it. The point of giving an End-of-Life (EoL) date for software is to tell people we are not going to patch or deal with this software anymore — “Its old, pay us for our new better software now.” But I still had an issue with how to deal with the response for the customer.
It was during an assessment that my team discovered these servers running this old deprecated software. As a Red Teamer, when I come across dated software, I typically get a little excited. When you discover the software is deprecated, it raises the possibility that a vulnerability might exist which does not have a patch.
In our case we did not find any of these. We were left with a system that was running software that was EoL which is considered a bad security practice. However, I don’t like providing “theoretical findings” such as “Deprecated software could lead to exploitation, upgrade now”. I would rather have some concrete evidence of the risk to share with the customer.
As my co-worker Khris Tolbert likes to do, I put on my imaginary lab coat (I think he may actually have one) and started doing, as he says “science”.
I needed an environment and system to test again. So I spent a lot more time then I thought I would need building out a replica Virtual Machine running the same OS and macOS Server. The system did not run at optimal speed (I think due to some VMware graphical issue) but it did work. I took the information the team had already discovered during the assessment and started digging into macOS Server.
Little plug for why Red Teamers should consider always building out replica systems during an assessment if time is available. In our case, doing this provided the team with a lot of information related to what features were enabled or not. By fingerprinting the system we were able to determine there were a lot of default settings in place on our target system. One of the big advantages of having this replica system was the ability to see what “success” looked like against the system. For example, the team could determine what the successful authentication response would look like. The team had a system to develop and test tools against before turning them on the target system and feel confident they were safe and worked properly. For example, co-worker Allen Butler researched the Apple Password Server protocol and created a tool to conduct Password Attack utilizing this specific protocol. Keep a look out on Maveris Labs or check out his github for it.
The Vulnerability:
The macOS Server software provides an administrator with the capability to deploy different services. One of the most common services I have seen is the wiki service. While investigating this service, I noticed in Burp Suite that there is a /collabdproxy endpoint that receives PUT requests. This endpoint looks to process requests and respond back with a lot of internal information when just simply browsing the wiki. This is the same endpoint that handles the request for authentication when a user attempts to login to the wiki. As you might expect, with Apple, there is not a lot of detailed information I could find on the inner-workings of this software. Research, investigation, and testing continued as I tried to determine what I could do with this endpoint.
The requests to this endpoint pass data as JSON and it generally must contain the following keys type, serviceName, and methodName. Depending on the associated values for those keys, there may be additional keys or optional keys within the JSON data structure. Below is an example of a normal request to the collabdproxy endpoint with varying key/value pairs in the JSON Data.
Through research and testing, it was discovered that the requests to the collabdproxy endpoint allowed for single or multiple requests. These requests all used similar structures when defining the data desired.
The most common type value is the com.apple.ServiceRequest. Other things to note, the value for methodName is case-sensitive and most methods must match their specific serviceName, however, there are a few like ping which seem to work with the different serviceName values.
As I mentioned previously, authentication to the wiki used the collabdproxy. While investigating different key/value pairs, the AuthService value for the serviceName key combined with the validateUsername:andPassword: (don’t miss the : at the end) value for the methodName value. This combination allowed for a simple method to do exactly what the methodName suggested, validate a user. Below is an example of a request with invalid credentials.
Do you notice the possible concern with the above error response?
That’s right: the error response in the exceptionName has “CSAuthBadPassword”, which implies the username is correct but the password is wrong. Below is an example of a request with an incorrect user with the same bad password.
The error response of “CSAuthNoUser” is pretty clear that the er does not exist. We have discovered error-based user enumeration. As a Red Teamer, I can use this to script up something to discover account usernames and then even use the same requests to conduct a password attack and hope to gain access to this wiki.
You may say, I can get a lot of those names by just looking at the people that have posted things on the wiki. What if I told you that you can enumerate more than just the wiki users?
Yes, you can enumerate any user on the system (or open directory if that service is running, which it probably is). You can even enumerate users like _www, nobody, root, daemon, _postfix, etc.
Also, the methodName value of sessionForUsername:andPassword: will provide the the exact same error messages in the responses. Except if you are successful, you actually get a session value to use to login.
Tool:
I usually let Allen Butler make all of our tools, because let’s be honest, he is just better at it and WAY Faster. However, I was wearing the lab coat, so I decided to make a tool. I created a command-line tool, in python, that will aid in enumeration of a server running macOS Server. It provides some other functionality besides just user enumeration, like determining the version, how many users are active, search for items in the wiki, etc. For more details on the options check out the — help command.
For user enumeration, you can supply your own option on the command-line, you can provide a path to file with a list of usernames, or you can use a list I built into the code to just prove the vulnerability. Additionally, I did add the ability to authenticate with credentials. There is a lot more that could be done with the tool, especially error checking and displaying the data better. If anything, the code has functions that already craft the JSON data structure so that you can easily use it to design your own tool.
https://github.com/ruddawg26/macOS_Server_Enum
One last interesting discovery that could be used to enhance things:
Lets look at that first example request:
In this request, the first type is actually com.apple.BatchServiceRequest. When this type is used, it allows for the batching of multiple requests together. In the JSON data we can see that there is a requests key. The key/value pair for this is actually a list of other JSON formatted requests. This allows for the collabdproxy to take multiple requests of type, serviceName, methodName and process them all from one HTTP request and provide the data back in an HTTP response.
Collabdproxy does not care if there are multiple requests of the same serviceName or methodName as long as the JSON data is structured properly. Which means it is possible to craft an HTTP request that will process multiple requests to do the same thing. Do you see where I am going with this?
Typically, when you try to authenticate to a system you make that one request with a username and password. As a Red Teamer you might conduct a password attack against a user account which would make multiple request, each HTTP request contains one set of credentials to test. But in this case, why not just send multiple authentication requests in the one HTTP request; same user name but varying passwords. As an attacker, I can send one HTTP request to the server, the server then processes all 100 of the requests and sends one HTTP response. I will leave this as a thought exercise for the reader on how best to utilize this information if desired.
I will say, Khris Tolbert did some of his own science related to this and determined for best results you need to have a nice balance between the latency of the network, the number of concurrent requests, and the server processing speed of the large requests. Let’s just say an HTTP request with 1000 authentication requests is doable, but it may not always be the most efficient. Also, this functionality is not currently built-in to my tool, but the framework is there to be able to easily add this feature if desired.
I still had the issue of how to deal with the vulnerability in relation to Apples’ response. I want to reiterate, I don’t have a huge issue with Apple’s response; it is what I expected. However, I still had a customer with an exposed vulnerability that would not get patched. After discussion with my team, they convinced me that we should publicly release this vulnerability. I know releasing vulnerabilities or tools can be a passionate debate for cybersecurity practitioners, but I don’t want to really go down that road in this blog post. However, I would like to share a few reasons why we decided to release this info in this way.
We have confirmed that this software is still used on the public Internet (limited use), and I assume there are still some of these systems sitting around inside organizations networks. So, there are definitely organizations that are susceptible to this vulnerability.
Khris Tolbert provided me some info that this vulnerability is similar to to CVE-2017–2382:
An issue was discovered in certain Apple products. macOS Server before 5.3 is affected. The issue involves the “Wiki Server” component. It allows remote attackers to enumerate user accounts via unspecified vectors.
There is no public information about how this vulnerability worked, so his concern is that even if this is the same vulnerability, it still exists. I have tested it extensively against macOS Server 5.3.1 and some limited tests against versions up to 5.7.
In conclusion, if you or your organization are running deprecated software, I strongly advise you to evaluate the accepted risk and take the appropriate actions. If the choice is to accept the risk, please ensure you are adding other security controls to attempt to reduce the attack surface and ensure there is security monitoring in place for the system. Just remember, there are adversaries wearing lab coats doing science every day.
Maveris is an IT and cybersecurity company committed to helping organizations create secure digital solutions to accelerate their mission. We are Veteran-owned and proud to serve customers across the Federal Government and private sector. Maveris Labs is a space for employees and customers to ask and explore answers to their burning “what if…” questions and to expand the limits of what is possible in IT and cybersecurity. To learn more, go to maveris.com
