Altentee » Performance & Test Automation Experts » security

Improved SPNEGO or Kerberos support with LoadRunner

Tim Koopmans — Fri, 17 Apr 2009 05:12:29 +0000

Previously I identified a way in which to test SPNEGO or Kerberos authentication with LoadRunner. However this implementation was buggy in the sense that if you ran your load tests under reasonable load with the WinInet replay engine (instead of sockets) you were likely to encounter the following error:

Error -27492: "HttpSendRequest" failed, Windows error code=12057 (certificate revoked) and retry limit (0) exceeded for URL=" https://someplacesecure.com.au/secure.html", Snapshot Info [MSH 1 2]

This error occurs when using WinInet replay instead of sockets with Integrated Authentication enabled in run-time settings. The purpose of this was to allow vusers to use SSO with SPNEGO authentication in an IBM WebSEAL environment.

After spending some time with the mystical HP level 3 support, they identified an undocumented flag which helps out significantly in this. So, instead of using the WinInet replay engine (which is not encouraged by HP) you should do something similar to the following.

vuser_init()
{
 
	// Preferred run-time settings
	// Browser -> Browser Emulation
       // [ ] Simulate a new user on each iteration
       // Preferences -> Options
       // Enable Integration Authentication [Yes]
 
	web_set_sockets_option("INITIAL_BASIC_AUTH","1");
 
	web_set_user("DOMAIN.LOCAL\\username",
		"password",
		"someplacesecure.com.au:443");
 
	web_url("myportal",
		"URL=https://someplacesecure.com.au/wps",
		"Resource=0",
		"Referer=",
		"Mode=HTML",
		LAST);
 
	return 0;
}

The magic is in the web_set_sockets_option("INITIAL_BASIC_AUTH","1") flag. Set that and you can then use LoadRunner in Sockets mode which as it turns out, is much more stable.

Enjoy.

Performance Testing SPNEGO or Kerberos with LoadRunner

Tim Koopmans — Mon, 27 Oct 2008 08:15:39 +0000

Alas, it can’t be done in JMeter. So this is how it works in LoadRunner …
This challenge came up recently and we were able to figure out how to test SPNEGO or Kerberos using Integrated Windows Authentication with LoadRunner.

To test this I built a VM with Win2K3, an AD domain and IIS6. To enforce kerberos only authentication I modified IIS as per the following:

I didn’t have WebSEAL (which is what I was ultimately trying to simulate) but I believe this is reasonably close, to quote:

Integrated Windows authentication uses Kerberos v5 authentication and NTLM authentication. Kerberos is an industry-standard authentication protocol that is used to verify user or host identity. If Active Directory is installed on a domain controller running Windows 2000 Server or Windows Server 2003, and the client browser supports the Kerberos v5 authentication protocol, Kerberos v5 authentication is used; otherwise, NTLM authentication is used.

So to log on to my test page I needed to provide domain credentials in IE. I also made sure my client IE enforces IWA as per the following:

If I don’t provide my domain credentials (in this case: smallbusiness\fred) then I get knocked back with a 401 as expected.

On generation of my LR script the first response is a 401.2. It then does a second request with the authorization header i.e.
Authorization: Negotiate TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFAs4OAAAADw==

The response header to this tells me to authenticate i.e.
WWW-Authenticate: Negotiate TlRMTVNTUAACAAAAGgAaADgAAAAFgomir1xcxf5zo2MAAAAAAAAAAOIA4gBSAAAABQLODgAAAA9TAE0AQQBMAEwAQgBVAFMASQBOAEUAUwBTAAIAGgBTAE0AQQBMAEwAQgBVAFMASQBOAEUAUwBTAAEAHgBLAE8ATwBQAFMALQA5ADYAWABZADIAVwBEAFUANgAEACYAcwBtAGEAbABsAGIAdQBzAGkAbgBlAHMAcwAuAGwAbwBjAGEAbAADAEYAawBvAG8AcABzAC0AOQA2AHgAeQAyAHcAZAB1ADYALgBzAG0AYQBsAGwAYgB1AHMAaQBuAGUAcwBzAC4AbABvAGMAYQBsAAUAJgBzAG0AYQBsAGwAYgB1AHMAaQBuAGUAcwBzAC4AbABvAGMAYQBsAAAAAAA=

