christophe at vandeplas.com

Quote H D Moore:

Austin, Texas, November 19th, 2008 -- The Metasploit Project announced today the free, world-wide availability of version 3.2 of their exploit development and attack framework. The latest version is provided under a true open source software license (BSD) and is backed by a community-based development team.

Get your update here, and don't forget to read the release notes.

e-land meldt dat Symantec een Europees ondezoek gedaan heeft betreffende de IT-beveiliging van de KMOs.

De verbazende conclusie luidt:

Belgische bedrijven scoren hier vrij goed op.

De kwaliteit van de argumenten waarom onze KMOs goed bezig zijn vind ik wel droevig:

Zo beschikken ruim vier op de tien kmo’s in België over een eigen IT-manager, wiens taak en verantwoordelijkheid het is om zich om computers en bijhorende beveiliging te bekommeren. Daarnaast doen Belgische kmo’s meer dan in de buurlanden een beroep op een externe expert die mee de IT-beveiliging in goede banen moet leiden. Ook inzake de uitrusting zelf, lijken de Belgische kmo’s goed te zitten. Zowat drie op de vier beschikken over "de vier beveiligingsvormen die door experts als de belangrijkste worden beschouwd: antivirus, antispam, firewall en back-ups".

Is de aanwezigheid van een anti-X product en een firewall indicator van de kwaliteit van IT security? Zijn dat geen standaard elementen die deze tijden ook maar een noodzaak zijn?

Enkele vragen die bij mij direct opkomen zijn: a) wat is de kwaliteit/efficiëntie van deze producten, b) zijn deze wel up-to-date?, c) hoe zijn deze geconfigureerd? d) zijn de backups getest?, e) waar worden de backups bijgehouden? (brand, diefstal,...), f) is er een disaster recovery plan?

En dan denk ik nog niet aan de andere zaken zoals de g) opleiding van de eindgebruiker, h) paswoord en account policy, i) confidentialiteit, j) beschikbaarheid, ...

Ik kon spijtig genoeg het origineel rapport niet terugvinden...

(warning rant ahead, after 20 minutes searching for that contact information, and still partially clueless)

Why is it that corporations don't publish their webmaster-contact information on their website?
How are we, security people, expected to contact them when we discover that their site is vulnerable to one of the OWASP Top 10 web-vulnerabilities?

Update: Finally I found it, yeuy.

Some time ago Check Point http://www.checkpoint.com/press/2008/demovpn-1ve150908.html ">announced on VMWorld they were launching VE (Virtual Edition), their software for VMware ESX and ESXi.
Yesterday I had the opportunity to go to a Technical Update Session of Check Point. Perfect place to ask more details over this new VE.

Unfortunately I misunderstood the design of Check Point VE which lead to a great disappointment.
In marketing terms they describe it as :"It enables you to segregate virtual systems from each other as well as from external threats."

Usually they draw you this drawing:

Analyzing this drawing, together with their explanation you understand the Firewall is really in between the hosts and enables you to filter all incoming and outgoing traffic from the virtual machines.
A question I asked was what would happen when a virtual machine is being VMotion-ned to another ESX. "Good question ! Well, it's simply VMnet that handles this." is the answer you get. And then you suddenly realize their drawing is not really what you get with CPVE.

 

In the reality they 'forgot' to draw the virtual switch that interconnects all the VM's. This simple switch changes the whole story as direct communication is possible between the hosts in the same subnet. CPVE plays exactly the same role as another firewall could do, routing and filtering the packets between networks. It will not firewall your individual virtual machines, except if you put them in different subnets.

 

In human-readable-forms Check Point's VE is "just the VPN-1 that runs in a VM". (and is officially supported by CP) Nothing more, nothing less.

 

The good news is that VMware opened up their API and Check Point says they are starting to work on implementing the first drawing I made, where the VE is between the hosts, and not next to them. But don't expect it to soon...

Warning: Rant ahead

