August 18, 2016 | 6 min read
On the Topic of Sage
Specifically, what I found were over 20 unprotected MongoDBs, under the control of Sage customers, powering “on premises” versions of Sage’s X3 server software suite. The Shodan.io search term used to unearth the list of unprotected installations was “port:27017 syracuse”. It appears that “syracuse” is an X3 server reference term.
X3 servers are intended for companies with over 200 employees, so finding more than 20 of them completely exposed to the public internet, with no username or password required for access, was a little unnerving. As you can imagine, some of these servers contained massive amounts of company records in the form of PDFs, DOCs, and XLS spreadsheets.
Initially I had assumed that these servers were under the control of Sage itself and, accordingly, I sent an email notification earlier this week to the company regarding my findings. High-level Sage staff members sent a response back within hours (rather impressive when considering the UK time zone difference). We engaged in a telephone conversation shortly thereafter. The Sage representatives were very clear that while they claim Sage is not at fault for these breaches, Sage is extremely concerned with any situation involving their software being implemented insecurely by clients.
Sage immediately began a process of reviewing the IP addresses I supplied to them and notifying affected customer companies that have been insecurely utilizing Sage’s X3 server software. For a company that is claiming to not be at fault, it is noble that Sage would embark on such a quest to notify exposed companies spanning across the globe. Although, considering the potential public relations problems, it is probably in Sage’s best interest to do so. That process started two days ago.
So, what other kinds of interesting stuff did I find? Well, the first sign that these servers hadsomething to do with Sage was the presence of “[name]@sage.com” login credentials. Initially I considered the possibility that this situation could be the cause of Sage’s “insider credential” data breach. That has turned out to not be the case, but the possibility was interesting to say the least.
I can also tell you that certain identical password hashes were present across many of the installations. That strongly indicates identical default passwords being commonplace in X3 server implementations. Of course there were also client-specific login credentials as well, and who wants to bet that many of those hashes could be cracked and used to access the also-exposed RDP services and SQL servers found at many of the same IPs?
Also worth noting-- Sage confirmed that one of the exposed X3 servers I located was set up by Sage itself as a demonstration unit. That begs the questions of why Sage would deploy a server, even if it was a demo, that contradicts its own best practices and instructions. A company as large and advanced as Sage should have IT staff that can run a VPN if something like access from a remote demo site is necessary.
I will likely catch some flak for now publishing details on how to locate this type of server. My decision to say something at this point is driven by a few key aspects. First of all, I’ve found logs indicating that I am not the first person to discover these exposed servers, so remaining silent would run the risk of less well-intentioned people plundering the data (if none have done so already). Secondly, there’s already been two days of Sage working around the clock to notify these exposed companies. If a client company’s IT staff is too inept to respond to this kind of urgent notification by now, then there’s little hope they will in the near future.
So, I’m left with what I’ll refer to as “the nuclear option.” That option being to ring some alarm bells and get a public message out. The message is simple: Sage’s on premise X3 software are not designed to be exposed to the public internet. If you are a large Sage client, make sure that your software installations are behind a firewall or, at the very least, you have some sort of access restrictions in place. Most companies do, but I know of at least 20 that did not… and the possible repercussions for those clients are frightening.
Attention - Portions of this article may be used for publication if properly referenced and credit is given to MacKeeper Security Researcher, Chris Vickery.
Stay tuned to the latest security news by visiting MacKeeper Security Watch blog with Chris Vickery.