Posted by & filed under Secure Development, Security News.

Wow, if this is even remotely true, it’s quite spectacular: Theo de Raadt,  has made public an email sent to him by Gregory Perry, who worked on the OpenBSD crypto framework a decade ago. The claim is that the FBI paid contractors to insert backdoors into OpenBSD’s IPSEC stack, a stack that has been re-used in many other products. Full email below:

I have received a mail regarding the early development of the OpenBSD
IPSEC stack. It is alleged that some ex-developers (and the company
they worked for) accepted US government money to put backdoors into
our network stack, in particular the IPSEC stack. Around 2000-2001.

Since we had the first IPSEC stack available for free, large parts of
the code are now found in many other projects/products. Over 10
years, the IPSEC code has gone through many changes and fixes, so it
is unclear what the true impact of these allegations are.

The mail came in privately from a person I have not talked to for
nearly 10 years. I refuse to become part of such a conspiracy, and
will not be talking to Gregory Perry about this. Therefore I am
making it public so that
(a) those who use the code can audit it for these problems,
(b) those that are angry at the story can take other actions,
(c) if it is not true, those who are being accused can defend themselves.

Of course I don’t like it when my private mail is forwarded. However
the “little ethic” of a private mail being forwarded is much smaller
than the “big ethic” of government paying companies to pay open source
developers (a member of a community-of-friends) to insert
privacy-invading holes in software.


From: Gregory Perry <[email protected]>
To: “[email protected]” <[email protected]>
Subject: OpenBSD Crypto Framework
Thread-Topic: OpenBSD Crypto Framework
Thread-Index: AcuZjuF6cT4gcSmqQv+Fo3/+2m80eg==
Date: Sat, 11 Dec 2010 23:55:25 +0000
Message-ID: <[email protected]omain.local>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset=”iso-8859-1″
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Status: RO

Hello Theo,

Long time no talk. If you will recall, a while back I was the CTO at
NETSEC and arranged funding and donations for the OpenBSD Crypto
Framework. At that same time I also did some consulting for the FBI,
for their GSA Technical Support Center, which was a cryptologic
reverse engineering project aimed at backdooring and implementing key
escrow mechanisms for smart card and other hardware-based computing

My NDA with the FBI has recently expired, and I wanted to make you
aware of the fact that the FBI implemented a number of backdoors and
side channel key leaking mechanisms into the OCF, for the express
purpose of monitoring the site to site VPN encryption system
implemented by EOUSA, the parent organization to the FBI. Jason
Wright and several other developers were responsible for those
backdoors, and you would be well advised to review any and all code
commits by Wright as well as the other developers he worked with
originating from NETSEC.

This is also probably the reason why you lost your DARPA funding, they
more than likely caught wind of the fact that those backdoors were
present and didn’t want to create any derivative products based upon
the same.

This is also why several inside FBI folks have been recently
advocating the use of OpenBSD for VPN and firewalling implementations
in virtualized environments, for example Scott Lowe is a well
respected author in virtualization circles who also happens top be on
the FBI payroll, and who has also recently published several tutorials
for the use of OpenBSD VMs in enterprise VMware vSphere deployments.

Merry Christmas…

Gregory Perry
Chief Executive Officer
GoVirtual Education

“VMware Training Products & Services”

540-645-6955 x111 (local)
866-354-7369 x111 (toll free)
540-931-9099 (mobile)
877-648-0555 (fax)

The real news here is of course not that OpenBSD IPSEC may be insecure. But the allegations (and yes, they are allegations only)  shows that code audits are vital in high-security projects, even if they’re Open Source.

Posted by & filed under Hacks, Security News.

Gawker has been hacked, and their whole user database was just leaked at The Pirate Bay, containing over 500 megs of usernames and passwords to Gawker, Gizmodo, Jalopnik, Jezebel, Kotaku, Lifehacker, Deadspin, io9 and Fleshbot. A couple of minutes ago I noticed an email from LinkedIn, stating:

Dear X,

In order to ensure that you continue to have the best experience using LinkedIn, we are constantly monitoring our site to make sure your account information is safe.

We have recently disabled your account for security reasons. To reset your password, follow these quick steps:

  1. Go to the LinkedIn website
  2. Click on “Sign In”
  3. Click on “Forgot Password?” and follow the directions on the website