The next request authorizes presumably with the correct token i.e.
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAIgAAAAYABgAoAAAABoAGgBIAAAACAAIAGIAAAAeAB4AagAAAAAAAAC4AAAABYKIogUCzg4AAAAPcwBtAGEAbABsAGIAdQBzAGkAbgBlAHMAcwBmAHIAZQBkAEsATwBPAFAAUwAtADkANgBYAFkAMgBXAEQAVQA2AB15bTxE3i63AAAAAAAAAAAAAAAAAAAAALQ6IC82wYIBXpniDchRG9zSW8/bC4891w==

From which the response is gravy, and my homepage loads.
So the recording process looks like it went through the necessary authentication steps.

Now in my LR script Action() I can set the domain credentials dynamically with web_set_user (hence emulate multiple users) i.e.
web_set_user("smallbusiness\\fred","********", "smallbusiness.local:80");

Then follow with a web_url request to the server i.e.

	web_url("smallbusiness.local",
		"URL=http://smallbusiness.local/",
		"Resource=0",
		"RecContentType=text/html",
		"Referer=",
		"Snapshot=t1.inf",
		"Mode=HTML",
		LAST);

Play that back and it fails. (Assuming WebSEAL will reject NTLM which in this case my test rig won’t, but I can make that assumption…)

Now change a couple of runtime settings:
Internet Protocol->Preferences->Options->Authentication->Enable Integrated Authentication

This makes sure that when the server asks for authentication via the first 401.2/1, that SPNEGO/Negotiate/Kerberos is tried *first* before any other protocol (like NTLM)

You also need to change:
Internet Protocol->Preferences->Advanced->WinInet [checked]:

This instructs VuGen to use the WinInet replay engine instead of the standard Sockets replay. VuGen has two HTTP replay engines: Sockets-based (default) or WinInet based. The WinInet is the engine used by Internet Explorer and it supports all of the features incorporated into the IE browser. I think this *better* emulates the IE client settings for IWA …

And re-run the script. I now get past the authentication using Kerberos and successfully load my home page… This can be repeated for WebSEAL provided you first do a web_set_user (so it knows what domain credentials to use) which effectively lets you run the test with multiple users… Great for testing those WebSEAL/SPNEGO/Kerberos single sign on solutions…

SSH and SCP over alternate ports

Tim Koopmans — Sat, 05 May 2007 12:05:59 +0000

For an internet facing SSH server, it is probably common practice to have sshd listening on a non-standard port. Coupled with key pair authentication, this reduces the profile you present to simple brute force attacks.

Connecting to a SSH server on a non standard port is relatively simple:
ssh -p username@servername.com

You may however need to copy files from the SSH server on an alternate port. Easy:
scp -P username@servername.com:/path/to/remote/file ~/home/path/to/local/file

But what happens if you’re using a proprietary client other than scp from the console that won’t support non standard ports?

The simplest way to do this I found is with port forwarding.

First, and you will need to be root to do this, forward the priveleged port 22 on your local machine to the remote port on the target:
sudo ssh -p -L 22:127.0.0.1: username@servername.com

Then after that your client can just talk to localhost and it will be bound to the forwarded port on the remote host:
scp username@127.0.0.1:/path/to/remote/file ~/home/path/to/local/file

Now your proprietary apps can talk merrily away. By the way, this is an extremely good method for running Microsoft RDP sessions over a secure SSH tunnel:
ssh -p -L 3389:127.0.01:3389 username@servername.com

Then just use remote desktop but point it to local host:
mstsc /v:127.0.0.1

Faking it! (UDP packets that is…)

Tim Koopmans — Wed, 02 May 2007 22:51:51 +0000

An associate of mine recently wanted a load script that could simulate thousands of UDP packets carrying a custom payload coming from different IP addresses. They were implementing a customised RFID solution that needed to simulate load from a lot of sources (think active RFID tags).

