Persistent Cross-Interface Attacks 

Download Article Article in Digital Form

With the advent of new technologies, exploitation trends have shifted from systems to the web. This is due to the fact that system vulnerabilities are getting harder to exploit, while exploitation through the web is made easy via infecting web sites with malware. A number of network devices are using web and back-end interfaces for administrative operations. These network devices include disk stations, firewalls, routers, modems and switches that are used heavily in home and organizational networks. The back-end administration interfaces include File Transfer Protocol (FTP) and Telnet. No doubt, the web has provided ease and flexibility, but it has greatly impacted the privacy and security of users and is prone to malware infections. Web interfaces also provide ease and flexibility, but at a cost: These web-facing network devices are prone to security vulnerabilities.

This article explores the types of attacks and vulnerabilities that persist within network devices supporting both web and traditional administrative interfaces. The vulnerability of one network-based storage device, Synology DiskStation Manager [DSM], was selected for analysis. The goal is to understand the vulnerability and exploitation technique used to conduct a successful cross-interface attack (CIA), which is defined as the use of one interface to attack another interface. For example, an FTP console interface can be used to attack a web interface. Knowledge and understanding of these types of attack patterns are required to conduct aggressive testing while performing security assessments.

To conduct any specific category of attacks, both an appropriate entry point and an attack surface are required. Efficient attacks result in gaining maximum information with minimum intervention in the system.1 There are a number of cross-site request forgery (CSRF) vulnerabilities that have occurred in network devices,2, 3, 4 but most of them follow a similar pattern, requiring exploitation of browser inefficiencies.5 CSRF is a class of attacks in which the attacker exploits the user session to execute commands on the running server or in the application itself.6 These attacks are prevalent in web applications and require robust solutions;7,8 however, it has been noticed that web applications used for managing network devices are usually designed in an insecure way. A related type of attack has targeted the Juniper firewall.9 Attacks through back-end consoles have not been explored much.

The vulnerability discussed in this article was detected in Synology DSM and was disclosed to the vendor,10, 11, 12 and the vulnerability is patched in the latest versions of Synology DSM. Using a step-by-step approach, this article explores the attacking technique related to this vulnerability and how back-end login (administrative) consoles are used to launch CIAs. Remote command execution through CSRF is quite reliable in this sort of attack, and certain techniques follow a tactical way of enumerating the information from the consoles that can also be helpful in launching attacks in vulnerable applications.13 If the network device follows the vulnerable design pattern explained in this article, an attacker can perform CIAs.

Threat Model

An attacker can exploit the remote command execution vulnerability by injecting commands through the FTP administrative console (i.e., username and password) to render payloads in the web application interface of network devices. There are a variety of injections that an attacker can use to exploit this type of vulnerability. The attacker’s goal is to exploit the design of back-end login consoles (FTP consoles). Remote code execution through CSRF includes the possibility of adding users, deleting records and modifying configurations on the network device management module per the attacker’s need.

The threats associated with this vulnerability are enumerated based on the risks as follows:

Remote command execution through CSRF—This type of vulnerability addresses the remote code execution behavior through the CSRF strings that are injected through the input point and are rendered in the web application to produce the desired impact. The possibility of remote code execution is higher because administrative privileges are used to conduct these types of attacks in the system.

Malware infections—Cross-site scripting vulnerabilities allow the attacker to inject malicious links in the web interface. Upon executing such a link, the malware is automatically downloaded into the server. The attacker can inject code to execute drive-by download attacks or further exploit the vulnerabilities of the running web server to increase the infection rate.14, 15 iFrame injections lead to a more subtle malware infection. The Hypertext Transmission Protocol (HTTP) specification allows the effective use of iFrame to embed one web page into another web page. The embedding is irrespective of the domain to which a page belongs, and can be used in a cross-domain context. Since iFrames are interactive in nature, it is possible to bypass a same origin policy (SOP), and it is easy to launch cross-domain attacks (CDA) if a certain set of vulnerabilities exists in the base software or in web applications.

Information theft—In broad terms, the information regarding administrative sessions can be compromised through cookie-stealing attacks. The injected code leverages the already-set-up session and transfers the cookie to a third party, thereby resulting in theft of the information from the system.

Understanding the Design and Vulnerability

Most network-facing devices provide multiple ways to access firmware, such as by having the administrative web interface running on a specific port or back-end access through FTP or Telnet consoles. A similar set of vulnerabilities has been observed across network devices that can be exploited in a generic manner. For example, misconfiguration can result in compromise of the network device through administrative consoles that are used for login purposes.