Thank you,
The LinkedIn Team

My first thought was that LinkedIn was hacked too; fortunately the mail was just a precaution taken by the LinkedIn staff to protect accounts that might have been compromised. Kudos to LinkedIn for responding so quickly and proactively.

So yeah, my password is compromised. Fortunately I use a password hierarchy (using the same type of passwords on “low-value” sites where I don’t store any personal information) , so the chances of it being exploited in any way is minimal. Still had to go through the boring job of changing it on several other sites though…

Update: Ok, so I tried to get my new password from LinkedIn using the procedure above. I clicked the “Forgot password” link, and I was greeted with the following:

Notice anything strange? How about:

Please enter the email address you used to create your LinkedIn account, and we will send you a link to reset your password.

Ouch. Now you are making it very difficult for yourself (and me, I might add) LinkedIn: I got rid of that mail account many years ago. Guess I have to call customer support.

Update 2: I tried to supply my new e-mail address instead of the one I used to create my LinkedIn account, and the reset worked. There seems to be some slowness in the system though. Here’s what I received from the LinkedIn team:

Dear X,

We have received your request to reset your LinkedIn password. Please use this secure URL to reset your password within 5 days.
To reset your password, please enter your new password twice on the page that opens.

If you cannot access the link above, you can paste the following address into your browser:

Thank you for using LinkedIn!

– The LinkedIn Team

Update 3: While I feel that this is a good security move by LinkedIn, I cannot avoid commenting on the “window of opportunity” it creates for phishing attacks: Using LinkedIn features such as viewLink one can serve malicious content or fake login pages, as Shlomi Narkolayev has shown.

If I were a malicious hacker I’d start serving fake password reset forms off these URLs, copied the legit mails above and… Well, the rest is obvious. Security is never easy.

Posted by & filed under Hacking & Pentesting, Tools & Methodology.

Just got a tip about this search engine – SHODAN.

SHODAN is basically a banner grabbing search engine: It scans the Internet for machines running services on common ports, contacts these and stores the banners that it gets in return. It makes these banners publicly searchable. Banners are not sensitive information, but they often contain the name of the service and it’s version number, and that’s why pentesters (and hackers) often use this to profile the service. Profiling or “fingerprinting” is an essential skill in the pentesters arsenal: The name and version may come in handy if you want to exploit a weakness in a specific service, say OpenSSL v0.9.7 or if you’re just looking for anything vulnerable to wreak havoc.

SHODAN enables the last part. It’s like Google except that instead of searching for content, you can search for vulnerable services. It also correlates the IP with the geographic location, so that you easily can find servers running Cisco IOS with their managmenet interface available on the Internet (bad idea) in for example Norway, where I’m from.

It’s kind of a continous port scan, and the implications of it is potentially harmful – it makes it very easy to identify vulnerable services that are accessible from the Internet. The legality is also a bit shady as port scanning is not considered polite, and publishing the results online, well that’s just rude.

Just like firesheep, the idea is not new, but the moment someone systemizes the information or creates a tool, suddenly everybody pays attention.

Of course this can be a great tool for pentesters. The problem I have with it is ethical; someone should really alert the sysadmins that are responsible for these services, some of them are so easy to attack that I find it funny that they are still up and running online.

Posted by & filed under /dev/random, Security News.

Susan Crawford has some very interesting thoughts in a recent blog post about how certain agencies seem to be lobbying for increased funding to “cyber war capabilities” and increased Internet control by feeding the mainstream media with news. FTA:

[…] the agencies that are most interested in forwarding cyberattack abilities, surveillance, guaranteed back doors for encrypted communications, and all the other trappings of a “more authenticated Internet” have an interest in portraying their vision of the future Internet as inevitable.  Part of that campaign would logically be to get the story into the mainstream media.[…]

I guess it would make sense to try to wedge the public opinion in your favor, or at least to plant the idea that there are such a threat as “cyber war” if you wanted increased control over the Internet. Personally i feel that the notion of a “cyber war” is a bit far fetched, since an eventual conflict in cyberspace would be nothing like the wars we’re used to.

Warfare just doesn’t translate into cyberspace, since the covertness of the Internet effectively (often) prevents people from identifying the actors. It’s much easier (though not easy) to identify actors in a regular war, since the physical presence is much harder to hide than that of a digital one. For example, you would notice if you had 1000 soldiers standing outside your door right now, but probably not if you had 1000 hackers on your router covertly controlling your box.

