nc2 : Netcat without a couple of annoyances

Netcat is without doubt one of the most useful tools I know. For years I've used it almost every day, and I still do, in different platforms. Its simplicity is its beauty.

All this time, however, two small details have kept the experience from being absolutely perfect for me. I know there are many rewrites of nc out there nowadays and some versions may not show the behavior I'm about to describe. I'm talking here about code based on that original from Hobbit, both for Linux (v1.10) and for Windows (v1.11).

The first annoyance is (was) in the Linux version. While in the Windows version there is a "-L" option ("listen harder") to make netcat continue listening for new connection attempts after a connection is terminated, there is no such option in the Linux version. You can get around it by launching netcat inside a "while" shell loop, but personally I've always found that to be a pain in the neck, especially when you compare it to simply invoke netcat with a capital "L" instead of lowercase "l", as you do in the Windows version.

The second annoyance is (was) in the Windows version. If you send a file through the client netcat's standard input (e.g. "cat(or type) file.txt ¦ nc target_ip target_port"), in Linux netcat terminates the connection as soon as it is finished sending the file, but in Windows the connection stays active until you tear it down manually, pressing CTRL-C, when you think the transfer is finished. That simply sucks.

Well, I decided to put an end to it. I downloaded the source code, which fortunately is distributed under the GPLv2 license, made a couple of tiny modifications (yes, you may call them quick and dirty hacks, I won't be offended) et voilà, "nc2" was born. Thus, let me make it clear that "nc2" is nothing more than "nc" with two little hacks that eliminate the small annoyances I just described.

I made it for myself, but I decided to publish it in case someone else finds it useful. The zip file (nc2-all-080925.zip, MD5 b26fd6bab7b4a4d89a76fa52dca0f64b, SHA1 b8639b450974a182b67fa637aa9484d111bff534) contains binaries for both platforms ("nc2" and "nc2.exe", respectively), their source code, and a copy of the original source code I derived nc2 from. I downloaded the Windows version from http://joncraton.org/files/nc111nt.zip and for Linux I used the source code of the netcat package that comes with openSUSE 10.3 (yes, you got me, I used NETinVM for this too :-) ).

Finally, and before you ask... I renamed it to "nc2" because this way it is easier for my feeble mind to distinguish when I'm running my own version or some other. For those of you with stronger minds that may feel outraged by this fact, I only have two words: "mv" and "move" ;-).

David Perez.

Security Book Review: "Applied Security Visualization"

"Applied Security Visualization"
Authors: Raffael Marty
Editorial: Addison-Wesley Professional
Publication date: August, 2008
ISBN-10: 0321510100
ISBN-13: 978-0321510105
http://safari.awprofessional.com/9780321510105



Summary: Definitely Security Visualization is one of the most relevant present and future topics in the security field, and this book is simply THE reference.

Score: 5/5

Review:
When security professionals are dealing with huge amounts of information, and who is not nowadays, correlation and filtering is not the easiest path (and sometimes enough) to discern what is going on. The in-depth analysis of security data and logs is a time consuming exercise, and security visualization (SecViz) extensively helps to focus on the relevant data and reduces the amount of work required to reach to the same conclusions. It is mandatory to add the tools and techniques associated to SecViz to your arsenal, as they are basically taking advantage of the capabilities we have as humans to visualize (and at the same time analyze) data. A clear example is the insider threat and related incidents, where tons of data sources are available.

The best sentence (unfortunately it is not an image ;) that describes SecViz comes from the author:

A picture is worth a thousand log entries.

This is a great book that joins two separate worlds, visualization and information security (infosec). The first chapter is an excellent introduction to the human perception system, its basic principles, and how we analyze, discern, and assimilate information. It is an eye opener for those new to the field. Chapter two is similar from an infosec perspective, and summarizes the main challenges and data sources, such as packet captures, traffic flows, and firewall, IDS/IPS, system, and application logs. The third chapter details different graph properties and chart types, including some open-source and online tools for chart and color selection. Although we (infosec pros) are familiarized with link graphs to represent relationships between botnet members or hosts, the book provides a whole set of charts for different purposes; one of the most useful types, and we are not very used too it in the security field, is treemaps. The chapter includes a really useful table to select the right graph based on the purpose of the analysis and the data available.

Then, the previous chapters are smoothly mixed together through a reference methodology that defines what is the problem to solve, and the process to manipulate the available data and generate a (or set of) graph(s) that allow gathering relevant conclusions and answers. The methodology is complemented with an introduction to the standard Unix-based text processing tools (grep, awk, Perl, etc). This methodology is later on applied, with a strong hands-on and how-to spirit, to an extensive set of common security use-cases, such as the perimeter threat, compliance, and the insider threat.

The perimeter chapter offers a deep insight into common attack scenarios, such as worms, DoS or anomaly detection, and operational tasks, like firewall log and ruleset analysis, IDS tuning, or vulnerability assessments. I could never forget how useful were SecViz techniques for anomaly detection on a huge DNS-related incident I was involved about 5 years ago. Thanks to the performance and statistical graphs we had available at that time, we were able to easily identify and solve a very complex and critical security incident.

When I saw this chapter included a wireless section I got really excited due to personal interest. However, I was disappointed as it was just a couple of pages. I think it could be extended to gather a whole set of useful information about complex wireless attacks and client and access points relationships, just by inspecting the different 802.11 management, control, and data frames, and even radio-frequency signals (from a spectrum analyzer). SecViz opens the door to a whole new wireless research area!

The compliance chapter offers a whole methodology to check and manage regulations, control frameworks, auditing, and risk monitoring and management from a visual perspective.

The same applies to the insider threat chapter, as it provides an impressive framework, not only visualization-based, to deal with malicious insiders. It is based on setting up scores for certain behaviors and activities (precursors), generating lists of suspicious candidates, and apply thresholds to accommodate exceptions. It also contains an extensive and directly applicable precursor list at the end to detect suspicious insider activities.

Finally, the book contains a whole chapter, full of references and comparison tables, of open-source and commercial visualization tools and libraries that allow the reader to select the appropriate tool for specific tasks and scenarios.

Although the book hands-on component is very significant, with lots of detailed examples of commands, scripts, and tool options to generate the different graphs, I would have liked to see a thorough usage of the how-to portions, as for some sections there are no specific details about how the graphs have been generated. The book layout makes it the perfect candidate to become a fully interactive technical book. I would suggest to add (for a 2nd edition ;)) practical sections to each chapter where the reader could reproduce all the steps discussed. The book CD is the perfect tool to provide the reader with all the (sanitized) data sets and logs used to generate the graphs, and even allow to include some challenges where the reader needs to analyze the data and answer some questions after generating the appropriate graphs.

