Saturday, 24 October 2015

[EN] SOAP testing

During one of last projects I needed to test some webservices.

I was wondering: if I can do it with Burp or by manual testing,
maybe I can also write some quick code in python...

And that's how I wrote


root@kali:~/code/soapee-v3# cat
#!/usr/bin/env python
# -------------------------------------
# - SOAP fuzz - v0.2
# -------------------------------------
# 16.10.2015

import urllib2
import sys
import re
from bs4 import BeautifulSoup
import httplib
from urlparse import urlparse

target = sys.argv[1]

def sendNewReq(method):
  global soap_header
  print '[+] Sending new request to webapp...'
  toSend = open('./logs/clear-method-'+str(method)+'.txt','r').read()

  parsed = urlparse(target)
  server_addr = parsed.netloc
  service_action =  parsed.path

  body = toSend
  print '[+] Sending:'

  print '[+] Response:'

  headers = {"Content-type": "text/xml; charset=utf-8",
        "Accept": "text/plain",
        "SOAPAction" : '"' + str(soap_header) + '"'

#  print '***********************************'
#  print 'headers: ', headers
#  print '***********************************'
  conn = httplib.HTTPConnection(server_addr)
  conn.request("POST", parsed.path, body, headers)
#  print body
  response = conn.getresponse()

  print '[+] Server said: ', response.status, response.reason
  data =

  logresp = open('./logs/resp-method-'+ method + '.txt','w')

  print '............start-resp...........................................'
  print data
  print '............stop-resp...........................................\n'

  print '[+] Finished. Next step...'
  print '[.] -----------------------------------------\n'


def prepareNewReq(method):
  print '[+] Preparing new request for method: '+str(method)

  fp = open('./logs/method-'+str(method)+'.txt','r')
  fp2 = open('./logs/fuzz-method-'+str(method)+'.txt','w')

  for line in fp:
    if line.find('SOAPAction') != -1:
      global soap_header
      soap_header = line
      soap_header = soap_header.split(" ")
      soap_header = soap_header[1].replace('"','')
      soap_header = soap_header.replace('\r\n','')
#     print soap_header

    newline = line.replace('<font class="value">','')
    newline2 = newline.replace('</font>','')

    newline3 = newline2.replace('string','";\'>')
    newline4 = newline3.replace('int','111111111*11111')
    newline5 = newline4.replace('length','1337')
    newline6 = newline5.replace('<soap:','<soap:')
    newline7 = newline6.replace('</soap:','</soap:')
    newline8 = newline7.replace(' or ','or')


  print '[+] New request prepared.'

  print '[+] Clearing file...'
  linez = open('./logs/fuzz-method-'+str(method)+'.txt').readlines()



# compose_link(method), get it, and save new req to file
def compose_link(method):
  methodLink = target + '?op='+ method
  print '[+] Getting: ', method

  fp = open('./logs/method-'+str(method)+'.txt','w')

  req = urllib2.urlopen(methodLink)
  page =
  soup = BeautifulSoup(page)

  for pre in soup.find('pre'):

  print '[+] Method body is saved to file for future analysis.'



## main
def main():
  print '        _________________'
  print '        (*(( soapee ))*)'
  print '             ^^^^^^\n'

  url1 = urllib2.urlopen(target)
  page1 = url1.readlines()

  # get_links_to_methods
  print '[+] Looking for methods:\n------------------------'
  for href in page1:
    hr = re.compile('<a href="(.*)\.asmx\?op=(.*?)">') #InfoExpert.asmx?op=GetBodyList">GetBodyList</a>')
    found =,href)
    if found: # at this stage we need to create working link for each found method
      method =

      # found method get as URL for pre content to next request

  # ...
  #     ... get example of each req
  #           ... change each str/int to fuzzval
  #     ... send modified req
  print '---------------------------\ndone.'



except IndexError, e:
  print 'usage: ' + str(sys.argv[1]) + ' http://link/to/WebService.asmx\n'



As you can see it's just a proof of concept (mosty to find some useful information disclosure bugs) but the skeleton can be used to prepare more advanced tools.

Maybe you will find it useful.

Enjoy ;)

Friday, 2 October 2015


During couple of last days I was checking lcamtuf’s American Fuzzy Lop against some (“non-instrumented”) binaries. 

I was wondering, what will happen if I will run it against Java… ;)

I was looking for some sources, but unfortunately I wasn’t able to find any. Next thing was checking where I have Java installed (so I will know what/where I can check. Kind of ‘test lab’ was: Ubuntu 12, Kali Linux, WinXP, Win7. (Exact version of Java installed on that OS’s you will find below.)

After 2 days there were approx. 170 different samples. After first check, we can see that java (7) will 
end up with sigsegv (with SSP enabled – Kali Linux):

Same sample with Java 6 will produce:

Next thing I saw was:
*** buffer overflow detected ***: /usr/lib/jvm/java-7-openjdk-i386/jre/bin/java terminated

During the analysis of the crash file in gdb I found some “new” function names. I decide to find them also but in Ida Pro and check, what is their purpose:

(As you can see, some core files were generated by valgrind.)
Below “find_file” function (from IdaPro):

You can easily see that we have malloc() here.
Next thing I decide to check was JLI_ParseManifest() function:

After checking those functions, we can see that JLI_ParseManifest() will iterate through each character in Manifest file. Correct me if I’m wrong but I think that find_file() is the place when SIGSEGV occurs. Manifest file is parsed here:

When we will set up “Windbg” (in IdaPro) to run Java with our sample.jar file (generated by afl), we will see, that crash occurs in similar region:

After this warning, Ida will jump to next location:

In text mode view, we can see more instructions:

Let’s see if in pseudocode (Tab/F5) we will find any hint:

We see the memcpy() function  with 3 arguments: v4, v3 and v5. Details about those variables we can find in the beginning of the pseudocode:

Now we know that v3 is the value from esi, v4 is the value from edi and v5 is the value from ecx. Next thing is generating and saving dump file. We will open it in Windbg later:

Now, open java.dmp file in Windbg and observe results:

We can see that SIGSEGV occurs when the program is using EDI and ESI registers. Let’s check what’s on that location: let’s use the “dc” command:

In case that you will ask what !exploitable will tell you about it, screen below:

Short summary: this sample file will crash Java on all mentioned systems.
If you think that this is exploitable… Well. Let me know what do you think about (comments or emails). Any ideas are welcome. ;)