The other way around; cyber threats doesn’t necessarily translate into real-world threats. It can be difficult to inflict real-life damage from a cyber perspective.

I’d say that “Cyber wars” has more in common with espionage and terror. The threat can be hard to assess, it moves over covert lines and often hits unexpected places. This also makes the cyber threat more difficult to defend against, just like the above.

By the way, Howard Schmidt, the new “cybersecurity czar” in the Obama administration has some good points about this and all the media fuzz.

Posted by & filed under /dev/random.

I’m currently reading the book “The Black Swan” by Nassim Nicholas Taleb, and it’s been a while since I have been this captured by a book. Taleb convincingly argues that we all (humans, that is) are failing to recognize the great events that change history – aka the “black swans”. He is exploring these highly improbable, but high-impact events, and dives into why we simply fail to predict or even try to guard against them.

I’m not done reading yet (I’m savoring every minute of it), but I find the parallel to my own profession are quite obvious: We security professionals are blissfully unaware of the game-changing events that will occur within information security, even though we have made it our profession to be able to predict it.

Yes, we do put a lot of effort into making predictions on the evolution of malware, advanced persistant threaths, cyber warfare etc., but how accurate are we really? I mean, given thousands of security researchers, someone is always makes the right call, but that doesn’t mean that we are any good at predicting, does it? If we were any good at it, the cyber criminals would have a hard time making money (unless they were as good or better at predicting than us).

But they are making money. Yet we behave like we know whats going on, when we are in fact no better on predicting whats next than a person with no knowledge on the subject whatsoever. It’s the same as “Doctor Doom” that predicted the credit crunch: Given millions of over-paid financial advisors, one shmuck was bound to be right. Pure luck?

Many predictions made in the field today is based on what happened last year (empiric data and “trends”), what CISO’s say they fear the next year to some worldwide survey (systematic hearsay) or what some security guru has blogged about recently (I’m shooting myself in the foot here, but: “less systematic” hearsay).

But how do we know that these data are any relevant for the future? Knowledge of them may enable you to shield your company from repetitive, predictable events (say, viruses, drive-by hacks, etc.), but will fail completely if someone does something unpredictable like getting access to your data through your backup provider. So how secure are we really? It’s easy to say in retrospective that an event could have been foreseen, but there are infinite ways of behaving unpredictable, and I know from personal experience that the word “infinite” and “IT Security Budget” is seldom uttered in the same sentence by management.

The truth is that we really can’t predict these events. Even so; these are the kind of events that can or will incur a major loss and maybe put you out of business. They have costs associated that are in a different league than those associated with virus attacks et cetera. But they are rare. At least we think they are rare, because no one (well, few) are reporting them. This does not mean that they do not occur, for some reason companies are not too eager to publish that their security has been breached. So we deal with both known unknowns (we know that there are some things that we don’t know, for example how many breaches that take place each day) and unknown unknowns (we don’t know that there are some things that we don’t know, which of course is even more serious). Donald Rumsfeld has a much ridiculed, but entirely correct definition at a press conference explaining the lack of WMDs in Iraq:

The known unknowns we can do something about; by sharing incident response and breach data we can make sure we are all up to speed and that we are cooperating against a common threat, and minimize the “unknown playing field”. The unknown unknowns are, in their nature, more elusive. These are also the events that often has the greatest impact, given that no one expects them. Including information security professionals.

So if we’re not any good at predicting the future and these “black swans” aka unknown unknowns, how can we claim to be able to protect our customers? Working within security today feels more like running from leak to leak on a sinking ship, trying to plug holes as they pop up all over the place. I think this also will be the case in the future – as long as business wants to trade risk (or, to make the consumer take a risk unknowingly) for money, security won’t be a priority. I’m not saying that trading risk for money is a bad idea – taking risk is vital for most economic environments to function properly. 

But security holes are here to stay, since we cannot predict them and because it is good business to ship applications with holes in them. Which of course is good news for me, since I’m the guy running from leak to leak, but bad news for the community as a whole.

Posted by & filed under /dev/random, Tools & Methodology.

