|
2019 highlights
2019 has been one of the toughest years for me, but it ended with the completion of a number of significant milestones:
* I finally got my US green card, allowing me to be a permanent resident and acquiring a lot more flexibility with work, eliminating stress associated with the temporariness of the H1B visa and finally being able make longer-term plans and more impactful life decisions.
* I led the authorship of the upcoming "Practical IoT Hacking" book, to be published by No Starch Press. This was one of the most time-consuming and stressful projects I have ever undertaken. Writing a book requires an immense commitment of time and dedication, especially with it being a side project on top of a full-time, demanding job as a principal security engineer at the Mayo Clinic. The book is expected to be published hopefully around summer.
* I started a remote, part-time PhD on information security (currently focused on IoT research). The reasoning for this was that since I had already been doing research on network security and other fields in my free time, I might as well combine it with something more official that will also provide me with the unique perspective of the academic world.
* I presented at many notable security conferences, including DEF CON, GrrCon, OWASP Latam, LayerOne.
* I organized and led the design of the DEF CON Biohacking Village CTF.
* I contributed to Kim Zetter's article on Hospital viruses: Fake cancerous nodes in CT scans, created by malware, trick radiologists featured at the Washington Post.
* While not a 2019 achievement, it is worth mentioning that in summer of 2018 I completed the Offensive Security Cracking the Perimeter course, passed the 48-hour exam and acquired the OSCE certification. I dedicated a blog post about this.
-- ithilgore, 12 January 2020
New blog
From hereon I will be posting some thoughts and ideas on information security, cyber warfare, biohacking and other topics here.
-- ithilgore, 12 April 2018
So many things
So many things have happened since my last update here (hopefully you are following me on twitter
and get my most recent updates from there):
* Moved to the US to work for Mayo Clinic as Principal Information Security Engineer.
* Mentored for Nmap during Google Summer of Code 2016 and then represented Nmap at the Google Mentor Summit.
* Released a new Ncrack version (0.5) and worked on the next one (0.6): Ncrack
* Attended Defcon 24 at Las Vegas - lots of fun.
* Attended Infiltrate Conference 2016 at Miami. Amazing hosting, presentations, training, time and place - Dave Aitel knows what he is doing.
* Authored and published a course on Mastering Nmap with Packt publishing.
I am also brainstorming and preparing a bunch of other exciting side projects - more on this soon.
-- ithilgore, 11 April 2017
Ncrack revived
Some months ago I sent a mail to the nmap-dev mailing list about the continuation of Ncrack development:
Ncrack revived. After a lot of work porting the
new openssh library to Windows, the Ncrack 0.5 release is imminent! We also have 3 new modules, 2 of which
have been contributed by another Greek developer:
Ncrack CHANGELOG.
-- ithilgore, 23 March 2016
PrimaVista, the project
I have been working on a large project called PrimaVista
for the last 2.5 years, along with friend and co-founder Fivos. PrimaVista is our
own startup that aims to help musicians move from the analog to the digital world. We recently published a major release, that
lets musicians upload their scores through a web interface and automatically synchronize them to all their devices.
We have also been working on 'magic' features like OMR (optical music recognition) that are going to be published soon.
I personally designed and implemented the back-end cloud infrastructure supported by an internal REST API,
a queuing mechanism for load balancing tasks and a custom synchronization algorithm with a robust recovery mechanism.
In addition, I developed the whole Android application which includes extra functionality like searching the
MuseScore archive for sheet music uploaded by a community of musicians.
-- ithilgore, 20 January 2015
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.
Cyber[War|Crime]
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
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:
"http://www.phrack.org/issues.html?issue=66&id;=9#article
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?
--dave"
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
Ncrack
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
IPd:
.asciz "127.0.0.1" # dest ip daddress
IPs:
.asciz "127.0.0.1" # source ip daddress
DATA:
.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
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
cld
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
Demonstration:
$ gcc raw.s -o raw
# ./raw
# tcpdump -i lo -n -X
16:57:48.495821 IP 127.0.0.1 > 127.0.0.1: 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):
linux-2.6.26/net/socket.c
/*
* 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);
out:
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:
socket.c:
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
:unix_mkname()).
*/
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"
void
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
~0xdead
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 0.0.0.0 - 239.255.255.255. 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
|
