This is akin to how I felt a few weeks ago after I finally got ahold of a Nokia N900 smartphone. Calling it a phone is a bit of a stretch, as it is primarily a Debian Linux tablet with impressive hardware specs and a huge number of .deb packages available for installation…oh, and you can make cellular phone calls with it. Many people use this phone, and despite some glitches it is rapidly developing into a formidable platform for security tools and penetration testing.

Broadly speaking, the objective of this series of blog posts is to introduce folks to the tools available and the potential for this phone as a security testing platform. Given the fact I’m a bit late in obtaining this phone, some smart people out there have already started to address the n900′s capabilities and available tools, and I would be remiss not to mention, and build upon, their insightful work. The key phrase here is “build upon” and get the word out, not to steal or simply re-hash their fine work and efforts!

I’ve one caveat to this series of blog posts. As my n900 is for now a “production phone” for me in that I need to use it and can’t brick it just yet, the path of this blog series on “Weaponizing the Nokia N900″ will progress from known, tested and functioning security tools on this phone — and therefore lower risk of bricking — to more advanced, edgy tools that require more tweaks and modifications, such as replacing the stock kernel. If someone out there finds this series useful, and has interest in furthering research on running security tools on the n900, I’d welcome the donation of a n900 for development and testing, and would credit them for their support. Please ping me offline if you’re interested

NeoPwn and the Nokia N900

One project to watch in particular is the upcoming release of NeoPwn, which is based on BackTrack and bills itself as the “First Ever Network Auditing Distribution for a Mobile Phone Platform” and is due for release sometime this month, hopefully before DefCon. I am fortunate to be in the BETA and will write up a blog post for this series on NeoPwn once I get full access to the NeoPwn toolset.

Worthy Resources on Nokia n900 Security Tools

1. Metasploit on the Nokia n900. ‘Nuff said.

2. knownokia.ca Blog SimonLR wrote an excellent post on “Using the N900 for Fun and Profit” that covers several awesome tools, such as Metasploit, Dsniff, SSLstrip, Aircrack-NG, etc. He’s clearly savvy and his future blogging on tools for the n900 will be great to see.

3. Asterisk on the n900

When I added the extra package repositories to my n900, I was more than a bit surprised to see a full version of Asterisk available as a .deb package. Wow. Think about this for a moment. One can run a full Asterisk server on a phone in their pocket. The capability of Asterisk on the n900 could enable attackers to do all sorts of mischief, such as running the SPITTER tool from their pocket as a simple example. From a surveillance aspect, think of “bad people” with n900s in their pockets running Asterisk servers on their phones and connecting to each other point-to-point over encrypted tunnels — now that’s a challenge.

Stay tuned for more posts on “Weaponizing the Nokia N900″

Streaming audio should be available on ietf71-ch4.

Jabber group chat should be available as well, but I don’t know yet in which chat room it will be. There isn’t yet a chat room on the IETF server for ‘rucus’. I’ll update this post once I know where the chat room is.

UPDATE: A request is in to create the ‘rucus@jabber.ietf.org’ room. If that room isn’t created in time, we’ll use the SIPPING room at ‘sipping@jabber.ietf.org’. We’ll announce on the streaming audio which one we are using.

Technorati Tags:
ietf, spit, spam, rucus, voip security