To sum up, this book is a mandatory reference for anyone involved in the operational side of infosec, doing intrusion detection, incident handling, forensic analysis, etc, and it can be applied to both, historical analysis and real-time monitoring. Additionally, I found it useful too for auditing and pen-testing professionals, as it provides great tips to generate relevant and efficient graphs for the associated reports.

The accompanying DAVIX Live CD is an excellent resource to start applying the techniques covered throughout the book through open-source tools, SecViz is the Web portal to expand your knowledge on this topic, and AfterGlow is (one of) the most relevant SecViz open-source tools.

UPDATE: Amazon review and Bookpool review (1st)

The Evidence was in your Monthly Cell Phone Bill!... Bluetooth?

About 11 months ago I posted a kind of security challenge about my cell phone. Sorry about the delay, we have had some readers (Thanks Robin! et al) reminding me and asking "what happened". You deserve the information ;), so finally, here it is!

Answers to the questions raised in the previous blog post:

1) What are the incident response steps you would follow to discern what happened?

On purpose, I'm not going to be too formal following the recommended 6-step Incident Handling process we use and teach in the SANS Security 504 course. The first think to consider is this post itself... eh? You need to go through a final "Lessons Learned" phase, summarize, agree on, and report what happened and how to avoid similar incidents in the future. No matter how busy you are after the incident, and it is better late than never (this post is the best example), you need to do it.

