Archive for the 'Security' Category

WarDialing using VoIP, IAX2, and WarVOX

I’ve done plenty of war-dialing projects in my day and historically had used a product called PhoneSweep. In the old days there use to be one called ToneLoc. I’ve also used Expect and other scripting languages. Well, welcome to the future…

As part of my most recent project I had a pool of about 10,000 phone lines to check for modems within a span of a few days. I had left this part of the project to the very end expecting there to be very few problems in this area (boy was I wrong about that – modem testing is the new SQL injection).

I utilized a little tool called WarVOX as part of the metasploit / Backtrack suite of tools. I first tested with my cell phone and our office numbers to verify that it wasn’t going to leave voicemails everywhere. That seemed to work.

As the war-dialing commenced, I very quickly realized that I was not going to make it in time. No problem – during the process I added an additional 8 trunks to my configuration within minutes.

Overall, it worked out quite well. I used Vitelity as the IAX2 provider. IAX2 is what WarVOX uses to talk to a pool of phone lines or trunks. Vitelity told me that use of IAX2 was not supported, but it worked despite the lack of support.

At one point, Vitelity detected a security problem and disabled the service for awhile until they verified I was who I said I was.  That is comforting to know that people with stolen credit cards attempting to do the same thing may get stopped at some point.

As the war-dialing completed, I then had to switch back to an analog phone to do the actual penetration attempts. I had to test about 50 supposed modem connections. It was a bit cumbersome to manually copy and paste the phone numbers using the existing interface to WarVOX. I hacked up the WarVOX code slightly to provide just the phone numbers in a table output to make it easy to copy and paste.

It was something of beauty to watch the phone lines being dialed in such rapid order through an Internet connection of all things. To make this even better, I had left my hacking laptop at work and was using a Windows based UNIX Graphical logon protocol (X11) client through Windows Remote Desktop (RDP) going over a mobile Internet connection to manage the war-dialing.

What a surreal experience if one stops to think about it. I’m not sure when, but one day I’m going to use this as a practical joke to ring all the phone lines in some meeting or something simultaneously.  I shall declare “It must be a sign!”.

Happy Alarms

Configuring the alarms from a health monitoring system can be challenging. The idea is to create alarms that will get the operator’s attention, won’t get ignored, are sent to the appropriate parties, and are clear and unambiguous.

To make this even more complex, numerous systems use email to send out alarms in a distributed manner. There may be a portable backup storage box with configured alarms in a non-standard format that still needs to be handled by someone monitoring the network. To make matters worse, often such devices have email alarms configured to an individual’s email address. This can cause problems when there is turnover.

As part of that I had explored all manner of ways of indicating the status of a system.

Borrowing from the Six Sigma tool set, one scheme involved using a 1,3,9 scale for ranking the severity of an item. A 1-3-9 scale forces the ranking of severity into meaningful categories. A 1-10 scale or similar provides room ambiguity.

Many systems use the existing syslog “standards” for ranking the severity of messages. This had to be incorporated.

For example:


It made sense to develop a scheme that would incorporate the syslog “standards”, the 1-3-3 scale, and provide unambiguous information to someone who had never seen an alarm unambiguous data on the severity of an alarm.

A number of distribution lists were created based on a target groups.

The following are some examples:


The last thing was designing the actual messages. It was decided that it would be important to specify fields in emails in the event that automated processing / parsing systems would have some role in reviewing messages from distributed systems in the future.

Here is a sample message:

Interface(10125) inside is Down at least 2 min on Switch: (192.168.10.X).
Monitors that are down include: Interface(10125) inside Monitors that are up include: Ping,SNMP,HTTP,Telnet,Interface(1) Vlan1,Interface(100) Vlan100 (,Interface(5010) Port-channel10,Interface(5011) Port-channel11,Interface(5015) Port-channel15,Interface(5016) Port-channel16,Interface(10101) dmz,Interface(10118) Inside – Alltel,Interface(10127) inside,Interface(10131) inside,Interface(10133) prd-003-vmi4, Channel-Group 10,Interface(10134) prd-003-vmi4, Channel-Group 10,Interface(10135) prd-004-vmi4, Channel-Group 11,Interface(10136) prd-004-vmi4, Channel-Group 11,Interface(10145) GigabitEthernet0/45,Interface(10146) sw-1 dmz trunking port,Interface(10147) sw2 inside trunking port,Interface(10148) storage trunking port,Interface(10501) Null0,”

This system has been in place for some time and seems to work well.

I kept thinking about this and realized that one of things to make this register and have people react a bit better still.

As I was thinking about this, I was shocked to discover that one of the Exchange Servers had become self-aware. Not one to waste an opportunity, I asked it about additional ways to improve this process. It reminded me that humans have emotions and perhaps that another way to improve the Health Monitoring system was by associating emotion with the status of various alarms.

So instead of saying that the DISK on Server A is RESTORE, instead we might say “Server A is relieved that it’s disk was replaced before a total system crash!”.

This self-aware exchange server, which we have now dubbed Fred, has a weird sense of humor.

OSSEC Upgrade 2.2

For those not in the know, OSSEC is an absolutely wonderful tool for monitoring the security of servers and systems. It includes automated responses, email alerting, and a fairly robust set of baseline rule. In addition, rules can be custom written like this set I did for TitanFTP.

Version 2.2 has been released recently. I suppose it is time to do the OSSEC upgrade. The 2.1 and 2.2 releases include a number of needed enhancements as follows:

1. Centralized configuration management.
2. Remote agent restart
3. Real time integrity checking
4. New Log Rules
5. WordPress Monitoring

I am mainly interested in items 1 through 3. I’ve had some issues with the integrity scan affecting performance during production hours so hopefully these changes will assist with that.

After installing the new version, I wanted to check out the impact that the integrity checks had on performance. I setup a test server and a test windows client.

From the Linux based ossec server:

root@prd-001-hids:/var/ossec/bin# ./agent_control

OSSEC HIDS agent_control: Control remote agents.
Available options:
-h          This help message.
-l          List available (active or not) agents.
-lc         List active agents.
-i <id>     Extracts information from an agent.
-R <id>     Restarts agent.
-r -a       Runs the integrity/rootkit checking on all agents now.
-r -u <id>  Runs the integrity/rootkit checking on one agent now.

-b <ip>     Blocks the specified ip address.
-f <ar>     Used with -b, specifies which response to run.
-L          List available active responses.
-s          Changes the output to CSV (comma delimited).
root@prd-001-hids:/var/ossec/bin# ./agent_control -r -a

OSSEC HIDS agent_control: Restarting Syscheck/Rootcheck on all agents.root@prd-001-hids:/var/ossec/bin#

I noted on the ossec client that there was a bit of a hit on performance during integrity scanning; however, it does not seem to be as bad as previous versions.

Terminal Services Dictionary on Ubuntu

apt-get remove rdesktop

apt-get install openssl libssl-dev libx11-dev

Get the source to version 1.50 from

Get the patch

tar -xzvf rdesktop-1.5.0.tar.gz

cd rdesktop1.50/
patch -p1 -i rdp-brute-force-r805.diff
make install

Brute-force attack using password file:

rdesktop -u administrator -p passwords.txt