--- [ News ] ---

Byakugan, a full-fledged logo recognition system

I uploaded my diploma thesis for my degree at the Computer Engineering and Informatics Department. It's a complete implementation of a logo recognition system, made possible by tapping into the power of OpenCV and using Android for the application component. It's written in Greek but there is complete code listing in the end of the document. It's called Byakugan and it will be pretty easy for anime lovers to get the reference!

-- ithilgore, 30 October 2012

Ncrack presentation video of AthCon2011

At last, here's the video of my presentation at AthCon2011 on Network Exploitation with Ncrack.

-- ithilgore, 6 April 2012

Ncrack presentation

Just letting people know, I uploaded the slides from my AthCon presentation on Network Exploitation with Ncrack. I will probably get my hands on the video material from the conference soon.

-- ithilgore, 18 January 2012

Google Summer of Code 2010 Wrap-up

Another Google Summer of Code has come to its end. I participated this year in the Nmap project working on Ncrack once again. I started Ncrack in last year's GSoC from scratch under the mentorship of Nmap's original author Fyodor and it already includes dozens of features that make it unique as a high-speed network authentication cracking tool.

I was very pleased to announce recently that its latest version includes support for cracking SMB as well as Microsoft's highly-complex Remote Desktop Protocol (RDP). Of course, Summer of Code was only the beginning and Ncrack has still a lot room for improvement. I plan to keep working on it in my spare time and rest assured that there are many surprises to watch unfold in the near future. Feel free to browse around read this summer's status reports to get an idea of what has been accomplished throughout this GSoC.

Stay tuned and also consider donating if you feel like it.

-- ithilgore, 20 September 2010

Abusing Network Protocols

In my presentation "Abusing Network Protocols" that I gave at athcon, I demonstrated a new stealthy port scanning attack that is made possible by abusing XMPP. The technique uses a "zombie" host (that can be anyone in your [most probably fake] friend/contact list) and some timing calculations in order to conduct a portscan through that proxy to any target. The IP address is never revealed to the scanned victim, the same way the famous idle/zombie scan, discovered by antirez, works. I just uploaded the whitepaper on Abusing Network Protocls and the relevant presentation slides on this site.

-- ithilgore, 9 June 2010

Athcon 2010

I recently gave a presentation on "Abusing Network Protocols" at athcon, a new security conference taking place in Athens, Greece. The presentation subjects ranged from BNF/general fuzzing, context-keyed payload encoding, SIP/VoIP exploitation to less technical ones like Mobile Privacy with Tor and CyberWar. A variety of security related subjects for a variety of audiences. I have been to various conferences these past few years but never got to comment on the experiences. This time, since this is also a conference in which I participated as a speaker, I will make an exception.

Athcon's presentation schedule went like this:

OWASP Top 10
An overview of more or less the vulnerability and security trends as documented by OWASP. Presentation was very low on technical details and was watchable by even non tech-savvy people.

Attacking VoIP
Sandro Gauci did some interesting work on finding ways to exploit SIP and VoIP, demonstrating his tool SIPvicious. He also mentioned several ways that the illegal part of the underground is leveraging SIP to gain tremendous amounts of money. I wonder how many vulnerable PBXs etc are out there.

Mobile privacy
Ever wanted to use Tor on your iPhone? If you are that paranoid (and probably you should be), then this talk might interest you. I expected more technical details though, to tell you the truth. By the way, don't forget that you never know who's behind a Tor exit node. Let me remind you that Moxie Marlinspike conducted some of his sslsniff/sslstrip tricks on such a host. People are lucky that he didn't abuse that information, but there are others who won't have second thoughts about it.

I am sure you have seen many talks on this topic, however this must have been the first time where the speaker almost urged people to go and browse a very well-known secret service's website and see what kind of jobs they are looking for.

BNF (Backus-Naur Form) based blackbox fuzzing
No heap exploitation this time by huku, but a at-first-seemingly obscure way of carrying out automated fuzzing. I am certain that his upcoming tool/framework on this will hold many surprises. I guess it might be "a hell of an easy thing to code a fuzzer" but doing this kind of detailed research sure isn't. Congratulations then for a hard work and a nice presentation (though with less text/slides next time) hk. Now where is that dyndns login page...

Context-Keyed Payload Encoding
Interesting ideas for evading even complex Intrusion Detection Systems. The bad thing with this is that once these techniques are known, it is only a matter of time until the modern IDSs just start looking for them. However, the vivid presentation by Glynos, surely stresses the fact that as long as there are people thinking out of the box out there, everything will be circumventable - from either side that is.

The DHCP Recession
A simple attack on DHCP mainly for the purpose of DoS. Nothing more, nothing less.