Finally found a good Common Vulnerability and Exposures (CVE) database: There are several (seemingly) similar databases that pretty much lists up all vulnerabilities that are included in CVE, but these guys takes it one step further with plenty of drill-down options and easy searches. Among its features, the site has graphs of types and occurrence frequencies of vulnerabilities, for example this one at the front page:

It is also possible to drill down further based on version numbers, type of application, manufacturer, etc. I tested it for OAS, and easily found cool data, among others you could list up all OAS vulnerabilities per year and per type:

I think I’m going to continue using this. Nice job!

Posted by & filed under /dev/random, Security News.

Interresting story from Symantec about a new critical 0-day vulnerability that affects IE6-8. The interresting part about it is really that Symantec was able to capture the command sequence of a live hacker in action, performing a sequence of commands at the victim computer through encrypted .gif files. Nice find.

Posted by & filed under Hacks.

This quick guide will show you how to create gnome menus in Ubuntu that can be shared between multiple users – handy if you want to create a default menu structure that will be loaded for each user on a multiuser system. The launchers created will be installed for all users on the system.

I’ve used Ubuntu 10.10 Maverick in the following, but the guide should be working on other versions and distros (that use gnome and xdg-desktop-menu) also.

The Ubuntu Gnome menu

The menu consists of a tree-like structure. The structure is automatically populated when you install programs through apt or synaptic:

Gnome menu structure

Since I wanted to create a sample menu with pentest tools, I’ll add the popular network scanning tool nmap to a folder structure under the main menu:


The final menu will look like this:

To create the structure we’re going to install the application, create launcher file for it, and then add the launcher to the menu using xdg-desktop-menu.

Intalling the application

To install the tool we need, let’s issue the following command:

sudo apt-get install nmap

Creating the launcher

The easiest way to create the launcher is to create it using the Create Launcher option in Gnome. But first, let’s make sure that we are able to share the launcher with all the other users on the machine by typing the following in a terminal:

sudo mkdir /usr/local/share/applications

It is crucial that the above folder is created, the following commands will strangely not work if this directory doesn’t exist (it will instead install the nmap.desktop file to /usr/share/applications, which did not update the menu on my system).

Create a shell script to launch nmap in the Terminal

You can skip this step if you’re following this guide just to install a GUI applicaiton to the menu and share it between users.

To be able to execute nmap in a shell when we select it in the menu (BackTrack style), we must create a small helper script to prevent the terminal from shutting down the moment the nmap command terminates. . The only thing the following bash script does is exactly this:

exec $SHELL[/bash]

We’ll put this script in a script catalog just below where the launcher will be stored:

cd /usr/local/share/applications
sudo mkdir script
sudo sh -c "echo -e '#!/bin/bash\n/usr/bin/nmap\nexec $SHELL' \
> script/"
sudo chmod +x script/

Use Create Launcher to, uhm… create the launcher

To create the launcher, we simply use the Create Launcher (duh!) option in Ubuntu; right click on the desktop, and select Create Launcher:

Create Launcher menu (right click on desktop)

In the following dialog, enter the name, path to the nmap shell script (or the binary/script of the application you want to launch) and a comment like below:

Check that the launcher works by double-clicking it.

Creating the menu

Finally, to create the menu entry, enter the following command in a terminal window:

sudo xdg-desktop-menu install --novendor --mode system \

This should create a new entry in your menu under the Other category, and the link should bring up nmap in a Terminal window when clicked. This menu entry should also show up in all other user’s menus. Result:

Nmap output BT4-style

Posted by & filed under /dev/random, Hacking & Pentesting, Tools & Methodology.

I’ve been using the nmap NSE scripts a lot recently in pentests, and i find the results from many of the scripts invaluable, like smb-enum-users. This script uses some ninja tricks to make the machines spill out all their users using null sessions.

Although the scripts are great, the nmap output format to stdout is not very efficient in terms of building user lists that can be utilized in further attacks, especially if you’re targetting a domain with thousands of users. Nmap of course also supports XML output via the -oX and -oA options, but I still could not find a parser that would extract the users from the output. Weird. So I wrote one myself.

The result is in code (Python 3) below, I’ve called it pwnmaps (Parse/wrestle nmap scripts). It basically parses the NSE script output and outputs a list of users separated by linefeeds. Not a downright breakthrough in advanced coding, but it does the job. Maybe I’ll extend it modular wise to be able to support other output as well in the future.