There are many different ways you can accomplish this, solutions like LoadRunner will offer the ability to spoof source IP addresses, but in this case the client couldn’t afford hefty licensing fees. So getting back to basics, I launched the *flood* from a cygwin shell running ruby.

The code looked a little like this…

UDP Faker.rb
def ipchecksum(data) checksum = data.unpack("n*").inject(0) { |s, x| s + x } ((checksum >> 16) + (checksum & 0xffff)) ^ 0xffff end


require 'socket'
class UDP_Faker
    @@id = 1234 - 1
    def initialize

        @s = Socket.new(Socket::PF_INET, Socket::SOCK_RAW, Socket::IPPROTO_RAW)

        @s.setsockopt(Socket::IPPROTO_IP, Socket::IP_HDRINCL, 1)

    end
    def send(src, sport, dst, dport, payload = '')

        dst_numeric = dst.split(/\./).map { |x| x.to_i }

        to = [ Socket::AF_INET,

            dport, dst_numeric, '' ].flatten.pack('snCCCCa8')

        packet = make_ip_header([

            [ '01000101', 'B8' ],                # version, hlen

            [ 0, 'C' ],                          # tos

            [ 28 + payload.size, 'n' ],          # total len

            [ @@id += 1, 'n' ],                  # id

            [ 0, 'n' ],                          # flags, offset

            [ 64, 'C' ],                         # ttl

            [ 17, 'C' ],                         # protocol

            [ 0, 'n' ],                          # checksum

            [ ip2long(src), 'N' ],               # source

            [ ip2long(dst), 'N' ],               # destination

        ])

        packet << make_udp_header([

            [ sport, 'n'],                        # source port

            [ dport, 'n' ],                       # destination port

            [ 8 + payload.size, 'n' ],            # len

            [ 0, 'n' ]                            # checksum (mandatory)

        ])

        packet << payload

        @s.send(packet, 0, to)

    end
    private
    def ip2long(ip)

        long = 0

        ip.split(/\./).reverse.each_with_index do |x, i|

            long += x.to_i << (i * 8  )

        end

        long

    end
    def ipchecksum(data)

        checksum = data.unpack("n*").inject(0) { |s, x| s + x }

        ((checksum >> 16) + (checksum & 0xffff)) ^ 0xffff

    end
    def make_ip_header(parts)

        template = ''

        data = []

        parts.each do |part|

            data += part[0..-2]

            template << part[-1]

        end

        data_str = data.pack(template)

        checksum = ipchecksum(data_str)

        data[-3] = checksum

        data.pack(template)

    end
    def make_udp_header(parts)

        template = ''

        data = []

        parts.each do |part|

            data += part[0..-2]

            template << part[-1]

        end

        data.pack(template)

    end
end

testRun = UDP_Faker.new loop do # Source IP Port Destination IP Port Payload testRun.send('203.64.36.24', 2069, '124.191.161.6', 81, 'Blob: here comes the data ...') end # TODO: Loop through a range of source IP addy's. # Return response from server. Use correctly formatted blob.

In a similar vein, but long since shutdown, the guys at Hackers Choice provided some excellent C code for flooding TCP connections, which I also found useful in this project in order to conduct some stress to break testing. Understandably, some people might misuse this script, but for internal uses, I found it extremely useful to flood the TCP/IP stack. You can dowload the code here: flood_connect.c

It's usage is along the lines of this:
Options: -S use SSL after TCP connect (not usuable with -u, sets port=443) -u use UDP protocol (default: TCP) (not usable with -c) -p port port to connect to (default: %d) -f forks number of forks to additionally spawn (default: 0) -i file data to send to the port (default: none) -n connects maximum number of connects (default: unlimited) -N delay delay between connects in ms (default: 0) -c close after connect (and sending data, if used with -i) use twice to shutdown SSL sessions hard (-S -c -c) -C delay delay before closing the port (for use with -c) (default: 0) -d dump data read from server -D delay delay before trying to read+dump data from server (default: 0) -e stop when no more connects possible (default: retry forever) -k no keep-alive after finnishing with connects, terminate! -v verbose mode TARGET target to flood attack (ip or dns)