Six months ago I discovered a huge vulnerability in the Watchguard SSL-VPN implementation. The consequences are quite important as, if exploited correctly, it is possible to perform arbitrary code execution on the victims machine.

For six months now I've been in contact with 'someone' from the Watchguard security team. He has promised me many times a date when the fix will be released. I'm still waiting for it...
In his last mail he said the fix was committed to the beta-team and I was going to be added to the beta-testers-list so I could try it out and play around with it. I'm still waiting to be added...

To be honest, I start to feel rather annoyed about their attitude.

• I informed them privately of two important vulnerabilities.
• I accepted to keep the details about the fixed problem confidential as courtesy.
• I keep waiting for 6 months with many beautiful promises about a fix and access to the beta.
• I don't ask any money for these reports.

For ethical reasons I will not publish the full disclosure without the fix. But next time I find a leak in their products I might start thinking about selling it to the highest bidder.

PS: This is not related to this other problem that has already been fixed.

Edit: Mark told me another way, that gives less a blackmailing-feeling. It's kindly requesting the company to make a donation to a charity before giving them the information about the vulnerability in private. I think I'll do that next time.

Edit 2: Watchguard released a new version v10.2.3 fixing this huge problem. Quote Release Notes: The Mobile VPN with SSL client and gateway now protect against "Man in the Middle" attacks. The Mobile VPN with SSL gateway generates a self-signed x.509 certificate when an IP address is assigned to the external interface of the Firebox. This certificate is presented by the gateway the first time a v10.2.3 client connects. Because the certificate is self-signed, a warning message about an “un-trusted” certificate is presented to the user the first time they connect to the Firebox. The user is given the option to confirm the certificate as trusted and save the certificate locally. Accepting the certificate as “trusted” allows the SSL client to warn the user if the certificate changes to alert the user of a possible Man in the Middle attack. [27304].

While cleaning up my computer I found this advisory lying around.
It was discovered around June 2005 while studying at Groep T. At that time we didn't really know the XSS principles so we didn't report it as such, but as a simple cookie vulnerability.

IPswitch didn't fix the problems as they were 'working on a complete new version'. We did report it to cert.org.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Security Advisory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  Severity: High
     Title: ipswitch iMail webmail: cookie password vulnerability
      Date: June 08, 2005
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Credits
=======

Peter Bulckens
Christophe Vandeplas


Description
===========

Due to the plain text storage of the user password in a cookie an
attacker can fetch the password using client-side scripting methods like
javascript contained in the html of the mail.
This vulnerability can be classed as high severity due to the fact that
the exploit can be performed without the victim noticing it.


Proof of Concept
================
--[ Structure Description

The malicious mail should not contain any  nor  tag, but
should be declared as a text/html content type.

To circumvent the internal scripting protection of the webmail the
script should not be embedded in the email, an external script should be
used instead.

When hovering over the document, the password will popup on the screen.
If the source is changed adequately the script could call an url with
the username and password as arguments to add the data into the
attacker's password database, without the victim noticing it.

--[ Email Source

Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: ipswitch iMail webmail: cookie password vulnerability

<script type="text/javascript"
src="http://www.netspade.com/articles/javascript/cookies.js"></script>
<div href="#" onmouseover="alert(getCookie('myICalUserName') + ' '
+getCookie('myICalPassword'))">
&nbsp; <br>
Vulnerability discovered by Peter Bulckens &
Christophe Vandeplas&nbsp; <br>
&nbsp; <br>
</div>

If you're busy with networking or security the following paper is certainly a good lecture. Understanding the protocols can lead to finding possible attacks. Reading about possible attacks can sometimes motivate people to learn more about the protocols...

Exploiting Tomorrow's Internet Today: Penetration testing with IPv6

This paper illustrates how IPv6-enabled systems with link-local and auto-configured addresses can be compromised using existing security tools. While most of the techniques described can apply to "real" IPv6 networks, the focus of this paper is to target IPv6-enabled systems on the local network.

This paper is written by H D Moore, he's the main author behind Metasploit and was invited at FOSDEM in 2007.