Vulnerabilities > CVE-2017-14728 - Use of Hard-coded Credentials vulnerability in Orpak Siteomat
Attack vector
NETWORK Attack complexity
LOW Privileges required
NONE Confidentiality impact
HIGH Integrity impact
HIGH Availability impact
HIGH Summary
An authentication bypass was found in an unknown area of the SiteOmat source code. All SiteOmat BOS versions are affected, prior to the submission of this exploit. Also, the SiteOmat does not force administrators to switch passwords, leaving SSH and HTTP remote authentication open to public.
Vulnerable Configurations
| Part | Description | Count |
|---|---|---|
| Application | 1 |
Common Weakness Enumeration (CWE)
Common Attack Pattern Enumeration and Classification (CAPEC)
- Reverse Engineering An attacker discovers the structure, function, and composition of an object, resource, or system by using a variety of analysis techniques to effectively determine how the analyzed entity was constructed or operates. The goal of reverse engineering is often to duplicate the function, or a part of the function, of an object in order to duplicate or "back engineer" some aspect of its functioning. Reverse engineering techniques can be applied to mechanical objects, electronic devices or components, or to software, although the methodology and techniques involved in each type of analysis differ widely.
- Software Reverse Engineering An attacker discovers the structure, function, and composition of a type of computer software by using a variety of analysis techniques to effectively determine how the software functions and operates, or if vulnerabilities or security weakness are present within the implementation. Reverse engineering methods, as applied to software, can utilize a wide number approaches and techniques. Methodologies for software reverse engineering fall into two broad categories, 'white box' and 'black box.' White box techniques involve methods which can be applied to a piece of software when an executable or some other compiled object can be directly subjected to analysis, revealing at least a portion of its machine instructions that can be observed upon execution. 'Black Box' methods involve interacting with the software indirectly, in the absence of the ability to measure, instrument, or analyze an executable object directly. Such analysis typically involves interacting with the software at the boundaries of where the software interfaces with a larger execution environment, such as input-output vectors, libraries, or APIs.
- Reverse Engineer an Executable to Expose Assumed Hidden Functionality or Content An attacker analyzes a binary file or executable for the purpose of discovering the structure, function, and possibly source-code of the file by using a variety of analysis techniques to effectively determine how the software functions and operates. This type of analysis is also referred to as Reverse Code Engineering, as techniques exist for extracting source code from an executable. Several techniques are often employed for this purpose, both black box and white box. The use of computer bus analyzers and packet sniffers allows the binary to be studied at a level of interactions with its computing environment, such as a host OS, inter-process communication, and/or network communication. This type of analysis falls into the 'black box' category because it involves behavioral analysis of the software without reference to source code, object code, or protocol specifications. White box analysis techniques include file or binary analysis, debugging, disassembly, and decompilation, and generally fall into categories referred to as 'static' and 'dynamic' analysis. Static analysis encompasses methods which analyze the binary, or extract its source code or object code without executing the program. Dynamic analysis involves analyzing the program during execution. Some forms of file analysis tools allow the executable itself to be analyzed, the most basic of which can analyze features of the binary, such as the strings contained within the file. More sophisticated forms of static analysis analyze the binary file and extract assembly code, and possibly source code representations, from analyzing the structure of the file itself. Dynamic analysis tools execute the binary file and monitor its in memory footprint, revealing its execution flow, memory usage, register values, and machine instructions. This type of analysis is most effective for analyzing the execution of binary files whose content has been obfuscated or encrypted in its native executable form. Debuggers allow the program's execution to be monitored, and depending upon the debugger's sophistication may show relevant source code for each step in execution, or may display and allow interactions with memory, variables, or values generated by the program during run-time operations. Disassemblers operate in reverse of assemblers, allowing assembly code to be extracted from a program as it executes machine code instructions. Disassemblers allow low-level interactions with the program as it executes, such as manipulating the program's run time operations. Decompilers can be utilized to analyze a binary file and extract source code from the compiled executable. Collectively, the tools and methods described are those commonly applied to a binary executable file and provide means for reverse engineering the file by revealing the hidden functions of its operation or composition.
- Read Sensitive Strings Within an Executable An attacker engages in activities to discover any sensitive strings are present within the compiled code of an executable, such as literal ASCII strings within the file itself, or possibly strings hard-coded into particular routines that can be revealed by code refactoring methods including static and dynamic analysis. One specific example of a sensitive string is a hard-coded password. Typical examples of software with hard-coded passwords include server-side executables which may check for a hard-coded password or key during a user's authentication with the server. Hard-coded passwords can also be present in client-side executables which utilize the password or key when connecting to either a remote component, such as a database server, licensing server, or otherwise, or a processes on the same host that expects a key or password. When analyzing an executable the attacker may search for the presence of such strings by analyzing the byte-code of the file itself. Example utilities for revealing strings within a file include 'strings,' 'grep,' or other variants of these programs depending upon the type of operating system used. These programs can be used to dump any ASCII or UNICODE strings contained within a program. Strings can also be searched for using a hex editors by loading the binary or object code file and utilizing native search functions such as regular expressions. More sophisticated methods of searching for sensitive strings within a file involve disassembly or decompiling of the file. One could, for example, utilize disassembly methods on an ISAPI executable or dll to discover a hard-coded password within the code as it executes. This type of analysis usually involves four stages in which first a debugger is attached to the running process, anti-debugging countermeasures are circumvented or bypassed, the program is analyzed step-by-step, and breakpoints are established so that discrete functions and data structures can be analyzed. Debugging tools such as SoftICE, Ollydbg, or vendor supplied debugging tools are often used. Disassembly tools such as IDA pro, or similar tools, can also be employed. A third strategy for accessing sensitive strings within a binary involves the decompilation of the file itself into source code that reveals the strings. An example of this type of analysis involves extracting source code from a java JAR file and then using functionality within a java IDE to search the source code for sensitive, hard-coded information. In performing this analysis native java tools, such as "jar" are used to extract the compiled class files. Next, a java decompiler such as "DJ" is used to extract java source code from the compiled classes, revealing source code. Finally, the source code is audited to reveal sensitive information, a step that is usually assisted by source code analysis programs.
- Protocol Reverse Engineering An attacker engages in activities to decipher and/or decode protocol information for a network or application communication protocol used for transmitting information between interconnected nodes or systems on a packet-switched data network. While this type of analysis inherently involves the analysis of a networking protocol, it does not require the presence of an actual or physical network. Although certain techniques for protocol analysis benefit from manipulating live 'on-the-wire' interactions between communicating components, static or dynamic analysis techniques applied to executables as well as to device drivers such as network interface drivers, can also be used to reveal the function and characteristics of a communication protocol implementation. Depending upon the methods used, protocol reverse engineering can involve similar methods as those employed when reverse engineering an executable, or the process may involve observing, interacting, and modifying actual communications occurring between hosts. The goal of protocol reverse engineering is to derive the data transmission syntax, as well as to extract the meaningful content, including packet or content delimiters used by the protocol. This type of analysis is often performed on closed-specification protocols, or proprietary protocols, but is also useful for analyzing publicly available specifications to determine how particular implementations deviate from published specifications. There are several challenges inherent to protocol reverse engineering depending upon the nature of the protocol being analyzed. There may also be other types of factors which complicate the process such as encryption or ad hoc obfuscation of the protocol. In general there are two kinds of networking protocols, each associated with its own challenges and analysis approaches or methodologies. Some protocols are human-readable, which is to say they are text-based protocols. Examples of these types of protocols include HTTP, SMTP, and SOAP. Additionally, application-layer protocols can be embedded or encapsulated within human-readable protocols in the data portion of the packet. Typically, human-readable protocol implementations are susceptible to automatic decoding by the appropriate tools, such as Wireshark/ethereal, tcpdump, or similar protocol sniffers or analyzers. The presence of well-known protocol specifications in addition to easily identified protocol delimiters, such as Carriage Return or Line Feed characters (CRLF) result in text-based protocols susceptibility to direct scrutiny through manual processes. Protocol reverse engineering against protocol implementation such as HTTP is often performed to identify idiosyncratic implementations of a protocol by a server or client. In the case of application-layer protocols which are embedded within text-based protocols, analysis techniques typically benefit from the well-known nature of the encapsulating protocols and can focus on discovering the semantic characteristics of the proprietary protocol or API, since the syntax and protocol delimiters of the underlying protocols can be readily identified. When performing protocol analysis of machine-readable (non-text-based) protocols difficulties emerge as the protocol itself was designed to be read by computing process. Such protocols are typically composed entirely in binary with no apparent syntax, grammar, or structural boundaries. Examples of these types of protocols are IP, UDP, and TCP. Binary protocols with published specifications can be automatically decoded by protocol analyzers, but in the case of proprietary, closed-specification, binary protocols there are no immediate indicators of packet syntax such as packet boundaries, delimiters, or structure, or the presence or absence of encryption or obfuscation. In these cases there is no one technology that can extract or reveal the structure of the packet on the wire, so it is necessary to use trial and error approaches while observing application behavior based on systematic mutations introduced at the packet-level. Tools such as Protocol Debug (PDB) or other packet injection suites are often employed. In cases where the binary executable is available, protocol analysis can be augmented with static and dynamic analysis techniques.
Seebug
| bulletinFamily | exploit |
| description | A few months ago, while undertaking unrelated research into online connected devices, we uncovered something surprising and realized almost immediately that we could be looking at a critical security threat. What we found was a simple purple web interface that was in fact a link to a real-life gas station, and we suspected this link made the station remotely hackable. Amihai Neiderman, then working for Azimuth security, and I investigated the findings. When our suspicions turned out to be true, we reported them to the vendor. The story was covered recently by [Motherboard VICE](https://motherboard.vice.com/en_us/article/43qkgb/flaws-in-gas-station-software-let-hackers-change-prices-steal-fuel-erase-evidence), and here we will share some of the technical details behind it. Further details of this research will be shared in early March at the [Security Analyst Summit 2018](https://sas.kaspersky.com/) in Cancun. The device we investigated was not just a tiny web interface. It was an embedded box running a Linux-based controller unit that was installed with a tiny httpd server. According to its manufacturer, the controller’s software is a site automation device that is responsible for managing every component of the station, including dispensers, payment terminals and more. More specifically, the controller is at the heart of the station and if an intruder finds a way to take over the box, the results could be catastrophic. Another worrying detail, discovered later in the research, was when the solution was installed – many instances were embedded in fueling systems over a decade ago and have been connected to the internet ever since. Before the research, we honestly believed that all fueling systems, without exception, would be isolated from the internet and properly monitored. But we were wrong. With our experienced eyes, we came to realize that even the least skilled attacker could use this product to take over a fueling system from anywhere in the world. ### Hide & seek The fuel stations we found using this product carried a watermark that can be found by running a search query with just one keyword. Within a few seconds, all those that are connected reveal their exact location and listening services. The following chart uses data from an online search engine and other sources to show the geographical spread of the fuel stations. We found that more than 1,000 gas stations are accessible from any computer in the world. And when it comes to [IoT](https://securelist.com/threats/internet-of-things-glossary?utm_source=securelist&utm_medium=blog&utm_campaign=termin-explanation) hacking, gas stations are a far more dangerous target than webcams, for example.  Top countries with gas stations open to the internet (data from Shodan and telemetry sources) Most of the research involved reviewing the information available online. It seems that the manufacturer posted much of the device’s technical information, allowing clients to go online and grab it. The user manuals were very detailed. They included screenshots, default credentials, different commands and a step-by-step guide on how to access and manage each of the interfaces. That alone assisted us in gaining all the information we needed, before we even wrote a single line of code. We understood how obsolete the device was when we realized it was operative and accessible remotely using services you don’t expect to see in modern devices. The user manual carefully listed the services it was using and the network architecture. Understanding how the device operates in the network doesn’t require special hacking skills.  Network layout showing the main controller unit and its access privileges ### Default credentials We found many places where default credentials were mentioned. Using the online search engine, we even saw proof that the services listed in the manual were scraped by the engine at some point in time. Since the engine itself is fairly new, it is believed that the services are also accessible. Among the rest, SSH, HTTP and X11 were marked as potential access backdoors.  Shift management login page with security issues allowing complete bypass During the research, we were able to log in to one shift management console. But that was just one instance – how could we be sure that all the other stations were accessible as well? We needed to ask permission from a gas station owner to let us access the station when it was offline. We wanted to understand what exactly was behind that web interface. Did it have the same functionality as a web camera, or could we actually find a critical issue that could cause major damage?  The shift management console The console appeared very robust. Considering the level of technical knowledge a shift manager is required to have, the functionality would allow them to pretty much change the dispenser settings, including gas station prices, printer settings, shift reports and more. The risk here stems from a malicious insider – a shift manager can modify shift reports, printed receipts and the actual gas price. We believe that such privileges should be reserved for the gas station owner only. In addition, we suspect that there are more interfaces in the network which allow a shift employee to track the convenience store and payment terminal using high privileges as well. In the sketch above, there was no mention of any protection software in place.  Functionality to change gas prices available to gas station shift manager The next step in the research was to verify if we could access the station remotely without any credentials. We started looking for creative ways to bypass the authentication mechanism. Presuming it was obsolete and not properly tested before being deployed, we didn’t expect it to take more than a day or two. ### A snake in the haystack We were positive that a coding vulnerability would be the first thing to surface, but it was something we least expected to find that first caught our attention. Once the initial firmware dump and main binary reversing step was completed, we searched for the login mechanism within the decompiled code. To our surprise, the following ‘if’ condition was a core part of that mechanism. It was a hardcoded username and password. In other words, a manufacturer backdoor for cases when the device requires remote or local access with the highest privileges.  Hardcoded credentials, a zero-day vulnerability reserved with CVE-2017-14728 Every similar device belonging to that vendor, up to the version we found, contained these hardcoded credentials. We reported our findings to MITRE to reserve the CVE, and contacted the vendor. In addition to hardcoded passwords, we found many areas that we suspect contain insecure code and which might allow code to be executed remotely. One of these components – soWebServer::XMLGetMeansReportRowsNumber code review boiled down to a name parameter which is being controlled by the end user and is prone to a stack-based buffer overflow attack. Based on that finding, we compiled a fully working remote code execution. Part of that code is in the following screenshot.  Code for remote login and stack buffer overflow Another code area which captured our attention was an authentication component which contained SQL injection. Throughout the entire analysis, we haven’t found SQL injection preventions to be sufficient. This is one example:  Code to extract gas station’s name and location ### Geo exploitation It is perfectly plausible that an IP address shows the actual location of a gas station, but we wanted to dig even further into the code and understand whether a gas station owner actually inputs the name of the gas station, or any location ID that can be traced, to find the actual location, gas vendor and other information related to that location. We found an XML component which is responsible for generating reports on a daily basis. It was found to contain a parameter that holds the actual name and location of the station. We wrote a quick proof of concept to simply extract this parameter’s value.  Code to extract gas station’s name and location As said, the code was not tested globally, but in the one case we had, it did extract the name, which after a few searches retrieved the exact location, vendor name and contact details. ### Update price Given the possibility of utilizing the hardcoded credentials to access the SiteOmat’s web interface and tamper with the update_price.cgi component’s input parameters, an intruder would be able to change the fuel price. To reproduce such attempt, first thing that needs to be done is to extract the victim dispenser’s information in a JSON format, to better understand which products are being sold and for what price. This can be achieved using one of the XML files responsible for storing the real-time prices in the local database.  Code snippet taken from the price modification proof of concept Each product has an ID, a gas type, a name following the type and price. An intruder only needs to modify the gas type in order to update the price. Once the intruder decides which of the prices to change, they will have to query for the relative CGI component that changes the price. ### The payment terminal An intruder that gains access to the gas station is able to connect directly to the payment terminal, and either extract payment information or directly exploit the payment bridge to steal transactions. We did not cover that area in our research since we lacked the access to the gas station network, though we strongly believe that it requires inspection and testing. ### What an intruder can do To give you some idea of the capabilities an intruder gains when taking over a gas station system through the vulnerable device we uncovered, here are a few scenarios: * Shut down all fueling systems * Cause fuel leakage and risk of casualties * Change fueling price * Circumvent payment terminal to steal money * Scrape vehicle license plates and driver identities * Halt the station’s operation, demanding a ransom in exchange * Execute code on the controller unit * Move freely within the gas station network To the best of our knowledge, the vulnerable gas stations have not yet been asked to disable remote access through this controller. On September of 2017, we alerted the vendor to the issues and offered to send full technical details to help ensure the vulnerabilities could be fixed. The Motherboard Vice article referenced a recent incident in Moscow where a hacker helped to fraudulently siphon gas from customers using malicious code – but we do not believe this incident is related to the area of our research. Our online search did not find any gas stations in Russia with this controller installed, and a recent presentation in Moscow of our ongoing research did not make public the name of the product, its manufacturer or technical details of the vulnerabilities. MITRE received reports on the vulnerabilities found during the research, though triage is still in process. CERT IL & US were also updated with details about the vulnerabilities. ### Reported vulnerabilities – MITRE  |
| id | SSV:97288 |
| last seen | 2018-06-26 |
| modified | 2018-05-14 |
| published | 2018-05-14 |
| reporter | My Seebug |
| title | SiteOmat Station Automation Software Multiple Vulnerabilities |