Alice Shares, Eve Reads
Has anyone wondered if the files they share on the cloud are really safe/private? This talk is all about demonstrating that by a high chance they aren't, as long as determined and patient attackers can try guessing or bruteforcing the not-so-random IDs of the automatically created filenames for these services.

Fuzzing - The past the present and the future
Second talk on fuzzing by Rodrigo Marcos. It would be nice to compare or even combine the research done by the two fuzzing researchers of the day.

Got database access? Own the network!
One of the most interesting talks of the day. Covering many aspects of intruding into a network, Bernardo Damele showed us that an attacker should have many different ideas, tools and techniques in his arsenal in order to subvert one or many systems. I really liked the part with the sys_* analysis.

I didn't cover every talk in this post, but the ones mentioned caught my attention the most (not implying that others didn't deserve or get it too). Overall, the conference was a good initiative for Greek standards but there is always room for improvement.

-- ithilgore, 8 June 2010

Accepting Donations

If you find Ncrack or any other of my work useful, consider making a donation to support further development and research. You can make a paypal donation through the "Donate" button in the site menu.

-- ithilgore, 20 February 2010

GSoC/Ncrack Presentation

I recently gave a talk at a local linux user group about my involvement with Google Summer of Code 2009 and some of the technical aspects of the project I undertook: Ncrack. The GSoC/Ncrack Presentation slides are a brief overview of the subjects that were discussed during the lecture.

I am also glad to say that after some (unrelated as it seemed) stressful debugging in Windows-land the --resume option was successfully ported there.

-- ithilgore, 3 Decemeber 2009

Quick Update

It's been only a little time since getting back to business after a long self-imposed break from tech-related things. The quest for learning is a never-ending journey, but 'life hacking' is a significantly more important and fascinating field than computers and deserves its own attention, lest we be driven insane (and yes there's too little time...).

I expect to have things running on schedule once again. I have partially shifted my interests now focusing more on pure Operating System internals and bypassing protections, and less on low-level networking stuff. However, this doesn't mean I will lose my connect(2)ion with Ncrack (for which btw I need and plan to do a lot of pending stuff) and the rest of the interesting things that kept me awake a lot of nights, meddling, tinkering, coding, messing up and getting frustrated, reevaluating ideas, exploiting and imagining...

I have also created a twitter account which you can follow for speedy updates. Initially, I was against this whole 'micro-blogging' thing, but eventually I decided that it has some advantages that are worth *not* overlooking.

-- ithilgore, 25 Novemeber 2009

GSoC end

It's been a while since Google Summer of Code has officially ended and I have been busy with various things (mostly non-tech). The GSoC programme was a success and Ncrack is soon going to be widely released in an improved ALPHA version. Just a couple more features that need to be added and the release will be a fact. In the meantime, I have already uploaded all of weekly Status Reports that describe Ncrack's progress during the Summer of Code.

-- ithilgore, 20 September 2009

Hacking the OpenSSH library for Ncrack

Hacking the OpenSSH library for Ncrack discusses the process of building a library based on OpenSSH code for Ncrack's SSH module. It analyzes authentication-related OpenSSH code as well as some pitfalls and challenges with SSH-bruteforcing.

-- ithilgore, 30 July 2009

Ncrack news

I have been spending a lot of time lately developing Ncrack, a high-speed network authentication cracking tool, for the Nmap project under this year's GSoC We are hoping to release a fairly robust and working codebase when this summer ends. The latest achievement is the introduction of the SSH module which is based on a custom-made library that is largely derived from the original OpenSSH code. The hardest part was probably the need to hack a large part of the OpenSSH functions in order to get them to work in collaboration with Nsock, the library that Ncrack uses to do all network/socket operations. OpenSSH has its own socket handlers and uses a lot of static/global variables to keep state, something which is prohibitive for the parallel connections that Ncrack utilizes. In addition, the opensshlib was tailored according to the specific needs of Ncrack, meaning that anything which was not directly-related to the authentication phase has been removed and the code kept at minimal levels to reduce complexity and increase maintanability. Now, some new ssh-related challenges came up as I was testing the experimental version of the new module.

-- ithilgore, 13 July 2009


Nkiller2 is the POC tool I made for my article Exploiting TCP and the Persist Timer Infiniteness which was published at the latest Phrack issue. It exploits an RFC-compliant TCP Persist Timer behaviour, perpetual to every Operating System out there to perform a pretty devastating DoS attack. It seems the whole thing has brought some attention to the internet security folks:

* Erratasec blog: A nice view on asynchronous network programming.
* Nkiller2 vs Cisco CSS: Unfortunately, I didn't have the chance to experiment with this Cisco load balancer and thus Nkiller2 can't handle its replies. Anyone care to make a patch or provide me with access to a Cisco CSS testbench?
* haproxy protection: Haproxy protection against Nkiller2. Has anyone tested this? It would be interesting to see how effective the protection really is.
* Snort rules: Snort signature created to detect possible Nkiller2 attack.
* Fyodor's reply: posted at nmap-dev mailing list.
* Dailydave: Dave aitel's reply to the article. Quoting:

    Is it just me or can pretty much every web site in the world get turned
    off now?
    I guess you could use iptables to drop the Window Size 0 packets? 