For testing and conducting attacks, it is useful to understand the design of the application. Automated testing to find patterns provides an edge in determining the loopholes and workflow of the deployed system. Manual testing can expose hidden functionality of web applications that cannot be found using automated tools alone. Generally, the FTP login console provides an FTP logging (error) mechanism. This means that any unsuccessful attempt to connect to the FTP server is logged in the web application logging module. Network device firmware uses the web application interface for all types of operations. Any user who logs into the application through the FTP console will be scrutinized through the FTP login detector module, and the response is sent back to the user (or attacker). Meanwhile, the credentials provided by the user are logged in the FTP logs module; the details are presented in figure 1.

Figure 1

The vulnerability and inconsistency are seen in the fact that errors generated at the FTP login console are stored in the access logs in the web application. Many devices do not use appropriate filtering mechanisms; hence, injected payload is executed in the context of web application, resulting in remote code execution through, for example, CSRF or malware infection.

The vulnerability revolves around the FTP logging mechanism. Primarily, the FTP logs are rendered as text or HTML content in the web interface, depending on the content-type parameters. Whatever input is supplied by the attacker is inserted as a log entry. An important observation is that the log process runs as “administrator” or “root,” which means that any malicious code injected into logs will run in privileged mode. Further, the logs are not rendered in a customized format, which allows Document Object Model (DOM) and HTML elements to be rendered as dynamic content in the browser’s JavaScript interpreter. In addition, no specific security mechanism is applied, such as a generic sandbox, to avoid the code execution through injected parameters. Of course, in this context, proper security would filter input prior to logging it. This is a design problem that has been found in many network devices.16

Attack Steps and Techniques

This section details a single type of attack, but many variations can work:

  1. Validating the default buffer length in the FTP console
  2. Fingerprinting FTP error codes
  3. Injecting payloads

Step 1—Validating the Default Buffer Length in the FTP Console
In the first step, the attacker tries to validate the default buffer length accepted by the FTP console. The attacker can tactically enumerate information available from administrative consoles, which is useful in building an attack. The attacker can determine the possible length of the string of a username that is accepted by the FTP server. To get this information, the attacker can use a default buffer trick, as presented in figure 2.

Figure 2

The 331 response code shown in figure 2 provides information about the username and asks for the password. The attacker can easily compute the string length that is acceptable in the username field. In this case, it is approximately 80–100 characters. Once this information is known, it becomes easier for the attacker to design reliable injections pertaining to the limit of accepted characters. This information can be exploited through back-end login consoles.

Step 2—Fingerprinting FTP Error Codes
In the second step, the attacker fingerprints the error code returned by the running FTP server and any input that is passed through the FTP console. It is possible to use the FTP server consoles to inject payloads into the username and password fields. In this way, an attacker can use a back-end login console to inject unauthorized code. The default design of FTP allows for the acceptance of both the username and password prior to the authentication process; however, there are a number of FTP servers that perform user verification prior to authentication. User verification without a password in the authentication process is not a good security practice because the attacker can enumerate users on the system by interpreting the errors. It indirectly helps in enumerating the users, as presented in figure 3.

Figure 3

Figure 4In this example, the normal functionality of an FTP server is manipulated by the attacker, as arbitrary code is injected as input into the username and password prompts. Of course, the authentication fails, but it generates connection failure errors in the web application logs. The error-handling mechanism used in the FTP console provides information, such as the presence of user accounts in the system, to the attacker that is quite useful in generating an attack surface. For example, a malicious input injected through an FTP login console shows the acceptable string length, thereby prompting for a password, such as the 331 response code discussed earlier. The error-reporting mechanism should be used in conjunction with the FTP authentication module to restrict the acceptance of malicious input through login consoles. FTP generates errors, as presented in figure 4.

Step 3—Injecting Payloads
In the final step, the attacker injects a payload in the acceptable buffer length. The details of this step are explained in the case study discussed in the next section. In the design of some web applications, security weaknesses exist in the form of dependencies among different modules, allowing access to the underlying system. Complex designs result in security failures. This defect has shown the stature of insecure and inappropriate design of web interfaces in network devices.

Case Study —Synology Diskstation Manager

This section discusses a specific vulnerability in Synology DSM to illustrate how an attacker can exploit the environment. Synology DSM is a network device used by organizations to manage data in a centralized environment. Of course, it is a hardware-based solution with administrative interfaces. Before examining the vulnerability pattern, it is advised to determine the application design and a generalized flow of information.

Figure 5The vulnerability in Synology DSM was discovered as a result of the remote compromise of the product due to a weak configuration that provided access to all modules with highest privileges. It provided an inbound and outbound control that could allow an attacker to scrutinize the way in which the product handled the input code from different interfaces. The product uses GET requests to manage the control of logging activity, as presented in figure 5.

The user is added through userman.cgi, as presented in figure 6.

Figure 6

