Analysis of FTP Attack Response
Table of Contents
The particular attack that triggered this concern was the discovery that millions of credentials for FTP sites had been collected into a database that was for sale. We don’t know whether IHE’s FTP server was on that database, but it’s reasonable to assume that it is. IHE needs to respond to this attack. There are short term and long term responses that are appropriate.
The primary motivation for the attackers is to place malware infected documents on reputable servers so that emails, links, and other insertion attacks can use a reputable server as the distribution source. Current malware protections are good enough that many servers that were dedicated to propagating malware have been blacklisted.
The mechanism for the overall attach is shown below, with attack points A, B, and C:
|
A |
Client software is attacked by means of malware plugins or client vulnerabilities.
|
|
B |
The password database is sold to various malware authors. They use it to install malicious documents on FTP servers. The goal is not to attack the users of the FTP server, so malware authors look for unused areas where a few extra files will go unnoticed. These files may be HTML, PDF, JPEG, or some other format. They then refer to these files with a link in emails, web pages, etc. The black listing of known malware servers has increasingly interfered with this practice, so they look for innocent reputable servers that will not be black listed. |
|
C |
The malicious files are hidden among the bulk of legitimate useful files in the document store of the FTP server. |
The assets that IHE needs to protect are:
|
The public |
IHE does not want to harm the public by distributing malware. |
|
IHE reputation |
IHE does not want to acquire a reputation as a source of malware, or as indifferent to a public harm. |
|
IHE Documents |
IHE does not want the profiles, supporting material, and other documents to be damaged. |
|
Automation |
Many of the uses of the IHE website depend upon automatic scripts and tools. The present FTP site supports that kind of tool (curl, rsync, wget, etc.) The response should not interfere with this automation. |
|
Convenience |
The IHE documents are accessed by people from many countries and many companies. They should remain open to the public. This access should remain as convenient as the FTP access, or get better. |
|
Server Load |
The burdens on the IHE servers to provide access to these documents for both the public and the IHE commitee members preparing documents should not become excessive. |
There are a number of possible responses that I think worth analyzing. These are not mutually exclusive. There are both simple responses that can be made immediately, and more complex responses that involve more work. It is reasonable to make a few simple responses immediately and a more complex response later.
These responses have different costs and provide different mitigations. These are described in a Pugh table below and given a meaningless numerical rating.
|
Change the password |
This is as simple as it sounds. Changing the password eliminates the threat from the password database. The new password will eventually be discovered. Meaningless rating: 9 |
|
Switch to SFTP |
This is the step taken by many open source projects. With SFTP each user has unique credentials (SSH key) and there is no general password to be stolen. Meaningless rating: 8-11 |
|
Internally use git to control documents |
This step is also taken by many open sosurce projects. This does not prevent addition of malware, but it makes it very easy to detect and remove malware. It also provides protection against malicious and accidental destruction of documents. Meaningless rating: 9 |
|
Set up an IHE git server |
This is done by many open source projects, especially the larger ones. It requires the use of git clients, rather than FTP clients. There are a wide variety of git clients for all operating systems and many browsers. Meaningless rating: 14-17 |
|
Use github |
This is done by many open source projects, usually in conjunction with having their own git server. Github offers proprietary server extensions that simplify access by naive users, and that eliminate the need to install client software. They also provide extensive education, training, and server facilities. Meaningless rating: 19 |
|
Use git-annex |
Git is very inefficient at managing blobs (large binary objects). Microsoft word documents, JPEG, PDF, and other opaque binary files are very costly to the git servers. There are several efforts under way to reduce the server burden from these opaque binary files. Until the IHE documents are in a non-proprietary form understood by git (e.g., DocBook), the servers will suffer under a much heavier load. Unfortunately, these extensions are all in alpha or beta stages. None are production ready. Meaningless rating: 12 |
Table 1. Simple Attack responses
| Criteria | Change Password | Use SFTP | Internal Git |
|---|---|---|---|
|
Meaningless rating |
|
|
|
|
Mitigates |
|||
|
Credential Loss |
|
|
|
|
Password Trojans |
|
|
|
|
Routine Password Loss |
|
|
|
|
Protects |
|||
|
Public |
|
|
|
|
Reputation |
|
|
|
|
Documents |
|
|
|
|
Automation |
|
|
|
|
Convenience |
|
|
|
|
Server Load |
|
|
|
|
Harms |
|||
|
Public |
|
|
|
|
Reputation |
|
|
|
|
Documents |
|
|
|
|
Automation |
|
|
|
|
Convenience |
|
|
|
|
Server Load |
|
|
|
|
Other |
|||
|
Ongoing Effort |
|
|
|
|
Transition Cost |
|
|
|
|
Firewall Issues |
|
|
|
|
Technology Risk |
|
|
|
Table 2. Complex Attack responses
| Criteria | IHE Git Server | Git Hub | Git Annex |
|---|---|---|---|
|
Meaningless rating |
|
|
|
|
Mitigates |
|||
|
Credential Loss |
|
|
|
|
Password Trojans |
|
|
|
|
Routine Password Loss |
|
|
|
|
Protects |
|||
|
Public |
|
|
|
|
Reputation |
|
|
|
|
Documents |
|
|
|
|
Automation |
|
|
|
|
Convenience |
|
|
|
|
Server Load |
|
|
|
|
Harms |
|||
|
Public |
|
|
|
|
Reputation |
|
|
|
|
Documents |
|
|
|
|
Automation |
|
|
|
|
Convenience |
|
|
|
|
Server Load |
|
|
|
|
Other |
|||
|
Ongoing Effort |
|
|
|
|
Transition Cost |
|
|
|
|
Firewall Issues |
|
|
|
|
Technology Risk |
|
|
|
I recommend that we take two steps immediately:
- Change the FTP password
- Put the FTP directory under internal git control within the IHE server. Making this available for public git access would be interesting, but that could also be a later step. Then automatic checkins can be performed daily. The git logs can be used to detect and report all modifications. Modifications that appear to be malware can be reversed and removed. The blob impact will be large. Probably each committee directory will need to be a separate git repository, and some may need to be re-organized and have excessively huge blobs (like movies) moved outside repositories.
Then on a longer term,
- Transition to using github. This should be in conjunction with an IHE controlled git server. The IHE controlled server provides a backup and alternative in the event that the github organization fails or becomes problematic. Other similar server organizations have had problems, bankruptcies, etc. The transition to github may be problematic due to the use of large blobs such as MS-word documents, JPEGs, MPEGs, etc. in IHE. But disk space and processors are getting cheaper, and github may view the IHE level of waste as tolerable.
Comments