#!/usr/bin/env python
Parse/Wrestle nmap Scripts

Parses nmap XML NSE script smb-enum-users and prints the users found to stdout.
Should be handy for generating user lists for further (brute force) attacks, to
generate such a list one could for example use sort to make sure we only have
unique user names: $ sort --unique output.txt > unique-users.txt
Created on Oct 9, 2010
@author: Carsten Maartmann-Moe
import xml.dom.minidom
# import locale
import sys
import getopt

# language, output_encoding = locale.getdefaultlocale()
verbose = False

def main(argv):
    doc = ""
        opts, args = getopt.getopt(argv, "hv", ["help", "verbose"])
    except getopt.GetoptError as err:
    for opt, arg in opts:
        if opt in ("-h", "--help"):
        elif opt in ("-v", "--verbose"):
            global verbose
            verbose = True

    if len(args) < 1: # Print usage if no arguments are given

    input_files = args # The remainder of arguments are treated like input files
    for i in input_files:
            doc = xml.dom.minidom.parse(i)
            print("[!] Invalid XML, giving up...")

def parse_nmap(doc):
    usernames = []

    for host in doc.getElementsByTagName("host"):
        ip = name = output = ""

        # Get host IPv4 address (and potentially IPv6 and mac as well)
        addresses = host.getElementsByTagName("address")
        for address in addresses:
            ip = address.getAttribute("addr")

        # Get host name
        hostnames = host.getElementsByTagName("hostname")
        for hostname in hostnames:
            name = hostname.getAttribute("name")

        scripts = host.getElementsByTagName("script")
        for script in scripts:
            output = script.getAttribute("output") #.encode(output_encoding)
            usernames = output.split(',')

            print("[*] Users harvested from " + ip + " (" + name + "):")

        for username in usernames:

def usage():
    print("""Usage: ./ [OPTIONS] results.xml

The input file should be generated using nmap with a similar syntax:
nmap --script=smb-enum-users -oX results.xml

    -h/--help:       Displays this message
    -v/--verbose:    Verbose mode""")

if __name__ == "__main__":

To generate input to pwnmap, scan with nmap, use the NSE script smb-enum-users and output to XML:

$ nmap -oX test.xml --script=smb-enum-users

Starting Nmap 5.00 ( ) at 2010-10-09 16:11 CEST
Interesting ports on
Not shown: 984 closed ports
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
389/tcp  open  ldap
445/tcp  open  microsoft-ds

Host script results:
|  smb-enum-users:
|_ EXAMPLE\Administrator, EXAMPLE\alice, EXAMPLE\bob, EXAMPLE\Cert Publishers, EXAMPLE\charlie, EXAMPLE\DHCP Administrators, EXAMPLE\DHCP Users, EXAMPLE\DnsAdmins, EXAMPLE\DnsUpdateProxy, EXAMPLE\Domain Admins, EXAMPLE\Domain Computers, EXAMPLE\Domain Controllers, EXAMPLE\Domain Guests, EXAMPLE\Domain Users, EXAMPLE\Enterprise Admins, EXAMPLE\EXAMPLE01$, EXAMPLE\EXAMPLE02$, EXAMPLE\EXAMPLE03$, EXAMPLE\EXAMPLE04$, EXAMPLE\EXAMPLEDC$, EXAMPLE\Group Policy Creator Owners, EXAMPLE\Guest, EXAMPLE\HelpServicesGroup, EXAMPLE\krbtgt, EXAMPLE\Schema Admins, EXAMPLE\SUPPORT_388945a0, EXAMPLE\TelnetClients, EXAMPLE\xena, EXAMPLE\yasir

Nmap done: 1 IP address (1 host up) scanned in 1.51 seconds

To parse the output with pwnmap (verbose switch -v used in the following example):

$ ./ -v test.xml
[*] Users harvested from ():
EXAMPLE\Cert Publishers
EXAMPLE\DHCP Administrators
EXAMPLE\Domain Admins
EXAMPLE\Domain Computers
EXAMPLE\Domain Controllers
EXAMPLE\Domain Guests
EXAMPLE\Domain Users
EXAMPLE\Enterprise Admins
EXAMPLE\Group Policy Creator Owners
EXAMPLE\Schema Admins