buy viagra
buy viagra online
viagra online
discount viagra
order viagra
cheap viagra
generic viagra
generica viagra
viagra buy
viagra price
order viagra online
viagra generic
viagra pill
where buy viagra
buy viagra cheap
viagra order
get viagra
buy online viagra
online viagra
viagra sale online
where to buy viagra
cheapest viagra
purchase viagra
cheap viagra online
viagra buy online
buying viagra
buy viagra on
generic viagra canada
prescription viagra
buy viagra norway
generic viagra pack
buy viagra in nevada
buy viagra now online
viagra online buy
find viagra online
buy cheap viagra online
cheap generic viagra
buy cheap viagra
generic viagra online
viagra sale
generic viagra cheap
buy viagra on line
where buy generic viagra
viagra online bestellen
viagra prescription online
generic online viagra
low price viagra
cheapest viagra price
buy generic viagra
viagra uk
viagra online prescription
cheap est viagra
viagra soft tab
viagra discount
viagra cheap
where to buy viagra on line
buying viagra online
buy viagra now
purchase viagra online
viagra pharmacy
natural viagra
buy viagra in canada
viagra paypal
viagra on line
viagra 100mg
viagra without prescription
cheapest place to buy viagra online
generic Cialis
buy cialis
buy cialis online
cialis online
online cialis
order cialis
cheap cialis
discount Cialis
generic cialis price
cialis prescription
buy cialis generic
cialis online discount
cheapest cialis
buy discount cialis
purchase cheap cialis online
order cialis online
cialis for sale
cialis price
purchase cialis
cialis online pharmacy
buy Cheap Cialis
cialis story
generic cialis online
best cialis price
cheapest cialis generic
order generic cialis
low cost cialis
buy cialis generic online
levitra
buy levitra
cheap levitra
levitra online
buy levitra online
order levitra
order levitra online
cialis levitra
generic levitra
online levitra
buy cheap levitra
discount levitra
levitra sale
buy generic levitra
levitra online pharmacy
levitra price
purchase levitra
cheap levitra online
levitra story
levitra on line
levitra prescription
levitra cheap
best price for levitra
buy xanax
buy phentermine
buy lasix
tramadol
buy tramadol
buy tramadol online
tramadol online
cheap tramadol
order tramadol
tramadol hcl
ultram tramadol
tramadol prescription
online tramadol
tramadol sale
purchase tramadol
buy cheap tramadol
order tramadol online
overnight tramadol
tramadol cheap
tramadol pharmacy
discount tramadol
tramadol hydrochloride
tramadol 50mg
cheap tramadol online
generic tramadol
buy clomid
buy prozac
buy cipro
buy diflucan
buy acomplia
buy lexapro
buy flagyl
buy propecia
order propecia
cheap propecia
propecia online
order propecia online
buy propecia online
generic propecia
compare propecia
propecia without prescription
propecia prescription
propecia pill
discount propecia
online propecia
cheapest propecia
get propecia
propecia order
propecia price
propecia uk
propecia cost
propecia sale
purchase propecia
buy cheap propecia
propecia sale online
buy online propecia
online pharmacy propecia
online prescription propecia
buy generic propecia
buying propecia
buy propecia now
buy fosamax
buy kamagra
buy clomid online
buy prozac online
buy cipro online
buy diflucan online
buy acomplia online
buy lexapro online
buy flagyl online

If you saved the URL or sent it on to someone, you’ll need to update to using the new URL. If you didn’t visit the RUCUS page before, please do check it out – and feel free to join the RUCUS mailing list. Of course, if you can, please do join us in person in Philadelphia!

Technorati Tags:
spit, ietf, spam, rucus, standards, sip

The RUCUS mailing list is now open for subscriptions and we encourage anyone interested in looking at how we address the issue of voice spam, aka “Spam for Internet Telephony” aka “SPIT” to join into the conversation.

We would ask you to please read the group description prior to joining so that you understand what we are trying to do. The primary goal of this session in March in Philadelphia is to look to understand the architecture necessary to address the issue and identify the pieces of that architecture that may already be there or may need to be put in place.

Technorati Tags:
rucus, spit, spam, voice spam, voip, voip security, security, ietf, standards

Want to get together with others and discuss in further detail what we can do about Spam for Internet Telephony (SPIT)? A new session has been approved for the IETF 71 meeting coming up in Philadelphia in March called “Reducing Unwanted Communications using SIP” a.k.a. “RUCUS” (Hey, it’s not a real IETF group until it has a cute acronym!) Hannes Tschofenig, who submitted the proposal, has created a RUCUS web page and is looking for feedback. The page says in part:

The topic of dealing with unwanted traffic in SIP has surfaced several times in the IETF in the context of preventing Spam for Internet telephony. Previous attempts to have a structured discussion about this topic have (among other reasons) failed due to the strong focus on selected solution approaches.

Prior work in SIP on identity management has an important role in this activity since a strong identity mechanism in SIP has been seen as a prerequisity for establishing authorization policies. Hence, the “Discussion and Analysis of SIP Identity” (DASI) BoF is relevant for this event. Even though there is no direct dependency between the two activities the number of interested participants will quite likely overlap.

