OpenBSD IPSEC supposedly backdoored by the FBI

According to an e-mail from Theo de Raadt(founder and current leader of the OpenBSD project) to the openbsd-tech mailing list, the IPSEC stack could have been backdoored by some open source developers(on the FBI payroll) taking part in the project in its early days. The supposition comes out of an e-mail he received from an old friend or so. Here goes the original e-mail:

List: openbsd-tech

Subject: Allegations regarding OpenBSD IPSEC

From: Theo de Raadt <deraadt () cvs ! openbsd ! org>

Date: 2010-12-14 22:24:39

Message-ID: 201012142224.oBEMOdWM031222 () cvs ! openbsd ! org

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 <Gregory.Perry@GoVirtual.tv>
To: "deraadt@openbsd.org" <deraadt@openbsd.org>
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: <8D3222F9EB68474DA381831A120B1023019AC034@mbx021-e2-nj-5.
exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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
technologies.

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)

http://www.facebook.com/GregoryVPerry
http://www.facebook.com/GoVirtual

(archived e-mail at marc.info)

 

If this turns out to be true then…that’s really insane.

 

ProFTPD pwned and backdoored

On 29 novemeber the server at ftp.proftpd.org which is hosting the official ProFTPD download packages and source for all other mirrors was compromised and a backdoor has been planted into the source. This seems to be the case only for the 1.3.3c version of ProFTPD.

Original quote from protfpd.org:

ftp.proftpd.org compromised

[01/Dec/2010]The ProFTPD Project team is sorry to announce that the Project’s main FTP server, as well as all of the mirror servers, have carried compromised versions of the ProFTPD 1.3.3c source code, from the November 28 2010 to December 2 2010. All users who run versions of ProFTPD which have been downloaded and compiled in this time window are strongly advised to check their systems for security compromises and install unmodified versions of ProFTPD.

To verify the integrity of your source files, use the PGP signatures which can be found here as well as on the FTP servers.

The source code in CVS was not affected.

Thus if you grabbed 1.3.3c lately and set it up on your system you’d better act upon it. More info on the subject and pointers on what too look for can be find here.

 

Energizer battery charger software contains backdoor

The United States Computer Emergency Response Team (US-CERT) has warned that the software included in the Energizer DUO USB battery charger contains a backdoor that allows unauthorized remote system access.

In an advisory, the US-CERT warned that he installer for the Energizer DUO software places the file UsbCharger.dll in the application’s directory and Arucer.dll in the Windows system32 directory.

When the Energizer UsbCharger software executes, it utilizes the UsbCharger.dll component for providing USB communication capabilities. UsbCharger.dll executes Arucer.dll via the Windows rundll32.exe mechanism, and it also configures Arucer.dll to execute automatically when Windows starts by creating an entry in the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry key.

US-CERT said that Arucer.dll is a backdoor that allows unauthorized remote system access via accepting connections on 7777/tcp.

You can read the bulletin from US-CERT here or a detailed report from symantec here.

Next time we will probably find a backdoor in the batteries themselves by alternating power to wherever you plug those batteries and make the device spit up bits of secret keys. 😆