Well, it can cause some serious damage, that's for sure, but YMMV.

-- ithilgore, 13 July 2009

sock_raw update

After some time of inactivity, I decided to make some improvements on the site. I opened up a new section Nmap/Ncrack which contains documentation I have written about these two tools as well as this year's Google summer of code status reports on Ncrack. Previously, these belonged to a wiki I had uploaded but decided it wasn't worth the trouble and the insecurity it entailed (we all know how vulnerability-prone PHP code can be and I personally don't have the time to audit the code by myself). Expect this section to be updated as Ncrack is progressing. I also changed the site's design a little bit and improved the rss-feed generation script I had written, showing the whole entry content now.

-- ithilgore, 13 July 2009

Windows firewall TCP deviations

After I ported Ncrack to Windows and conducted some tests, I came across a really bizzare TCP behaviour, which completely violates RFC 793 rules. In summary, when the Windows default firewall is enabled and the peer we are connected to, sends a FIN to close the connection on his side then Windows acknowledges the FIN (as it should) and then immediately sends an RST to the peer completely killing the connection! This practically doesn't allow ourselves to send any additional data (which is perfectly legal to do, since we haven't closed the connection on our part) and also potentially disallows us from reading any last data that the peer had sent before closing the connection. The latter might happen if we haven't called read(2) before the peer's FIN arrives, since after Windows sends the RST any receive-buffers for the connection are nullified. There is an ongoing discussion about the issue at nmap-dev This illicit behaviour has caused a lot of frustration to others as well. I am starting to think about reporting this to Microsoft.

-- ithilgore, 27 June 2009

Exploiting TCP and the Persist Timer Infiniteness - Phrack #66

At last, the new phrack issue is out! A long time ago, I had promised an article on exploiting the TCP Persist Timer. You can now read all about it in phrack #66 here.

-- ithilgore, 13 June 2009


Plans have changed for this GSoC and I will be undertaking a more challenging project on Nmap. Fyodor proposed a new network authentication cracker, under the name Ncrack which will be written from scratch but based on Nsock - an optimized parallel sockets library used by NSE (Nmap Scripting Engine) as well as Nmap's service-scanner and parallel rDNS resolver. At this stage, an initial overall planning about Ncrack's architecture is being carried out. I have proposed a draft which can be found here.

-- ithilgore, 5 May 2009

IDS, UDP and DoS

I was taking a look at various papers on distributed intrusion detection systems to get ideas for my own and happened to study this one. One of the main design decisions one has to make, is on which transport protocol the agents are going to communicate with one another and with the central node which collects all the data. The authors of the paper suggested using UDP and multicasting. As far as multicasting is concerned, it is a fairly good practice since it gives many benefits without adding overly much to the complexity. And as we know, TCP can't be combined with multicasting. However using UDP can have really, really negative security implications, especially with DoS attacks. The authors suggest that in face of a DoS attack, TCP will probably fail to deliver any important data due to ACK loss. They state in particular:

    "Consider a LAN experiencing a DoS attack. If the LAN's intrusion detection
     system tried to communicate with the central node using TCP through the LAN's
     upstream link, the connection would probably fail to be established. Although
     the packets transmitted by the IDS would reach their destination, the ACK
     packets would likely be dropped."

However, if TCP loses some ACK packets, it has many chances that it will later be able to retransmit the packet successfully. TCP has a fairly robust congestion-avoidance algorithm (which varies among implementations) and a retransmission mechanism that is far more reliable than UDP can ever dream of acquiring. To implement a sufficiently reliable UDP delivery mechanism, one has to at least reinvent the wheel, and probably fail in the process of doing so, since TCP has been thoroughly tested over the years from this aspect.

