VoIP Security Tool List

This VoIP Security Tool List provides categories, descriptions and
links to current free and commercial VoIP security tools. Each commercial tool is indicated by the following icon next to it:

The key objectives of this list are as follows:

  1. Provide links to tools that help test the efficacy of implemented best practices outlined by VOIPSA's Best Practices Project.
  2. Facilitate the open discussion of VoIP security tool information
    to help users better audit and defend their VoIP devices and
    deployments.
  3. Provide vendors the information needed to proactively test their
    VoIP devices' ability to function and withstand real-world attacks.

Very good list from VoIPSA.

Advertisements

Hacking Linux onto your 360 just got a wee bit easier

Once again, we're a far cry from PS3-Linux-easy, but those 360 kids seem rather hard to dissuade. The latest development on the XeLL bootloader front is that you no longer need a serial cable hooked up for executing the boot loader, all you need is a 360 set up for running burned DVDs,
a modified version of the King Kong disc — you'll want the original
game, Windows and a DVD burner to get that together — and of course a
Live CD with XeLL and your Linux distro all prepped to go. By now we're
sure we don't need to tell you that this is limited to those lucky 4532
and 4548 kernels, but if you've got all of the above ingredients, plus
a little bit of patience and complete disregard for warranty voidance,
it looks like Linux on the 360 is within your reach at last. Peep a
video after the break of the previous version of XeLL doing its thing.

From Engadget.

Good review of SILICA

Imagine a device that, with the push of a button, automatically scans for
wireless networks, connects to them, and then attacks each and every device on
the network. Sound like something out of Hollywood? Well, the device is real,
and for $3600 you too can own one — and then own everyone.

The device, formally known as the SILICA, was created by Immunity to assist
penetration testers with their work. It officially hit the shelves in February
2007, but has been making some headlines over the last year as Immunity
demonstrated it at various conferences. Thankfully, White Wolf Security was
gracious enough to let us borrow theirs and give it a whirl. Quite honestly, we
were expecting to be a bit disappointed because media hype is usually
exaggerated. However, not only were we dead wrong about that assumption, but we
will go so far as to highly recommend this device to anyone interested in
penetration testing from the palm of your hand.

Read the full review at InformIT.com.

Video Day at The Lazy Genius!

First from SecurityPark.net:

We are now offering video interviews with industry leaders on a wide range of issues related to the Security industry:

Second, Easynews has posted a nice mirror of many Security Conferences' Video Series.  Let the leeching begin!

McAfee maps malware risk domains

A global road map of the riskiest and safest places to surf online
found Russian and Romanian sites among the top-level domains most
commonly hosting malicious downloads, browser exploits, and scams.

A survey of 265 top-level domains by McAfee, dubbed Mapping the Mal Web,
revealed large differences in safety from one domain to another. The
worst haven for malware belonged to the the tiny Pacific island of
Tokelau (.tk), where 10.1 per cent of websites contained dodgy content.
The most risky large country domains were Romania (.ro, 5.6 per cent
risky sites) and Russia (.ru, 4.5 per cent risky sites). These East
European country domains were the most likely to host exploit or
“drive-by-download” sites run by hackers.

By contrast, three of the safest top level domains were associated with
Nordic countries, namely Finland (.fi, 0.10 per cent), Norway (.no,
0.16 per cent) and Sweden (.se, 0.21 per cent). Iceland (.is, 0.19 per
cent) and Ireland (.ie, 0.11 per cent) rounded out McAfee's list of
safe surfing habitats.

Read the full article at the Register.  The complete study, along with an interactive map, can be found here.

Security Development Lifecycle (SDL) Banned Function Calls

Prohibiting the use of banned APIs is a good way to remove a
significant number of code vulnerabilities — this practice is reflected
in Stage 6 of The Microsoft Security Development Lifecycle: “Establish
and Follow Best Practices for Development.” It can also be referenced
in Chapter 11 of the Microsoft Press Book The Security Development Lifecycle.

When
the C runtime library (CRT) was first created about 25 years ago, the
threats to computers were different; machines were not as
interconnected as they are today, and attacks were not as prevalent.
With this in mind, a subset of the C runtime library must be deprecated
for new code and, over time, removed from earlier code. It's just too
easy to get code wrong that uses these outdated functions. Even some of
the classic replacement functions are prone to error, too.

This
list is the SDL view of what comprises banned APIs; it is derived from
experience with real-world security bugs and focuses almost exclusively
on functions that can lead to buffer overruns (Howard, LeBlanc, and
Viega 2005). Any function in this section's tables must be replaced
with a more secure version. Obviously, you cannot replace a banned API
with another banned API. For example, replacing strcpy with strncpy is
not valid because strncpy is banned, too.

Also note that some of
the function names might be a little different, depending on whether
the function takes ASCII, Unicode, _T (ASCII or Unicode), or multibyte
chars. Some function names might include A or W at the
end of the name. For example, the StrSafe StringCbCatEx function is
also available as StringCbCatExW (Unicode) and StringCbCatExA (ASCII).

I'm not a developer, but I play one on TV.  If you, however, are writing any code, you should read this article by Microsoft.

An Analysis of Address Space Layout Randomization on Windows Vista

Address space layout randomization (ASLR) is a
prophylactic security technology aimed at reducing the
effectiveness of exploit attempts. With the advent of the
Microsoft® Windows Vista operating system, ASLR has been
integrated into the default configuration of the Windows®
operating system for the first time. We measure the behavior
of the ASLR implementation in the Windows Vista RTM
release. Our analysis of the results uncovers predictability in
the implementation that reduces its effectiveness.

A very interesting paper from Symantec (PDF).  I hadn't heard about ASLR before.  It seems that Microsoft came to the realization that exploits will continue to happen.  So ASLR is an attempt at making it harder to implement the exploit.  It turns out that Microsoft implementation on ASLR is flowed and lessens it's effectiveness.  Good try fellas, maybe next time.