This module exploits a remote command execution vulnerability in the Sonicwall SRA Appliance Version <= v8.1.0.2-14sv. The vulnerability exist in a section of the machine's adminstrative infertface for performing configurations related to on-connect scripts to be launched for users's connecting.
This module exploits a remote command execution vulnerability in the Sonicwall SRA Appliance Version <= v8.1.0.2-14sv. The vulnerability exist in a section of the machine's adminstrative infertface for performing configurations related to on-connect scripts to be launched for users's connecting.
The Sonicwall Secure Remote Access server (ver 8.1.0.2-14sv) is vulnerable to two Remote Command Injection vulnerabilities in it's web administrative interface. These vulnerabilies occur in the diagnostics CGI (/cgi-bin/diagnostics) component responsible for emailing out information about the state of the system. The application doesn't properly escape the information passed in the 'tsrDeleteRestartedFile' or 'currentTSREmailTo' variables before making a call to system() allowing for remote command injection. Exploitation of this vulnerability yeilds shell access to the remote machine under the useraccount 'nobody'.
This exploit is a buffer overflow vulnerability in Sync Breeze Enterprise. It allows an attacker to send a malicious request to the server, which can cause the server to crash or execute arbitrary code. The exploit is triggered by sending a specially crafted request with an overly long username and password. The request is sent to the server via a POST request to the /login endpoint. The request contains a Content-Length header that is set to the length of the malicious request, which is longer than the expected length. This causes the server to crash or execute arbitrary code.
The application is vulnerable to server side request forgery attacks. We were able to use the web server to send packets internally and thereby perform port scan on other internal assets and/or obtain information accessible only from inside or otherwise not accessible to an external user. It was also possible to query internal server information otherwise unavailable publicly.
There is a type confusion issue related to how some arithmetic operations are performed in VBScript. To illustrate, see the following simplified code of VbsVarMod static unsigned char result_lookup_table[18][18] = {...} void VbsVarMod(VAR *v1, VAR *v2) { VAR *arith_v1 = v1->PvarGetArithVal(); VAR *arith_v2 = v2->PvarGetArithVal(); int result_type = result_lookup_table[v1->vartype][v2->vartype]; if(result_type == 10) { RaiseError(...); } if(result_type == 2) { ... } else if(result_type == 3) { ... } else if(result_type == 4) { ... } v1->vartype = result_type; } where the logic for VAR::PvarGetArithVal is roughly VAR *VAR::PvarGetArithVal() { VAR *result = this->PvarGetVarVal() if(result->vartype > 17) RaiseError(...); } The VbsVarMod function (as well as many other arithmetic functions) first gets the arithmetic values of input variables and then uses the lookup table to determine the result type. PvarGetArithVal tries to ensure that the vartypes of input will be <18 so the lookup table won't be accessed out-of-bounds. The problem is that the call to v2->PvarGetArithVal() can run arbitrary script which can change the type of arith_v1. If we change v1 to an array (which typically has vartype of 8192), suddenly there will be an out-of-bound access when looking up the result type and the result type can become unexpected. In case of VbsVarMod() if the result type is not 10(Error),2(Integer),3(Long) or 4(single), the function will simply assign the result type to the result variable (v1), while the actual data will remain unchanged. This causes a type confusion in v1. Which result type an attacker can select depends on the build of vbscript.dll. On 64-bit Windows 10 in IE Version 11.1066.14393.0 (Update version 11.0.41) it is possible to set the result type to 5 (Double) which causes a heap pointer leak.
There is a memory corruption issue in IE that can be triggered with svg <use> element. The bug was confirmed on IE Version 11.0.9600.18617 (Update Version 11.0.40) running on Windows 7 64-bit. The PoC code is provided in the text. The crash log when the PoC is ran on 64-bit IE in the single process mode (TabProcGrowth=0) is also provided.
Low privileged users can directly access the administrator resources to download a full compressed file with configurations and files of the platform, a 300MB compressed file was downloaded in a production environment. The application is vulnerable to multiple cross-site scripting vulnerabilities. The application is vulnerable to reflected XSS in the following parameters: pyActivity, pyActivityParam, pyActivityParam.
Hashicorp's vagrant plugin for vmware fusion uses a product called Ruby Encoder to protect their proprietary ruby code. It does this by turning the ruby code into bytecode and executing it directly. Unfortunately the execution chain necessary for this to work is not safe. After installing the plugin, the first time you 'vagrant up' any vagrant file using vmware fusion it will create some files in ~/.vagrant.d/gems/2.2.5/gems/vagrant-vmware-fusion-4.0.18/bin. The first one is an encoded ruby script, the others are 'sudo helper' binaries for the different platforms supported by the plugin. Of these sudo helpers, the one that corresponds to your platform will be made suid root when vagrant up is run. Unfortunately the helper calls the ruby script with system('ruby <script path>') - i.e. it doesn't verify the path to the ruby script and it doesn't scrub the PATH variable either. We can easily exploit this to get root.
This module exploits a remote command execution vulnerability in the Barracuda Load Balancer Firmware Version <= v6.0.1.006 (2016-08-19) by exploiting a vulnerability in the web administration interface. By sending a specially crafted request it's possible to inject system commands while escalating to root do to relaxed sudo configuration on the local machine.
Services By CQR