A DoS attack can be easily carried through, with complete IP spoofing when UDP is used. Any authentication (for example using digital signatures) has to be done, after the datagram has been received in the process' receive socket buffer. So the attacker can pretty easily craft a packet, spoofed with an IP of an agent and flood the ids with bogus packets. If TCP was used, then at least IP spoofing would go as far as triggering the syn-cookies mechanism which is not as terrible nowadays. Using TCP will complement a firewall's filtering to thwart such an attack since any attempt to spoof the IP with that of an agent (suppose the firewall only allows communication through a strict IP ACL that includes only the agent's IP addresses), will result in at most filling the SYN queue, partially completing the 2way TCP handshake and thus at worst triggering the syn-cookie mechanism as we said before. No such thing will happen with UDP. The specially crafted packets will get through the firewall's ACL and will be delivered in the socket receive buffer flooding it and thus disallowing any additional communication, unless other measures are taken.

-- ithilgore, 22 April 2009

Nmap GSoC

I was accepted in Google Summer of Code and will be working on Nmap improving Ncat, introducing raw socket support for IPv6 and creating an application abusing engine! I am pretty excited about working officially on one of my favourite projects, the best network exploration tool out there.

-- ithilgore, 20 April 2009

Asm raw sockets

I decided to post some simple old code that demonstrates that raw sockets can be easily programmed in assembly, even if that sounds a bit crazy. Or maybe not. Shellcode that uses raw sockets is nothing new, after all. The code is pretty well commented, so I will provide no additional guide whatsoever. It's really small anyway.

  .section .data
  .equ AF_INET, 2
  .equ SOCK_RAW, 3
  .equ IPPROTO_RAW, 255
  .asciz  "" # dest ip daddress
  .asciz  "" # source ip daddress
  .ascii  "RAW SOCKETS IN ASM!"
  .section .bss
  .lcomm sock, 4
  .lcomm saddr, 16
  .lcomm daddr, 16
  .lcomm sockargs, 12 # 3 ints for socket (int domain, int type, int protocol)
  .lcomm sendargs, 24 # 6 ints for sendto()
  .lcomm iph, 40      # ip header + data
  .section .text
  .globl main
  nop                         # debugging purposes
  movl $sockargs, %edi        # point edi to sockargs
  movl $AF_INET, (%edi)       # family = AF_INET
  movl $SOCK_RAW, 4(%edi)     # type = SOCK_RAW
  movl $IPPROTO_RAW, 8(%edi)  # protocol = 255
  movl $102, %eax   # 102 = sys_socketcall, a demultiplexor for socket syscalls
  movl $1, %ebx     # this is the call argument - SYS_SOCKET is 1 
  movl %edi, %ecx   # a pointer to the arguments of socket()
  int $0x80         # socket(2) through sys_socketcall
  movl %eax, sock   # save socket descriptor
  movl $daddr, %edi # point edi to our sockdaddr_in daddr
  movl $2, (%edi)   # daddr.sin_daddr = AF_INET
  push $8000        # htons() for port-apparently htons doesn't mess up with %edi
  call htons
  movl %eax, 2(%edi) # daddr.sin_port = 8000
  movl $0, 8(%edi)   # daddr.sin_zero = 0  - we might not need this 
  movl $0, 12(%edi)  # daddr.sin_zero = 0
  # call inet_pton -daddr
  addl $4, %edi   # must give address of daddr.sin_addr 
  push %edi       # argument: void *dst
  push $IPd       # argument: const char *src
  push $AF_INET   # argument: int family
  call inet_pton
  # call inet_pton -saddr
  movl $saddr, %edi
  movl $2, (%edi)   # saddr.sin_daddr = AF_INET
  addl $4, %edi     # must give address of saddr.sin_addr 
  push %edi         # argument: void *dst
  push $IPs         # argument: const char *src
  push $AF_INET     # argument: int family
  call inet_pton
  # create ip header and data
  movl $iph, %ebx
  movw $0x0045, (%ebx)       # version, header length, TOS  (length by kernel)
  movl $0x0000ffff, 4(%ebx)  # identification number, frag offset = 0
  movb $0x40, 8(%ebx)        # TTL
  movb $IPPROTO_RAW, 9(%ebx) # Protocol  (checksum will be filled by kernel)
  movl $saddr, %eax
  addl $4, %eax
  movl (%eax), %eax
  movl %eax, 12(%ebx)        # source ip address
  movl $daddr, %eax
  addl $4, %eax
  movl (%eax), %eax
  movl %eax, 16(%ebx)        # destination ip address
  movl $DATA, %esi           # data
  movl $iph+20, %edi
  movl $19, %ecx
  rep movsb 
  # sendto() through sys_socketcall
  movl $sockargs, %edi
  movl sock, %eax
  movl %eax, (%edi)   # arg1: int sockfd
  movl $iph, %eax
  movl %eax, 4(%edi)  # arg2: const void *buf
  movl $50, %eax
  movl %eax, 8(%edi)  # arg3: size_t len
  movl $0, %eax
  movl %eax, 12(%edi) # arg4: int flags = 0
  movl $daddr, %eax
  movl %eax, 16(%edi) # arg5: const struct sockaddr *servaddr
  movl $16, %eax
  movl %eax, 20(%edi) # arg6: socklen_t addrlen
  movl $102, %eax
  movl $11, %ebx      # SYS_SENDTO = 11
  movl %edi, %ecx     # arguments to sendto(2)
  int $0x80
  movl $1, %eax
  movl $0, %ebx
  int $0x80
  $ gcc raw.s -o raw
  # ./raw
  # tcpdump -i lo -n -X 
  16:57:48.495821 IP >  ip-proto-255 30
          0x0000:  4500 0032 ffff 0000 40ff 7bcb 7f00 0001  E..2....@.{.....
          0x0010:  7f00 0001 5241 5720 534f 434b 4554 5320  ....RAW.SOCKETS.
          0x0020:  494e 2041 534d 2100 0000 0000 0000 0000  IN.ASM!.........
          0x0030:  0000                                     ..

-- ithilgore, 19 April 2009

Socket Internals

I will begin writing a series of posts concerning the internals of the socket mechanism based on a 2.6.* Linux kernel. I was recently refreshing my memory on some parts of Unix Network Programming vol 1 by Unix guru Stevens and thought it would be fruitful to share some thoughts and tinkering about the often misunderstood socket world.

Value-result magic

I will begin by analysing a simple example of the length value-result argument as seen in many socket-related system calls like recvfrom(2) and accept(2). Anyone who has some basic experience with network programming should already know that these routines require a pointer of type socklen_t argument as well as a pointer to a sockaddr struct (usually cast to a protocol-family-dependent structure like sockaddr_in - blame pre-ANSI C). Initially, the socklen_t argument is set by the program to a value that denotes the actual length of the sockaddr struct that the kernel will fill in with relevant information. However, the userspace application's say on the type and thus size of sockaddr struct used may, under really obscure circumstances, be different than the one that the kernel decides is suitable. For example, suppose you provided a unix domain sockaddr_un struct for a UDP socket. Then, the kernel would write far less bytes (16) at the userspace struct and will update the length variable to denote the real size of the sockaddr as it should be. That is why these kind of variables are called value-result. They act as both an initial value as well as a returning value.

Let's see an example from recvfrom(2):

   *  Receive a frame from the socket and optionally record the address of the
   *  sender. We verify the buffers are writable and if needed move the
   *  sender address from kernel to user space.
  asmlinkage long sys_recvfrom(int fd, void __user *ubuf, size_t size,
             unsigned flags, struct sockaddr __user *addr,
             int __user *addr_len)
    struct socket *sock;
    struct iovec iov;
    struct msghdr msg;
    char address[MAX_SOCK_ADDR];
    int err, err2;
    int fput_needed;
    sock = sockfd_lookup_light(fd, &err, &fput_needed);
    if (!sock)
      goto out;
    msg.msg_control = NULL;
    msg.msg_controllen = 0;
    msg.msg_iovlen = 1;
    msg.msg_iov = &iov;
    iov.iov_len = size;
    iov.iov_base = ubuf;
    msg.msg_name = address;
    msg.msg_namelen = MAX_SOCK_ADDR;
    if (sock->file->f_flags & O_NONBLOCK)
        flags |= MSG_DONTWAIT;
    err = sock_recvmsg(sock, &msg, size, flags);
    if (err >= 0 && addr != NULL) {
        err2 = move_addr_to_user(address, msg.msg_namelen, addr, addr_len);
        if (err2 < 0)
            err = err2;
    fput_light(sock->file, fput_needed);
    return err;

The arguments correspond to the ones shown in recv(2):

   ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags,
   struct sockaddr *src_addr, socklen_t *addrlen); 

The first task that sys_recvfrom does is find the relevant socket given the file descriptor. Thus it calls sockfd_lookup_light() which is shown below:

  static struct socket *sockfd_lookup_light(int fd, int *err, int *fput_needed)
    struct file *file;
    struct socket *sock;
    *err = -EBADF;
    file = fget_light(fd, fput_needed);
    if (file) {
      sock = sock_from_file(file, err);
      if (sock)
        return sock;
      fput_light(file, *fput_needed);
    return NULL;

As we can see, there are two calls inside it: fget_light() which returns a file instance by searching in the descriptor table and then sock_from_file() which references the file structure which has been initialiazed by sock_map_fd() during the socket creation-allocation phase, to ultimately return the socket structure that we need.

  static struct socket *sock_from_file(struct file *file, int *err)
    if (file->f_op == &socket_file_ops)
      return file->private_data;  /* set in sock_map_fd */
    *err = -ENOTSOCK;
    return NULL;

After getting the socket struct, sys_recvfrom() proceeds with filling in the msghdr and iovec structs which are used for message and data passing inside the kernel. Then sock_recvmsg() is called and is responsible to prepare for passing control to the transport-layer specific handler (e.g the UDP specific recvmsg - udp_recvmsg() from net/ipv4/udp.c):

      err = sock_recvmsg(sock, &msg, size, flags);

We finally reach the point that interests us most.

      err2 = move_addr_to_user(address, msg.msg_namelen, addr, addr_len);

This is the routine that will copy the sockaddr struct that has already been filled with relevant information from the transport-layer specific recvmsg() to the userspace application. The address of 'address' had previously been passed to msg.msg_name and msg.msg_namelen was assigned a MAX_SOCK_ADDR length. MAX_SOCK_ADDR is defined so large as to be able to hold the lengthiest struct (unix domain sockaddr) available in the system:

  #define MAX_SOCK_ADDR 128   /* 108 for Unix domain -
               16 for IP, 16 for IPX,
               24 for IPv6,
               about 80 for AX.25
               must be at least one bigger than
               the AF_UNIX size (see net/unix/af_unix.c

Let's uncover the internals of move_addr_to_user now:

   *  move_addr_to_user - copy an address to user space
   *  @kaddr: kernel space address
   *  @klen: length of address in kernel
   *  @uaddr: user space address
   *  @ulen: pointer to user length field
   *  The value pointed to by ulen on entry is the buffer length available.
   *  This is overwritten with the buffer space used. -EINVAL is returned
   *  if an overlong buffer is specified or a negative buffer size. -EFAULT
   *  is returned if either the buffer or the length field are not
   *  accessible.
   *  After copying the data up to the limit the user specifies, the true
   *  length of the data is written over the length limit the user
   *  specified. Zero is returned for a success.
  int move_addr_to_user(void *kaddr, int klen, void __user *uaddr,
            int __user *ulen)
    int err;
    int len;
    err = get_user(len, ulen);
    if (err)
      return err;
    if (len > klen)
      len = klen;
    if (len < 0 || len > MAX_SOCK_ADDR)
      return -EINVAL;
    if (len) {
      if (audit_sockaddr(klen, kaddr))
        return -ENOMEM;
      if (copy_to_user(uaddr, kaddr, len))
        return -EFAULT;
     *      "fromlen shall refer to the value before truncation.."
     *                      1003.1g
    return __put_user(klen, ulen);

The author's comments are pretty informative though studying the code always sheds more light. get_user() is nothing else than a mini-userspace-to-kernel copier for small-sized variables. It writes the userspace ulen variable into the local variable len, and later uses that to make all the comparisons - obviously for performance reasons. We can see the sanitization checks that follow: len gets truncated to a maximum of klen which is the actual number of bytes that the kernel previously wrote to the sockaddr struct. Additionally, if len is negative or larger than MAX_SOCK_ADDR, then an error of type EINVAL is returned. The all-around-classic copy_to_user() routine copies the sockaddr struct to the userspace and __put_user(), which is the opposite of get_user(), copies the klen into ulen. We can deduce from the above the following:

- If the userspace application passes a socklen_t addrlen argument that is more than the number of bytes actually written by the kernel, then addrlen will be overwritten with the new size.

- If the userspace application passes a socklen_t addrlen argument that is less than the number of bytes actually written by the kernel in the kernelspace struct, then addrlen will be overwritten with the new size but only the first addrlen userspace bytes will be filled in by the kernel.

That is expected behaviour, as we can see from the recv(2) manpage:

        "The argument addrlen is a value-result  argument,
         which  the  caller should initialize before the call to the size of the
         buffer associated with src_addr, and modified on return to indicate the
         actual  size  of the source address.  The returned address is truncated
         if the buffer provided is too small; in this case, addrlen will  return
         a value greater than was supplied to the call." 

Finally, let's see a simple example from UNP. It is a simple protocol-independent function that echoes the message that it gets to the one who initially sent it. Why did Stevens use the local variable len instead of just passing the clilen argument directly? It's not for performance reasons since both are variables that can be accessed locally through the stack. Only clilen may be some bytes above or below, depending on the underlying architecture, in memory. The real reason is defensive programming. Recvfrom() could potentially change clilen any time. If that happened, then the next time it was called, since clilen is a value-result variable, the next call would be 'infected' by the previous variable of clilen. To avoid that, a local variable len is assigned clilen each time in the beginning of the loop.

  #include     "unp.h"
  dg_echo(int sockfd, SA *pcliaddr, socklen_t clilen)
      int     n;
      socklen_t len;
      char    mesg[MAXLINE];
      for ( ; ; ) {
          len = clilen;
          n = Recvfrom(sockfd, mesg, MAXLINE, 0, pcliaddr, &len);
          Sendto(sockfd, mesg, n, 0, pcliaddr, len);

The question is: is there any case that recvfrom() could actually return different values for len each time it was called? Remember that this function is meant to be protocol-agnostic. Inspecting the TCP and UDP code will show that no such case exists. However, there may exist other transport-layer protocols that have strange behaviours. In addition, there are variable-length socket address structures like Unix domain (sockaddr_un) that can return a length less than the maximum of the structure. Thinking so far ahead to include any possible future end-case is truly the mark of a guru like Stevens.

-- ithilgore, 19 April 2009

Digging through Snort

I have been studying the snort source code to get some ideas for my upcoming distributed intrusion detection system and I will have to admit that it is pretty easily readable. I have spotted some points though that should have no place in a contemporary codebase.

  void *InterfaceThread(void *arg)
    int pcap_ret;
    struct timezone tz;
    int pkts_to_read = pv.pkt_cnt;

    bzero((char *) &ptz, sizeof(tz));

We all know that bzero is deprecated though we keep seeing it very frequently. What I didn't expect was that Snort in non-inline mode uses a single process to do the whole work of getting the packets through libpcap, parse them, decode them and later analyse them producing any subsequent alerts. I expected it to use more than one thread for all these tasks but it seems that that would make things more complicated than needed without any additional real gain.

By the way I added the rss feeds to the site.

-- ithilgore, 15 April 2009


I am still alive, though the site - I'll have to admit - has been unupdated for a while. Though there are many reasons about it, I will not go into details and excuses. I have been lately working on a distributed IDS as well as the extraction of the plaintext private ssh key from /dev/mem. Have been digging through a lot of openssl code on that and have been frustrated with all the abstraction layers there. I am very close to the solution though. I am thinking about making some major design changes to the site too. Maybe also add some rss feeds, since many asked for them. More later.

-- ithilgore, 14 April 2009

The TCP/IP Drinking Game

A new iteration of the TCP/IP Drinking Game has officially started! The idea behind it is to delve into the network abyss and find obscure, unheard of, or otherwise in general unknown details of networking protocols and internet lore, transform them into a question-answer scheme and have fun. Feel free to make your own contributions to the list by sending an email and/or provide any other kind of feedback. Finally, don't forget to sock_valbool_flag(sk, SOCK_BROADCAST, 1); it.

-- ithilgore, 10 February 2009

Backdooring OpenSSH Server

I recently made a quick implementation of a POC sshd backdoor, based on the the idea of sending a fake authentication password that gets decoded with a predefined 2-way algorithm revealing the real passphrase only on the server side, in case you know someone is mitm-ing you and still need to initiate a new ssh session. Of course, it doesn't even compare with using public key authentication, but nevertheless it still remains an original idea.

-- ithilgore, 7 February 2009

Paranoid Filtering

I finished writing about the exploitation of the TCP Persist Timer and coding of Nkiller2 but won't release it just yet, since it will hopefully be first published elsewhere (at a known underground ezine).

Filtering access on ports that are meant for administrative purposes only (e.g ssh), has always been a much debated issue. Techniques ranging from port-knocking to complex IP filtering schemes are one way, but a really generic way to accomplish slightly more protection is to filter based on the source port. It is assumed that you have also moved your service listening on a port other than the default. Combine the above and a prospective attacker will have to send at worst a total of 2^32 [2^16(dst)*2^16(src)] packets to find your hidden service. The only hindrance will be having to always use the designated source port for the client. To do this, without resorting to recompiling the client and hardcoding the used port, you can use a tool like socat that lets you perform port-forwarding in addition to allowing you to choose the source port. Demonstration:

  # iptables -A INPUT -p TCP -s 0/0 --dport 3333 --sport 2222 -j ACCEPT
  $ socat TCP4-LISTEN:4444 TCP:<ip>:3333,sourceport=2222 &
  ssh ithilgore@localhost -p4444

Mark the above as an alias and you are done. To use scp you will need to allow an additional source port. Say 7777. Then you would use a function like this (function and not an alias this time, since we will need to use the bash argument variable $@):

  pscp () { a=$RANDOM; socat TCP4-LISTEN:$a TCP:<ip>:3333,sourceport=7777
  & scp -P$a "$@" ithilgore@localhost:~; } 

-- ithilgore, 1 February 2009

TCP vulnerabilities / New domain

Many things have happened since the last time I updated the site. Lately, I have been experimenting with/reading about TCP vulnerabilities. From the old blind RST bug to congestion collapses with misbehaving receivers. The most remarkable thing about the last attacks, or at least some of them, is that the RFC 2581 (TCP Congestion Control) authors were actually aware of their existence.Specifically, Section 5. Security Considerations states:

"This document requires a TCP to diminish its sending rate in the presence of retransmission timeouts and the arrival of duplicate acknowledgments. An attacker can therefore impair the performance of a TCP connection by either causing data packets or their acknowledgments to be lost, or by forging excessive duplicate acknowledgments."

Yes, these attacks (and more) exist and yes they work.

Upcoming is an update on Nkiller which exploits the TCP persist timer. Details will be included later.

Some other news: sock-raw.org is the new domain for the site. sock-raw.homeunix.org will still continue to work but I don't know for how long I will keep it.

-- ithilgore, 15 January 2009

Nmap out-of-bounds mem access bug

I've been busy lately, dealing with many tenuous projects, but managed to indulge myself by auditing some of the Nmap code. It was part of the inspection I would do anyway for the upcoming paper. The idea came while revisiting some chapters from the venerable security bible "The art of software security assessment". The chapter on networks, mentioned a list of basic rules that every low-level network tool should follow as far as packet length validation is concerned. So, I applied this set of checks upon the latest Nmap release validation routines. The result was this. The funniest part about the whole thing was the fact that I needed to change the Linux kernel source code, so that I could make packets of arbitrary length (packets that had an overall real length that was less than the one mentioned in the ip->ip_len field in the IP header).

-- ithilgore, 25 November 2008

Nkiller - a TCP stressing tool

The "arsenal" of networking tools now comprises of a new program which I decided to call Nkiller. It is based on an idea first posted at bugtraq in 2000 but still works until today, more or less. As far as I have tried it in my own servers, I had 100% success (though some option optimization was needed at times e.g more aggressive timing). The targets included web servers running on Windows Server 2003, Linux (2.6.22) and OpenBSD... The good thing is that it combines both the exploitation of a mechanism that is perpetual on every OS, and the idea of reverse syn cookies first introduced by Dan Kaminsky's scanrand, which adds to the overall speed. I have to warn you: I will not be held responsible for any kind of abuse of this tool. It is to be used on servers you own yourself to test their potential ability to withstand such an attack.

-- ithilgore, 21 October 2008

Locating Stateless Firewalls

I finished writing another paper, this time concerning firewalls: how to locate and possibly defeat stateless ones. The paper uses more or less old methods (which *still* work however) to identify the nature of a stateless firewall and further on bypass it exploiting the fact that RFC 793 is ambiguous in one part about tcp flags, thus allowing a margin for misconfigurations. The article can be found here.

After I sharpen my low-level networking skills a bit more, I am planning to write a paper on "analyzing the Nmap source code". This will probably be a formidable task, considering the enormousness of the Nmap codebase. It will probably resemble SOCK_RAW Demystified in its extent and complexity.

Since firewalls was one of my research interests the last days, I happened to come across some guy on nmap-dev asking about how he could identify which of four firewalls along his way, was blocking his requests. The brief theoretical explanation of the technique that could be used in such a case is explained here.

Now that I give it a second thought, there is actually an out-of-the-box tool that serves the purpose of firewall reconnaissance: It is the venerable Firewalk by Mike Schiffman, the well-known TCP/IP guru and hacker.

I must not forget to mention this good reading that comments on the recent TCP DoS attack discovered by Robert Lee (main developer of Unicornscan) and his team at Outpost24.

-- ithilgore, 6 October 2008

Port knocking module & nmap payload patch

I 've added some new material to the site:

1) pknf - pknf is a loadable kernel module for linux, which implements a port knocking mechanism using netfilter hooks. Nf hooks was a choice over other methods since, although lower level and thus less portable, it is a stealthier and perhaps more rootkit-friendly way.

2) Nmap payload patch - this patch intoduces a new option for the latest version of Nmap (4.68 as of now), which lets you define your own payload for Nmap's probes. Until now, you could only insert random data by defining the --data-length option. I wrote it, after some user on nmap-dev asked for such functionality. Of course, as I noted there and as Michael Pattrick later mentioned here, payload handling is something NSE is more suitable for. Nevertheless, it provides a nifty solution for someone who needs a quick and protocol-agnostic way to manipulate extra payloads, since it uses the existing build_<protocol>_raw (where <protocol> = tcp,udp,icmp etc) functions defined in tcpip.cc of Nmap source code. You can find the patch here.

There were some discussions lately about the daunting task of scanning the whole internet. Fyodor presented at Black Hat and Defcon 2008 some interesting results based on his own findings from scanning most part of the internet range - Another thought-provoking article comes from thc - Port Scanning the Internet.

-- ithilgore, 25 August 2008

Hacking Bash History

After quite a long time of absence from updating the site, I now included in the papers section a new article I wrote about subverting the bash_history mechanism when it is vainly used as a user monitoring facility. I analyse both the strictest defensive measures that can be taken to supposedly secure it and more than enough counter-attacks to override it. In the end, a way to interface bash with syslog by hacking its source code is examined. You can find the text here.

-- ithilgore, 12 July 2008

SOCK_RAW Demystified

The site has just opened. You might want to take a look at my new paper SOCK_RAW Demystified.

There is also some of my old work Coding a Syn Scanner along with some nifty new (and old) projects such as TAP - the Tcpdump Analysing Parser.

I will usually post stuff of lesser-scale in the networking/security section.

-- ithilgore, May 2008