This BoF focuses on the discussion of architectural aspects. The underlying theme is that the work on building blocks is more fruitful once the larger framework is understood. A number of solutions components have been submitted to the IETF, have been published in the academic literature and found their way into other standardization bodies. Reduce unwanted communication requires authorization decisions to be made. These decisions can be made based on individual sessions but also on the interaction at a higher granularity (e.g., the interaction with a specific VoIP provider network). Examples of questions with relevance for an architecture might be:

- Where does information for decision making come from?

- What are useful information items for decision making?

- Where are policy decision points located? What about the placement of
policy enforcement points?

- Are privacy aspects to consider with the exchange of information?

- How does the underlying trust model look like?

- What assumptions are certain mechanisms based on?

- Can individual proposals be combined in a reasonable way?
etc.

It is not the aim of the BoF to discuss specific solution approaches since it is likely that multiple techniques have to be used in concert.

If you are attending IETF 71 in Philadelphia in March, do plan on joining in the RUCUS! (I’ll be there.)

Technorati Tags:
rucus, spit, spam, voice spam, voip, voip security, security, ietf, standards

The RFC is an excellent summary of the current thinking about the
SPIT problem and potential solutions to address it. If you haven’t
read the document, I would *highly* recommend it.

A concern I had, though, was that it did not appear to me that
existing documents address the issue of what SPIT could look like at
a network level. For instance, if a network administrator monitoring
network traffic suddenly saw a large flood of SIP INVITE packets
coming into his/her network, it could be:

1. a telemarketer/spammer launching a flood of SIP connections to
deliver SPIT;
2. an attacker launching a DoS attack through one of the various SIP
attack tools out there; or
3. a legitimate notification system starting to notify a range of SIP
endpoints.

I could very easily see existing network tools that look at traffic
and perform anomaly detection (and potentially source suppression)
being modified to suppress large flows of SIP traffic. This last case
of legitimate traffic concerned me and so I put together an Internet-
Draft talking about the types of legitimate systems that might
generate a significant volume of traffic that could resemble SPIT (or
a DoS attack).

I put the document out primarily to stimulate discussion. Are these
legitimate scenarios being addressed in current thinking about
SPIT? If not, my point really is that they need to be considered.

Comments about the document are very definitely welcome. Are there other scenarios I
should include? Am I accurate? Am I overstating the case? or what?

Technorati Tags:
ietf, security, sip, standards, voip, voip security

Rosenberg touched on many topics in his presentation on the challenges for IP telephony, but of course one of the challenges he talked about was SPIT or voice SPAM. He said that one basic decision point is whether you know the caller or not. As long as we have strong identity on VoIP networks, it’s possible to keep a white list of permitted callers. Then the problem becomes how to enroll people on to that list in the first place.

Safely letting in people that you don’t know opens the field to a whole range of different techniques. Some that he mentioned include: consent and reputation systems; CAPTCHAs; computational puzzles and payments at risk. Some of these he outlined as more promising than others, but the point is that this problem is not solved yet, and in fact is an ongoing discussion in the IETF and elsewhere.

For the uninitiated, CAPTCHA means “Completely Automated Public Turing Test to Tell Computers and Humans Apart”, or in other words an automated test of your humanity. In the context SPAM over Internet Telephony, the aim is to tell genuine human callers from ‘bots’ or software that aims to make our phones ring and play unwanted marketing messages at us.

Some of the choices are laid out there, for example a system (corporate PBX for example) could challenge an incoming call, by playing a sound, then asking you to describe the sound. Or in the case of a video call, show you a picture and ask you to describe it in words before connecting the call. A moment’s examination would allow a human to conclude “teapot”, where a computer looking at a cartoon or photo teapot would need to expend a lot of CPU to reach the same result.

Ok, you may say that computers are so smart now that they can recognize pictures, or do automatic speech recognition (speech to text) remarkably well. This is true, to a degree, but the fact is that clever CAPTHCAs will demand heavy processing on the attacker’s side, and this works against what they are trying to do. After all, they want to implement systems that can make thousands of calls per hour at low cost. If we increase the cost of the calls by adding a quarter of a second of CPU to each call, then we give the telephony spammers a capacity problem, and force them to spend much more on server machines. By making SPAM an economic problem once again, we can raise the barriers to entry.

The draft text can be found here, and Hannes’s blog is here.

Technorati Tags: SPIT, SPAM, CAPTCHA