First of all, you need a good detection mechanism, anomaly-based in this case, to detect deviations from the norm. After being aware of the extra charges, I started analyzing in-depth the logs, that is, the cell phone bill details. I focused on the specific date and time the messages were sent. Let's say September 9, between 21:50 and 22:05 (16 minutes). I focused on remembering where I was on that date, what I was doing at that time, and where my cell phone was on that specific moment :) I checked with the people around me at that date and time to double check my memories (team work).

I also tried to identify a pattern in the timing for the message generation during the 16 minutes period without success. There were minutes without messages, minutes with a single message, and minutes with up to five messages. The number of messages per minute in the 16 minutes period were: 1 3 1 3 2 0 1 0 1 5 1 0 1 0 3 2.

Additionally, I inspected the list of sent messages on the cell phone, trying to gather more evidence about the incident. Unfortunately, the list was empty. I checked the phone settings and discovered that the "Save all sent messages" option was off :( Time to change it for future incidents and reflect it into the "Lessons Learned" report. Check your phone at this point, exercising the "Preparation" phase, and be sure you enable as much logging as possible (if the phone memory can support it), so that you can have all the evidence available in future incidents.

I made a call to the telecommunication provider just to notify them about the incident and get them involved in reviewing the case. The person taking care of my call checked the description and classified it as "consecutive SMS messages sent" event. It seems it is something they already have categorized ;) The reason they initially argued was that my cell phone brand (of course, they know my cell phone brand) sometimes present this misbehavior. Amazing! ;) It is the first time I see this and I was tempted to ask: Does it apply to all models from the same manufacturer? (BTW, the brand was one of the major cell players world-wide)

Finally, I was following the incident with the provider, and three months later (one of the reasons that delayed this post), they agreed that it was a misbehavior on their billing system and decided to return my money back. From a technical perspective, unfortunately, it was not due to a new cutting-edge hacking technique ;)


2) What do you think is the most probable security threat/vulnerability/exploit that could explain this type of incident?

Being wireless one of my preferred security topics, the first thing that came to my mind was... Bluetooth!! Perhaps I left the Bluetooth radio enabled by mistake and someone was able to take advantage of it through a bluebugging attack (sometimes referred as bluesnarfing). Sometimes people mix these two types of Bluetooth attacks as they are very similar.


Both anonymous attacks allow an intruder to exploit a vulnerability in the phone firmware and get unauthorized access to the cell phone capabilities and run commands through Bluetooth without notifying or alerting the user, that is, evading any authentication and authorization mechanism:

• Bluebugging uses the RFCOMM and Serial Port profile to get control of the phone telecom capabilities through AT commands, that is, the attacker can send make and forward calls, establish data connections, send and receive text messages (SMS) - this is what I thought - and even turn the device into a listening bug. View an example from The Real Hustle.

• Bluesnarfing uses the OBEX Object Push profile to get access to the storage capabilities of the device, including the list of contacts, calendar, SMS boxes, files (images, audio, video, etc), IMEI, etc.

Although these are old Bluetooth attacks, I'm sure we still are going to see similar vulnerabilities in new phone models, as it is an implementation bug. If you want to test your device, I suggest you to port and service scan it from a Bluetooth point of view using the psm_scan (1-65535) and rfcomm_scan (1-30) tools.

Another option, as Robin pointed out, could have been someone around me, like the kids (it is always good to have kids around to blame them for it ;)), playing with my phone and impulsively voting through SMS in any of the popular TV programs. It was not the case :)

Finally, do not forget to add all your mobile, and especially Bluetooth devices, to your common detection, incident handling, and computer forensics best practices, as well as to your auditing and pen-testing capabilities. It is time to do so, as these devices are used for really sensitive information and tasks! For this same reason, new cutting-edge Bluetooth sections and labs have been recently added to the SANS "Wireless Ethical Hacking, Penetration Testing, and Defenses" course.