Synology DSM uses a normal POST request for adding a user by submitting a form with variables. On further analysis of the application, it was detected that the product allows the FTP login console as an entry point to inject data. By default, the FTP login console does not scrutinize the types of strings that are passed. The attacker can inject malicious code or attack payloads because strings are not filtered. The injected rogue code is not a registered FTP user; as a result, the login is not allowed and fails with an error. Consequentially, it is noticed that errors are logged in the FTP connection log module with inappropriate content-type specification, which allows the injected code from the FTP login console to render code as HTML, JavaScript, etc. The injection occurs in the context of admin privileges, which increases the impact of the attack.

To illustrate the attack, a differential set of tests was performed, as presented in figure 7.

Figure 7

The testing resulted in positive artifacts regarding the successful remote execution of the code. The output of the attacks is presented in figures 8 and 9.

Figure 8

Figure 9

It is possible to perform remote command execution when deleting logs and adding users through stealth CSRF attacks injected through the FTP login console. The exploitation can be extended using the advanced codes presented in figure 10.

Figure 10

The major risks are of malware infection and remote command execution. The severity of CIAs is high because they infect the server machines on a large scale.


The FTP login consoles or the user verification module should scrutinize the string parameter before verifying the user. A white-list approach should be followed at the protocol level to reduce the impact of exploitation. The applied-design principle should be simple to avoid obscuring vulnerabilities. For example, FTP logs should be rendered in a more customized environment, considering access to a number of clients. The content should be filtered to avoid the use of malicious input, thereby appropriately defining the content type.


This article discussed a unique set of attacks in network devices. The exploitation of a vulnerability depends on the environment, and design plays a critical role in determining the successful exploitation of a vulnerability. Insecurities may prevail in the web interface design of network devices due to lack of security controls. As a result, these devices provide opportunities for attacks. The attacks are more devastating because they result in full compromise of the servers that are providing network services. As discussed in this article, the attack surface depends on several factors, and even a single loophole results in exploitation. The lesson here is that network devices should be developed with due diligence and that secure design principles should be followed.


1 Sood, Aditya K.; “FTP Anonymous Services—User and Reconnaissance,” Security Space for the Untamed Minds, 6 August 2009,
2 Brown, Jeremy; “Cisco Router HTTP Administration CSRF Remote Command Execution Universal Exploit (2),”,
3 Lindberg, Henri; Smilehouse Oy; “A-Link WL54AP3 and WL54AP2 CSRF+XSS Vulnerability,” SecurityFocus, 31 October 2008,
4 “Siemens ADSL SL2-141 XSRF Exploit,” Packet Storm, 26 January 2009,
5 Alme, Christoph; Web Browsers: An Emerging Platform Under Attack, McAfee, USA, 2009,
6 Burns, Jesse; “Cross Site Request Forgery: An Introduction to a Common Web Application Weakness, Version 1.2,” Information Security Partners LLC, USA, 2007,
7 Jovanovic, Nenad; Engin Kirda; Christopher Kruegel; “Preventing Cross Site Request Forgery Attacks,”
8 Barth, Adam; Collin Jackson; John C. Mitchell; “Robust Defenses for Cross-site Request Forgery,” CCS’08, 27–31 October 2008,
9 US Computer Emergency Readiness Team (US-CERT), “Vulnerability Summary for CVE-2008-6096,” National Vulnerability Database (NVD), 8 March 2011,
10 Common Vulnerabilities and Exposures, “CVE-2010-2453,”
11 Branco, Rodrigo Rubira; Aditya K. Sood; “Web Commands Injection Through FTP Login in Synology Disk Station,”
12 Check Point Software Technologies Ltd., “Update Protection Against Synology Disk Station FTP Login Web Commands Injection Vulnerability,”
13 Op cit, Sood
14 Cova, Marco; Christopher Kruegel; Giovanni Vigna; “Detection and Analysis of Drive-by-download Attacks and Malicious JavaScript Code,” WWW 2010, 26–30 April 2010,
15 Egele, Manuel; Engin Kirda; Christopher Kruegel; “Mitigating Drive-by Download Attacks: Challenges and Open Problems,”
16 Op cit, US-CERT

Aditya K. Sood
is a security researcher and doctoral candidate at Michigan State University (USA) and has worked in the security domain for Armorize, COSEINC and KPMG. Sood is a founder of SecNiche Security Labs, an independent security research arena for cutting-edge computer security research.

Richard J. Enbody, Ph.D.,
is associate professor in the Department of Computer Science and Engineering at Michigan State University (USA), where he joined the faculty in 1987. His research interests include computer security, computer architecture, web-based distance education, and parallel processing. Enbody has two patents pending on hardware buffer-overflow protection that could prevent most computer worms and viruses.

Enjoying this article? To read the most current ISACA Journal articles, become a member or subscribe to the Journal.

The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.

© 2011 ISACA. All rights reserved.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.