NDR welcome banner

We were invited to give a workshop about advanced technical investigation techniques for the attending journalists, which turned out to be quite a success. We tried to cover the topic not only from a journalist’s view, but also from an attacker’s perspective (lacking the legal and ethical constraints a journalist should have), because we felt it is important to show to people not only what they can do, but what possibilities the other side has, too.

The slides, including a link collection, can be downloaded from our website under Publications.

Thanks to the organisers for the event. We met many interesting people and generally had a very positive feedback to our workshop. We hope to do another one next year!

Update: Heise has an article where a large part is about our workshop: Netzwerk Recherche: Pentestereien für Journalisten

http://www.redteam-pentesting.de/publications/jboss

This new informational page also contains the now publicly released scripts used in the older paper “Bridging the Gap between the Enterprise and You – or – Who’s the JBoss now?”, which is also available there.

Abstract

The JBoss Application Server (JBoss AS) is a widely used, open source Java application server. It is part of the JBoss Enterprise Middleware Suite (JEMS) and often used in large enterprise installations. Because of the high modularity and versatility of this software solution, which leads to a high complexity, the JBoss AS is a rewarding target for attackers in enterprise networks. This paper adds to the whitepaper “Bridging the Gap between the Enterprise and You – or – Who’s the JBoss now?” released by RedTeam Pentesting. It shows how to use the DeploymentFileRepository MBean to deploy a Web ARchive (WAR) without the need of outbound connections being allowed for the JBoss AS. It also describes how this can be used in conjunction with CSRF to attack a JBoss AS with a protected JMX Console.

To make the JBoss research complete, I sent one new and two updated Metasploit modules to their mailing list. The updated modules improve on the already existing jboss_deploymentfilerepository.rb and jboss_maindeployer exploits. The new module jboss_bshdeployer.rb adds an exploit to install a WAR file via the BeanShellDeployer MBean's createScriptDeployment() method. If they do not make it to the main repository, you can always download them from the list post.

For us, this means that in almost all web application pentests, we find XSS vulnerabilities to be documented. And there’s one thing we always tell people when we present our results: If possible, don’t code your own filter, but use a well-tested XSS prevention library.

Now this should be a no-brainer, but surprisingly often you find self-written code in web applications that’s supposed to defend against XSS. And it fails. Because XSS filtering is hard, which people still tend to disbelieve. All you need to do is to check for those angle brackets and single ticks, right? Well, have a look at the much cited XSS cheat sheet if you don’t believe how hard XSS filtering can really be.

Now I don’t want to go into the details of XSS filtering, the OWASP XSS Prevention Cheat Sheet already has a very nice overview of what to pay attention to. Point 1.6 is what we also say though: You need a security encoding library. OWASP is recommending their own ESAPI project, but there are of course also other libraries for different languages (like e.g. HTML Purifier). Today’s web application frameworks oftentimes implement XSS prevention measures, so have a look at your favourite framework and if there’s already some builtin XSS mitigation functionality.

The next thing, and that’s also explained in the cheat sheet, is the differentiation between input validation and output encoding and why you preferably should use both. Many XSS attacks will already be prevented by simply encoding your output properly.

Also, always have an eye open for new developments. HTML5 is around the corner and people are already working on the HTML5 Security Cheat Sheet. Don’t get lazy because you added a filtering library to your code. It might not work against the newest attacks.

It doesn’t say so on the website, but according to the organisers the talk is open for everyone. So, if you happen to be in Bochum that day, make sure to join us at the RUB, we’d be happy to see you there.

Now, the problem with documentation is twofold: First of all, there has to exist some kind of documentation. I’m a Ruby coder, believe me, I know all about missing docs… The next problem is: It has to be accurate. If what is written in the documentation is not true, then you have a problem. Sometimes, documentation is just sloppy in whatever it describes. Sometimes, it is plain wrong.

Inaccurate documentation may be only a nuisance when you try to find out why the config option you set for coloured log output doesn’t do anything, but it can become outright dangerous when it comes to security related documentation. I want to show you what I mean by example. Let’s have a look at… the Typo3 documentation.

Typo3 provides in its core documentation the “Typo3 Coding Guidelines”. To follow them is mandatory for core developers and contributers to the Typo3 core, as the document states. To be fair from the start: The linked documentation is for version 4.1.0 and not directly linked from the website anymore. If you click on the documentation link on their website, you get directed to the current documentation for version 4.3.2. The link is, however, the first one you get with a Google search for “typo3 updatequery”, which may not be such an unusual search request when you want to know how the updatequery() function works. As you may have guessed, the function executes a SQL UPDATE and is part of Typo3’s Database Abstraction Layer (DBAL). The new documentation for 4.3.2 only contains this sentence:

The TYPO3 database should be always accessed through the use of $GLOBALS['TYPO3_DB']. This is the instance of t3lib_db class from t3lib/class.t3lib_db.php.

That said, let me quote the relevant parts from section 1.4 “Database connectivity and DBAL” from the old version 4.1.0:

TYPO3 has been designed to use MySQL from the beginning. With TYPO3 3.6.0 a database wrapper class has been introduced in all of the core and default global extensions. This means that implementation of various Database Abstraction Layers (DBAL) is now possible.
[...]
The wrapper class is called “t3lib_DB” and is instantiated globally as $TYPO3_DB. The class contains three sections of functions
[...]
2. Query building functions: Instead of constructing SELECT, UPDATE, INSERT and DELETE statements directly you can use API functions in the wrapper class for this. This requires a bit more re-design from you but you will get better security in your scripts (prevents SQL injection for UPDATE/INSERT at least) and is step-2 towards database abstraction support in your extensions!

As a developer reading this part of the documentation, I might just think “great, I don’t have to worry about SQL Injection in my UPDATE and INSERT queries if I use the DBAL. How convenient!”. As a pentester, you of course immediately get suspicious. Especially if you searched for “Typo3 prepared statements” before and know that Typo3 doesn’t support prepared statements in its DBAL (yet).

Ok, let’s have a look at the source code. The following sources are from version 4.3.2 and haven’t changed in the relevant parts since 4.1.0. The function UPDATEquery() is defined in t3lib/class.t3lib_db.php:

/**
 * Creates an UPDATE SQL-statement for $table where $where-clause (typ. 'uid=...')
 * from the array with field/value pairs $fields_values.
 * Usage count/core: 6
 *
 * @param       string          See exec_UPDATEquery()
 * @param       string          See exec_UPDATEquery()
 * @param       array           See exec_UPDATEquery()
 * @param       array           See fullQuoteArray()
 * @return      string          Full SQL query for UPDATE (unless  $fields_values
 * does not contain any elements in which case it will be false)
 */
function UPDATEquery($table,$where,$fields_values,$no_quote_fields=FALSE) {
  // Table and fieldnames should be "SQL-injection-safe" when supplied to this
  // function (contrary to values in the arrays which may be insecure).

Wait a minute. Table- and fieldnames should be SQL injection safe? Like in, before I supply them to UPDATEquery()? Why, that’s useful information! Let’s see the body of the function to verify that table and fieldnames are not sanitised:

  if (is_string($where))    {
    if (is_array($fields_values) && count($fields_values))  {

      // quote and escape values
      $nArr = $this->fullQuoteArray($fields_values,$table,$no_quote_fields);

Here, the $fields_values array get escaped. fullQuoteArray() uses Typo3’s fullQuoteStr() internally, which in turn uses mysql_real_escape() to escape a value:

function fullQuoteArray($arr, $table, $noQuote=FALSE)   {
[...]
  foreach($arr as $k => $v)       {
    if ($noQuote===FALSE || !in_array($k,$noQuote))     {
      $arr[$k] = $this->fullQuoteStr($v, $table);
    }
  }
  return $arr;
}

Ok. As we can see, the field names indeed do not get escaped, only the field values. What about $table and $where?

      $fields = array();
      foreach ($nArr as $k => $v) {
        $fields[] = $k.'='.$v;
      }

      // Build query:
      $query = 'UPDATE ' . $table . ' SET ' . implode(',', $fields) .
        (strlen($where) > 0 ? ' WHERE ' . $where : '');

      // Return query:
      if ($this->debugOutput || $this->store_lastBuiltQuery) {
        $this->debug_lastBuiltQuery = $query;
      }
      return $query;
[...]
}

Apparently, the $table and $fields variables are inserted into the query without any further sanitisation. So the comment is right, you have to check for SQL injections in the table- and fieldnames. But, the values in the $where variable are also inserted verbatim! So there’s another unsanitised variable, not even mentioned in the comment.

As you can see, blindly trusting the documentation may lead to dangerous behaviour, like not santising all your inputs in this case. Of course, you can’t check the source code of every security relevant functionality yourself, even if you have access to it. Just have a healthy dose of scepticism if you find a statement like the one in the old Typo3 coding guidelines without any further explanation.

I wrote a similar blog post way back in 2006 titled “Reading the fine Manual”, where we saw that the PHP ereg*() functions are not binary safe. In that case however, the documentation did tell the truth :).

Client: “You will have to work on site for this job. The data you’re gonna work with is of course highly sensitive and confidential. We cannot risk any of it to leave the company premises.”

Ok, so at this point, you usually prepare yourself to disillusion the client about how secure large company networks usually are and through how many insecure systems their data travels daily (including the Internet). But this time, they had a solution to the problem:

Client: “Ok, how about this: We take an image of your hard drive when you enter the building. When you leave in the evening, we take another image and see what data changed. This way, we know if any sensitive data leaves the company.”

No further questions. On the bright side, it didn’t take long to convince them that this wouldn’t really solve the problem.

The moral of the story: If you hire pentesters to deliberatly hack your network and search for security vulnerabilities, make sure that you trust them. Otherwise, search for another company. This is one of the reasons why we always have a personal meeting even before we send you a quote. We want you to know who we are and that you can entrust us with the highly sensitive task of pentesting your network. All our pentesters are listed on our homepage, something you usually do not see with other companies. You may want to read this older blog post about pentesting as a me-too-business too, a topic also relevant when thinking about trust.

“Well, the system says an ID card is not required. Let me check again. Nope, the option’s not checked. But now that you mention it… we had a software upgrade last week. I guess the config just got lost in the process.”

So remember: When doing a software update in a high security area, back up your config files and compare them with the updated configuration. You may spare yourself the unpleasant surprise of having some pentesters notice the lowered security barrier. Or much worse, have a real incident.

“Emulationsbasiertes Entpacken von laufzeitgepackten Schadprogrammen und darüber hinaus”

He’ll show you his project “Pandora’s Bochs”, based on the popular Bochs IA-32 Emulator. The talk will be on February 9th, the first workshop day, at 4:15pm. Be aware that the location changed, it now takes place at the Grand Elysée Hamburg.

We are happy to have been accepted for a talk the fourth time in a row, the DFN-CERT workshop it’s always nice to be at the workshop and present some of our research. Be sure to check out the program, there’ll be other interesting talks, too.

To give you a little reminder: Always check for

• http://www.example.com/jmx-console
• http://www.example.com/web-console
• http://www.example.com/web-console/Invoker
• http://www.example.com/invoker/JMXInvokerServlet

and any open JBoss Remoting / RMI ports. See the paper for details.

So, if you own a copy of Acunetix WVS, there are no excuses anymore that you accidentally missed an open JMX Invoker ;)

• RT-SA-2010-001: Insecure handling of long URLs
• RT-SA-2010-002: Insecure handling of NMEA-data
• RT-SA-2010-003: Faulty implementation of HTTP Digest Authentication

All vulnerabilities have been fixed by the vendor in version 1.4.0.8, so if you happen to run this software, please update as soon as possible.

This is one of the questions you get asked surprisingly often when you explain to people what you do for a living (and the answer is no: we don’t proactively hack companies and then sell our service. That’s what the mafia does). Although pentesting is a term more and more established in IT, the art of finding security vulnerabilities and actively exploiting them to verify the practical impact is still regarded as a rather shady work by many. There’s at least the presumption that all pentesters must’ve been blackhats in their past, as the skills required to do this job can only be acquired hanging out in the dark corners of the Internet, learning from 1337 h4X0rs who hack the gibson on a daily basis. Ok, frankly, you really don’t learn this stuff just by attending classes at university, but I think you get the point.

I guess this may be one of the reasons why from time to time, business offers of a, let’s say, rather questionable kind arrive at our doors. Security experts are in high demand it seems, on both sides of the law.

When you explain why you absolutely need to know what systems/networks are in scope (so we don’t accidentally attack an IP from a range close by, for example), many people drop a sentence about how interesting it would be to know what the competition is doing. Everyone says it with a wink and smile (and, one time, the promise of a small island in return), but sometimes, you’re not quite sure if it would really be out of the question. Competition’s tough these days.

At the other end of the spectrum, there are the phone calls asking if you also work outside of Germany (yes, we do) and what skillsets your “hackers” have (hmm, they’re like, good at what they do?). After some more inquiries, it turned out that this was not meant to be a pentest of a normal company network… suffice to say, we thankfully declined.

I’m being rather vague here to protect the innocent (i.e. me, so I don’t wake up next to this), but just to make this clear again: Either you’re a legit company who wants to know about potential security problems in your own stuff, or we can’t work for you. If you are a legit company in need of a pentest, the contact information’s on the website :).

http://www.redteam-pentesting.de/publications/tls-renegotiation

RedTeam wishes you all a Merry Christmas. Be sure not to use the code for something naughty, Santa will know ;).

Like many others, we have spent some time on that vulnerability. Unfortunately, the original Proof-of-Concept code is written in C and cumbersome to use. So Lutz decided to write our own. This PoC is written in Python and is – hopefully – platform independent. It works great for doing Man-in-the-Middle attacks against HTTPS-secured websites. We already used the code in our pentests and demonstrated to our clients what may happen if SSL/TLS renegotiation is enabled.

We are going to release the code in a couple of days on our website, so stay tuned and check the news and this blog for updates.

The paper should have been released a lot earlier, but as usual, other work took over. But better late than never.

The paper can be found in our “Publications” section as usual. To our knowledge, this is currently the only paper dealing with the JBoss AS and its Invokers from an attacker’s perspective.

http://www.redteam-pentesting.de/en/publications/MitM-chipTAN-comfort

Have fun.

http://www.redteam-pentesting.de/de/publications/MitM-chipTAN-comfort

You’ll find our press release (in German) and a paper (also in German) there, giving you all the details about the three attacks we came up with. I’m sorry that I didn’t get the English version of the paper ready on time, it’ll follow soon, I’ll announce the release here and on our website.

What we showed in the German TV magazine SAT1 Planetopia is one possible man-in-the-middle attack against chipTAN comfort. You can watch the video on their website if you haven’t seen it yet.

Sunday, 22. November 2009, SAT1 Planetopia: Gefährliches Onlinebanking (Dangerous Online Banking)

Online banking is still a hot topic, with all the new systems cropping up after the traditional PIN/TAN and the more recent PIN/iTAN (indexed TAN) systems.

We already showed in 2005 that Man-in-the-Middle attacks on iTAN-based systems are possible and predicted that we will start to see MitM attacks as soon as the majority of the banks switch to iTAN. Which promptly happened (German, second link is a PDF).

Today, systems like chipTAN/chipTAN comfort or sm@rtTAN plus/sm@rtTAN optic try to improve on iTAN by providing a little device which theoretically shows you at least part of the transfer data you’re about to acknowledge on its built-in screen. For a simple cash transfer, this is normally the amount of money and the account number you’re going to send the money to.

The idea behind this procedure is that you authorise transfers using a trusted device an attacker can’t compromise (unlike your computer). Sounds familiar? Yep, HBCI/FinTS with a card reader send a greeting from the past.

This month we were asked by Planetopia, a German TV magazine, if we could show again how to break iTAN systems and to check for potential flaws in the chipTAN comfort system. Sure we could :). And we got interesting results. So please honour the two coding sprees late into the night and the long day filming everything and watch the show ;).

We will also publish the full details about all attacks on Monday, 23rd Nov. 2009. They will be available on our website under “Publications”.

Much happened this year, apart from the usual exchange of new ideas and gossip from the IT security world. Claus and Alex won Eric Filiol’s Crypto Challenge, a task not too easy. Lutz made second place in the Reverse Engineering Challenge. Actually, he was first in solving it using his Pandora’s Bochs, but to be fair to the others he agreed to additionally solve the challenge manually.

I also gave a short interview for RTL Télé Lëtzebuerg as part of their news item about the hack.lu. The news item is in Luxembourgish, but my part is in German. If you speak German, you’ll understand the Luxembourgish fairly well, though. You can watch it on their website at RTL.lu.

Many thanks again to all the organisers for the fantastic job they’ve done. hack.lu definitely stays to be one of our favourite conferences. We’re already looking forward to next year’s edition!

We’re all set and ready to go. We are also very curious about the further unravelling of the Crypto Challenge. We’ll of course stay close on the terrorist’s heels, as we already decrypted the first message :).

See you in Luxembourg!

Expert configuration admin gender

For those with only limited German language knowledge (or a textmode-only RSS feed reader or browser): It reads

Admin Gender

• unknown
• male
• female
• geek

Sometimes, there’s just nothing more to say. It’s also a really nice touch to add this in the “expert configuration” area. Like they wanted to say “hey, nobody’s using the expert configuration anyway. Let’s put an easter egg there!”

Sorry, but the semester break of the college student developing the security toolkit is over, so there’s some delay.

Timo also stitched together a nice 360° view of the location:

BruCON Panorama (click for large version)

We of course participated in the BruCON CTF “The Hex Factor” (together with two (in)famous non-RedTeam members from Aachen who also attended the conference and are well known to us) and made second place. Congrats again to team virtuax++ for making a perfect score and overtaking us in the last hours of the game. We were faster in solving the hacking challenges, but presumably lost points due to spelling errors in our answers to the trivia questions (I know. Don’t rub it in). Playing was much fun, thanks again to the Hex Factor organisers for the time and effort they put into this.

So now we are waiting for the second edition of BruCON next year and hope to see many participants again at the upcoming hack.lu in Luxembourg on the 28th-30th of October!

But on the bright side, a good pentest also lives from the creativity and outside-the-box thinking of the pentesters. We all know that finding the moonshine 0day is where the fun is, right? So never underestimate the importance of being creative either. The bad guys get surprisingly inventive when there’s enough money in it, and so should you (I’m talking about the getting creative part, not the illegal money making).

The only problem is, being creative is hard sometimes. There are times where you just don’t have any good ideas on how to approach something from a different angle, where you are stuck in a certain mindset. One advice when this happens is: Search for the standard issues in the time you can’t wrap your mind around other things. There’s always no-brainer stuff that has to be done. Another thing you can do is to start documenting everything you already found. You have to do it anyway, so start collecting all your notes and logs (you have detailed notes and logs about what you’ve already done, haven’t you?) and document the details.

The above will help you when you temporarily run out of ideas what to do next, but won’t solve the problem if you’ve already covered the standard things and your documentation is nicely done and you still have no idea how to proceed. This is where you should remember the greatest resource of all: your colleagues and fellow pentesters. It implies of course that you’re not working alone (e.g. as a freelancer). Talk things through with them. Get new ideas about your problem. It’s amazing how much it helps to just give somebody a detailed description about what you’re trying to do. Many times, you get new ideas while still talking. Your colleagues may also have deeper insights into some areas than you. IT (security) is such a complex field, nobody can master it all, everyone’s specialised in one way or the other.

At RedTeam, we wanted to leverage the benefits of teamwork from the beginning, so for us the consequence is: We always work in a team of (at least) three pentesters. You normally can’t hire only one of us. This of course doesn’t mean that we’re just tripling the cost of every pentest. The team will naturally work faster and therefore needs less days than a single pentester. As far as I see it, our day-to-day work proves us right. We’ve really made positive experiences with working in a team, I can think of numerous occasions where I would’ve been stuck if it weren’t for one of the other’s saying: “Have you already tried to…”.

Contact Person: teddybaer

For the visually impaired or those using a text-only RSS feed reader like me: Apparently, the contact person we had at Victorvox goes by the name “teddybaer”. At least the invoice says so. And yes, “had”. This is old, so don’t get any silly ideas ;).

What more can I say, except: Tiggerific!

BTW, on a completely unrelated note: The early bird for hack.lu ends on September 1st, so go and register. Now!

• RT-SA-2009-005: Papoo CMS: Authenticated Arbitrary Code Execution

This one’s nice because you can do your exploit development in Gimp. The idea is to plant your exploit code (in this case, PHP code) in a file with a valid GIF header and the file extension .php. Papoo CMS only sees the valid GIF header and let’s the user upload the file, as it is deemed harmless. The web server on the other hand will parse the file as PHP code because of the file extension -> instant remote code execution. The PoC in the advisory only creates a file with a minimal GIF header content, but if you need a valid GIF, just add the PHP code to the GIF comment section. You’ll be limited to 240 characters though.

Adding PHP code to a GIF comment in Gimp

The idea of embedding code in GIFs is not new but still works surprisingly well. So remember: always make sure that you look at both the header and the file extension when dealing with untrusted files (at least if your web server decides by file extension how to parse files).

BTW, another neat exploit along the lines of the above is the GIFAR attack which was presented at last year’s BlackHat.

[Update]
HD Moore adds in reply to windexh8er’s tweet the fun fact that Apache treats files like file.php.gif as PHP code and not as a GIF. Very true.

[2nd Update]
As you can see, HD also added his remark to this blog’s comments, which unfortunately got caught in the spam filter so I didn’t see it when posting the first update. I guess I’ll have to whitelist you HD ;).

On August 22nd, we will present our JBoss AS talk at FrOSCon. It’s a two day conference on Free Software and Open Source. They’re featuring a Java track in their program, where we will present at 4:30pm.

I’m positive this is gonna be a lot of fun, as I guess we will present to a crowd who’s eating (drinking?) Java for breakfast. So I hope for some interesting feedback from those who have far more knowledge about Java intricacies than we have. We just 0wn boxes ;).

We’d be glad to have you at the talk, so please come. I think the rest of the conference will be interesting too, especially for admins and developers. Ticket prices range from 5 EUR for normal visitors to 100 EUR for business tickets, so money’s no excuse for not attending.

In this post, I want to discuss one standard part of every web application pentest: Searching for standard files. This can be any of:

• Changelog, Readme, License etc. files
• (Example) documentation
• Example web pages
• Example scripts
• …

and many more I probably forgot to mention. I’m talking about all these files that get installed with every standard installation of so many web applications (or servers, e.g. the Apache documentation on every newly installed system).

So, why is it necessary to search for these files, you may ask? Well, first of all, many times they give you valuable information about the application. One thing that crosses the mind is for example version information. It’s always interesting to know what version the web application has you’re pentesting, and more than often you get the information for free by just searching for a Changelog file if the application does not tell you by itself.

Even more interesting are example web pages, scripts and the like. Let me show you why: Search for “example” in the OSVDB (Open Source Vulnerability Database). At the moment, I get about 71 hits for vulnerabilities in all kinds of applications. They range from Cross Site Scripting over SQL Injection up to Remote Command Execution. This means that there’s a serious security risk emanating from these normally totally superflous files. And that’s what makes your local pentester happy, of course ;). Many times, one of the first things I do when pentesting an application which is running on some open source solution is to download the source and have a look at what interesting files there may be, even before starting to get my hands dirty with application-specific tests.

The moral of the story: Keep the attack surface of your web application to a minimum by removing everything which is not needed for it to work properly. This is not only true for your own stuff (old web pages not used any more, scripts etc.) but also for all parts of the standard installation of e.g. the CMS you’re using. Even if on a first glance, the files are seemingly harmless. They’re not, and even if they are, there’s no harm done in removing them if you don’t need them. And believe me, normally you don’t.

The first step we take is of course to ask our clients if it is ok to write security advisories about the vulnerabilities and publish them. This is due to the fact that if we discover something during a pentest, the clients paid for these findings and have a right to decide what to do with them. We always recommend releasing stuff to the public if it’s something generic, as we of course also benefit from people releasing new security advisories, as do our clients.

The next step is to write preliminary advisories with all the details and then notify the vendors. We want to give them a chance to patch the vulnerabilities before we release the advisory. We therefore work closely with them on the issue and coordinate the public announcement.

Before finally releasing, we notify our clients about the patch so they can deploy it. The vendors hopefully also notify their clients, if we’re talking about commercial software. As soon as the vendors publicly announce the new version of their software or that a patch is available, we release the advisories on our homepage and through the usual channels (Bugtraq, Full Disclosure etc.).

I think this is a pretty normal procedure for releasing new advisories and is the usual “responsible disclosure” type of thing. I guess there’s only two points we may need to explain further:

1. We release our advisories as soon as the vendors publish their security alerts / patches / new versions. The latter is the most important. Sometimes, the vendors silently correct security holes or just tell you that “some security issues” were fixed. When we release our advisory with detailed information, sometimes people complain (not only to us, others do the same and get those complaints, too) about not having enough time to deploy the new version before everyone knows what the vulnerability is.

   The problem is that every sufficiently advanced attacker is able to use a diffing tool to check what changed in the code and then knows what the problem is. This is of course made difficult if there’s not only a security fix, but also other fixes which get included in the release, but it’s still only a matter of patience and time. People do it all the time with Microsoft’s patches (Alexander Sotirov is one of the good guys btw., don’t get me wrong), for example. So we rather release our advisory and tell you what’s wrong, than to publish an advisory with only insufficient information. Which leads us directly to

2. We always give detailed information about the vulnerabilies in our advisories. This is another controversy going on for some time, should advisories contain detailed instructions on how to exploit the vulnerability (and even contain PoC exploit code)? Many argue that this only makes it easier for malicious attackers and worse for administrators. The thing is that without the details, you make it actually harder for administrators to estimate the risk of a vulnerability and if or when they should patch / upgrade. Also, as mentioned above, any serious attackers will get the details themselves in no time. It is of course a problem if you release without a patch or new version being available – which brings us back to responsible disclosure.

Nonetheless we had a fun weekend with too little sleep and too much caffeine. In the end our team scored 3300 points and made the top 15. If you like, check out the Defcon 17 Capture the Flag Qualifications Results. More than 200 teams solved at least one question, with more than 50 scoring 1500 points or more. We’re really looking forward to next year’s qualifiers. Hopefully we can participate again and improve our score.

Thank you, ddtek, for a great game and congratulations to all teams that qualified for the DEFCON CTF.

The paper gives you a more detailed overview about the JBoss AS internals we used in the attacks, as well as a complete description of the individual exploitation techniques.

The only catch is that the paper is written in German, as it was first published in the DFN-CERT’s workshop book. Maybe I’ll translate it someday, but at the moment there’s just not enough time to sit down and do this for almost 30 pages. See it as an interesting way to brush up on your German ;).

The talk focuses on examples from penetration tests and real cases of industrial espionage. It is meant to raise awareness about unusual and surprising risk factors from both the digital and the physical world.

Participation is free, interested parties can register here.

Greyed out key fingerprint in PuTTY dialog

I’m convinced greying out the server’s key fingerprint will make sure those pesky hackers won’t mess with the system…

Enjoy the new design and drop us a comment (or email) if you like it, don’t like it, have suggestions for improvement or if you find a bug. All feedback is welcome.

“No, we just need one of your pentesters. He’ll be working under our company’s name for the time.”

The above conversation, though not in the exact same words, happened more than once in the past years, with different companies. Some of those companies were even advertising penetration tests as one of their key competences. Which brings me to the topic of this blog post: Pentesting as a “me too” business.

It seems that there are a lot of IT companies nowadays jumping on the IT security bandwagon, offering a variety of related services (one being pentesting). The problem is normally that IT security and pentesting is nothing you learn in two weeks by booking a “Writing Exploits for Beginners” class. That is why most of the time, what you’ll get is the results of some automated scanner like Nessus, maybe with a custom document layout. This, of course, isn’t a pentest at all.

Those who at least realise that they don’t have the necessary skills to do a pentest on their own will go and hire somebody for the project, which results in phone calls like the one above. This makes sense from a business point of view and is common practice in other branches of business. But a good pentest requires more.

First of all, a company specialised on pentests like us will hardly let their pentesters do their work in the name of somebody else. That’s just bad for your own business, despite the quick bucks we could make. But besides this obvious point, the main reason is that a pentest is more than just hacking away at somebody’s network or product. You have things like preliminary talks, to get an impression of the clients’ needs and to help them planning a pentest which makes sense for them. You want to determine the threat potentials, the scope of the test, an estimation of the time frame needed etc. This is followed by the actual test. After the test, the follow-up work starts. Additionally to the documentation we write, we always give a final presentation with the results, demonstrating whatever we found, for example. There’s also the point that we always do a pentest in a team of at least 3 pentesters, because we are convinced that the teamwork leads to better results in the end (I guess I should elaborate on this in another blog post sometimes). And these items are just off the top of my head and are certainly incomplete.

A pentest, at least for us, is therefore more than just an individual pentester doing the technical work. “Just” hiring somebody for the job after you sold your client a pentest, without having any expert knowledge in this area, will in all likelihood result in something subpar, even if the one you hired is somebody capable.

• RT-SA-2009-001: IceWarp WebMail Server: Cross Site Scripting in Email View
• RT-SA-2009-002: IceWarp WebMail Server: User-assisted Cross Site Scripting in RSS Feed Reader
• RT-SA-2009-003: IceWarp WebMail Server: SQL Injection in Groupware Component
• RT-SA-2009-004: IceWarp WebMail Server: Client-Side Specification of “Forgot Password” eMail Content

We found those during a penetration test of a customer using this system, and now the vendor has released the fixed version 9.4.2. So please, if you’ve deployed an IceWarp eMail Server somewhere, upgrade to the new version.

Vulnerable JBoss AS (Dec. 2008)

The picture above shows a little statistic we made in December 2008 with the top 25 unique search results from Yahoo!. As you can see, less than 10% are secure against the attacks we will show in the talk. About one third of the JBoss AS weren’t reachable any more. Might make you think someones exploits crashed the boxes ;). We didn’t attack those JBoss AS for real of course, but only looked for telltale signs that make you pretty sure they are exploitable. So if you want to know how the attacks work and see a live demo, join us on the 19th.

Participation is free for everyone interested, you only have to register. We hope to see you there!

RedTeam will support the event by joining the exhibition in the foyer with our booth. We’ll show how to eavesdrop on DECT phones, so feel free to come by. Bring your own DECT phone for added fun, so we can examine them on-site. We’d be happy to see you around!

As expected, I wasn’t let down this time either. The first speaker was Andy Clark from Detica Forensics. He held a very entertaining talk about security delusions, including e.g. why putting everything in “the cloud” (meaning mostly all those Web 2.0 services like Facebook, GMail, Twitter etc.) is of more harm to the privacy of the individual than most people think. Nothing new from a technical point of view, but interesting nonetheless. According to the hands raised when Andy asked the audience various questions, I was also only one of a few people with only fully encrypted HDs and without accounts in any of the major Web 2.0 social networking sites. The paranoia comes with the job I guess… ;).

The next talk was held by Boris Škorić from the TU/e and covered Physical Unclonable Functions (PUFs). Those are e.g. interesting for anti-counterfeiting measures. Today, anti-counterfeiting features like holograms are still counterfeited, as the production process is repeatable. With PUFs, processes can be used which cannot be run a second time, but create something uniquely identifiable.

After lunch break, Benne de Weger (also TU/e) gave his talk about the creation of a rogue CA certificate. This was first published in December by a whole group of security researchers (him being one of them) at the 25C3 and caused quite a stir back then. Have a look at this website for more information and a link to the video from the congress, if you’re interested in more details.

Finally, David Naccache (ENS) gave an introduction to side channel attacks and how to solve at least parts of the problem. He first demonstrated how his research group was able to transfer bits of information between two computers which were placed in the same rack or blade, but otherwise completely separated from each other. They did it by raising or lowering the heat one machine emitted, and measuring the fan speed in the other. They were able to read about 1 bit per 13 minutes, which is quite slow, but still proves the point. In a second part of his talk, he introduces the subleq machine. This is a Turing-complete machine with only one instruction:

subleq a b c

It subtracts b from a and branches to c if the result is less or equal to 0. He then proceeded to build “normal” assembler instructions from this like mov, clr etc. The advantage of such a machine is that there’s no way of running side channel attacks by measuring differences between assembler instructions, as ultimately, there is only one instruction.

All in all, it was again a nice event with interesting talks and the opportunity to chat with like-minded people during the coffee- and lunch breaks. I’m looking forward to seeing what EiPSI will do on the second anniversary :).

But now, even Google seemingly can’t resist to play the practical joke of showing us this message for our adwords (click for a bigger version):

Google badwords filter

Very funny Google. Very funny.

I still have to rework the categories a little bit, they’ve been neglected and almost everything was put into “RedTeam” so far. There weren’t any categories in the old blogging software, so I will have to adjust this by hand, which I already started and did for the posts going back to 2008. Maybe I’ll do this for more posts if I’m bored.

BTW, the comment-to-post-ratio has dropped since the blogging software was changed, and we wonder why that is. So I hope the new layout is an incentive to start commenting again ;). You don’t have to give your email or website in the comment, they’re completely optional (and the email will not be shown anyway).

So, welcome to the team and happy hacking Alex!

[0] No, there’s no photo on the team page at the moment, but we’re working on it

Some weeks ago, we had a problem with the laser printer at RedTeam’s headquarters. It started to smear toner on the page in some places. The vendor had an online chat for support questions. We decided to at least try and get someone competent, as usually these support chats don’t have the reputation of being very helpful.

We were very suprised that shortly after giving our chat partner our telephone number, the phone rang. The support staff was very helpful and let us measure the distance between the edge of the paper sheet and the first smear. He instantly knew that this was a problem of the exposure module fuser. Instead of trying to sell us a new one, he proceeded to instruct us on how to clean it:

Cleaning the fuser

After the cleaning, the printer worked again as expected. But this is not the end of the story. Some days later, the Fax/Scanning machine from the very same vendor broke down. After calling them and detailing the problem, they gave us instructions on how to get some more informations from the machine (we now know how to get into admin mode…) and send it to them. One day later, we got the call that they will send us a new machine, as the old one can’t be fixed. All this without any further questions or trying to blame us for the error.

So, either we were lucky or there are still vendors with decent customer support. The name of the vendor? HP. Not a small one, as you can see. I really hope others will follow their example.

Update: a colleague told me that it was the fuser, not the exposure module which had the problem.

The other talks were quite interesting, as always. Dr. Neil Long from Team Cymru gave a very informative keynote about the computer underground, not so much from an “I didn’t know this!” point of view but more because it was a nice wrap-up of the current situation. With a lot of interesting IRC conversations. I guess you have to play at least two years of online games before you have the adequate skills to write in the same language as those guys and girls. The way 1337 sp33k is going scares me…

Anyway, lots of familiar faces and interesting conversations with people mostly coming from a university background, working in the data centers. The broad attack surface of a university network gives them quite a lot to do in the security sector, so it’s always interesting to hear their stories. The social event at the Gröninger Braukeller in the evening of the first day is also quite legendary by now ;).

We are of course planning to go there again next year, hopefully with a new topic for a talk.

So if you didn’t have the opportunity to join us in Luxembourg, come and meet us in Hamburg if you can. There’ll be of course many other interestings talks, see the website for the complete program. The talk will be in German this time, but you can get the english slides from the hack.lu at RedTeam Pentesting’s publication page. The Linux Magazine, like in the last years, will also stream the event.

Printer error message: PID, TID

Printer error message: LIBDecisionImpl.cxx

Which reminded me why we always tell our clients to treat their printers like servers, security-wise. Additionally, never trust a machine with a LIBDecisionImpl.cxx. Who knows if Asimov’s Laws really hold. In a next step, it may develop a LIBConsciousnessImpl.cxx…

The talk has real world examples of mistakes made when using cryptography. It covers the implementation of weak crypto, self-developed crypto and how sometimes crypto is used with the wrong assumptions in mind, leading to us just circumventing it. If you’re interested in the slides, grab them at our publications page.

Thanks again to the EiPSI staff for the kind invitation, I really enjoyed my visit there.

Ethernet cable in hotel

The first three German lines roughly translate to

fast – comfortable – secure
[X] tap-proof
[X] free of radiation

Good ol’ ethernet cable. Now they just need someone who explains ARP spoofing and unencrypted network traffic to them. But hey, it’s Highspeed Internet. Those packets are way too fast to get sniffed.

The talk (in German) will be held at the Open Source forum on March 06, the security day, at 2:30 – 3:15pm, with the title “Überraschende Angriffsvektoren: Weit verbreitet, oft übersehen” (surprising attack vectors: widely spread, often missed). The Linux Magazine will also do a live streaming of the event, in case you can’t make it to the CeBIT.

“Well, sometimes they find five vulnerabilities and report only four, so they have something ready for the next time.”

This is something that always bothers me, this attitude that a pentest is only successful if you can show new vulnerabilities. If we test a system for a second time and the vulnerabilities we found in the first test are fixed, and the customer additionally didn’t make the same mistakes or fixed them in all other places, I consider our job well done. My interest doesn’t lie in successfully exploiting my client to show what a 1337 h4X0r I am, but to increase their security level by showing them the problem, explaining it in detail and thus enabling them to avoid making the same mistake in the future. Although, the greatest satisfaction lies in combining those two :).

Of course, if you work with someone for the first time, this first test is always difficult in terms of customers not knowing if they get what they pay for. It’s hard to tell if those new pentesters didn’t find anything (or only a few weaknesses) because your security is top notch, or because they’re just not good enough. But in a retest, the customer already worked with you and knows that you do a decent job (hopefully ;)).

Also, normally, there’s always some new vulnerabilities to find. IT systems just change too fast to not include some new attack vectors the next time you test. There’s also the thing about systems never being 100% secure, with only the complexity of exploiting them successfully getting higher. So the more time you have with a system, the more intimate knowledge you get and the more potential security flaws you find.

to become the best and most fun hacking (*) and security event in Belgium and W. Europe.

The Call for Papers is open since January 25, so you still have time to submit. We wish them the best of luck and hope to be able to make it to the conference, as Brussels is only a 1 1/2 hours drive from Aachen.

<object width="550" height="400">
  <param name="movie" value="somefilename.swf">
  <embed src="somefilename.swf" width="550" height="400">
  </embed>
</object>

This is all well and good, but sometimes, developers want a little bit of flexibility. Lets say I want to display some user specific content, like the user’s name in my Flash app. And while I’m at it, why not load some more user data from an XML file? So how can I dynamically change what my Flash app is howing and what file it loads?

This is where FlashVars come into play as one convenient method to achieve this (there are more, see this technote).

FlashVars look more or less the same as HTTP GET parameters and get imported into the top level of a Flash movie. The syntax for <object> is to add it as a <param> tag:

<param
  name=FlashVars
  value="username=patrick
         &userdata=http://www.example.com/udata/patrick.xml"
>

For <embed>, add it as an attribute:

<embed
  src="myapp.swf"
  FlashVars="username=patrick
             &userdata=http://www.example.com/udata/patrick.xml"
></embed>

The variables will get imported and I can use them in my Flash movie. Great, isn’t it? Well, there’s one more thing, which made me write the whole blog post: FlashVars can also be passed directly to the Flash movie, without adding the FlashVars parameter:

http://www.example.com/myapp.swf
  ?username=patrick
  &userdata=http://www.example.com/udata/patrick.xml

You may see where this is going already. The whole point of the story is: These variables almost never get checked or sanitised before being used in the Flash file. With many Flash files, this opens up a whole lot of attack vectors. It is of course a client side attack, because I have to make a user click on a manipulated link.

One of the worst things (security wise) people do is to load external URLs with this technique, like in the example above. Normally, these URLs get loaded internally with the getURL() Actionscript function. Did you know that this function also takes javascript: URI schemes? This means Cross Site Scripting in your Flash movie:

http://www.example.com/myapp.swf
  ?username=patrick
  &userdata=javascript:alert('RedTeam')

By loading external data without verifying it first, you make yourself (or more precisely, your users) also vulnerable to potential exploits in the Flash Player itself. CVE-2007-3456 describes a Flash Player exploit with a manipulated FLV file. This can lead to a complete compromise of the user’s system.

There are of course a lot more possibilities, depending on what problems people are trying to solve with FlashVars.

So, to make a long story short, FlashVars can be easily manipulated and need to be treated like every other user input. Never use them in your Flash application without first checking them like you check your HTTP GET or POST parameters.

Pizza amounting to exactly 23 EUR in the shopping cart

No, this wasn’t planned. All hail Eris!

DECT card working with Linux

Holy sh*t, this really works. Thank you guys, well done!

BTW, tests with our own DECT equipment (no, we don’t use DECT telephones for work. So don’t even think about it) showed that it suffices to press buttons like “internal call” or “dial” to make the telephone open the microphone and send to its base station.

So you either need some travel companion having an eye on your valuable stuff, like your laptop, or some other means of securing it. Many people favour Kensington locks for this task. Apart from the fact that these locks do not provide any real security, some of the people using them seem to forget that they will only protect your laptop from getting physically stolen and will not protect the data on your harddrive from being stolen or wiped or trojanised or whatever:

Laptops secured with Kensington locks but without locked screens

The above picture was taken on a business trip on the ICE, where you usually find your share of other business travellers, like in this case. The screen of the laptop is not locked at all. For business travellers, normally the hardware costs of the laptop being potentially stolen will be less than the costs of losing the data on it.

So please, if you really want to leave your laptop alone with strangers, at least lock the screen, so I can’t just plug in my pendrive and get all your data. Turning the laptop off so the full disk encryption you hopefully use will take effect wouldn’t hurt either.

a fortress-like building

Luckily, we also avoided all traffic jams on our way to Brussels, so we had some time to spend. First we explored the way to the workshop location, which was easy to find. Then we spent some time sight-seeing and found a very nice sculpture:

a sculpture of a criminal flooring a policeman

On our way to get some fast food, we also stumbled upon the home of big brother:

a map with many surveillance cameras

Finally the workshop itself was much fun. As we found out, it was the initial meeting of the Brussels hackerspace community. There will be more events every second Sunday of the week if I remember correctly. The next meeting will be about building wireless antennas. It will also be the topic of a workshop at the 25C3 in Berlin at the end of the year, where we will meet again. Thomas also gave an introductive talk about aircrack-ng and its current development, which was recorded and will be available on the aircrack-ng homepage.

hackers around a table having fun

Thank you Thomas for the workshop and the tons of potatoe crisps and also everyone else for this nice sunday afternoon.

Now for the 2^2th time some of us are going to the hack.lu security conferrence, taking place from October 22nd to October 24th in Luxembourg, Luxembourg.

We really enjoyed being there in the past and are looking forward to the CTF this year. This year, all of us will attend the conference, so maybe we will meet you there? There will be also an interesting talk from us about jboss security on the second day.

Right, who’d have thought. I really missed the warning about the sharp edges of the card.

Doing skimming at an ATM frequented by a pentester? Tough luck ;).

Of course, he immediately notified the bank and the police. You’ll never guess what their comment was: “Sorry, we just got a new ATM, and it really looks like this one. We know it’s bad, and we are trying to get this fixed, either by trying to get the plastic out of the old machine’s card-slot, or by gluing a new plastic piece into the new machine’s card-slot, too.”

So, what was this all about? It wasn’t a skimming attack at all, but the bank most likely installed one of these devices. They are called “Card Protection Kits” (CPK) and are actually made to prevent skimming attacks. A picture and some information (unfortunately, only in german) can be found on this site, as the vendor does not give any details without a registration.

How do these devices work?

Basically, they get glued to the card slot of the ATM and send electronic interference signals. If some skimmer glues its own device in front of the CPK to read the card data, the interference signal will render it useless. The real card reader of the ATM is sitting inside the ATM and will not be affected by the signal because of its relatively short range.

Anyway, the bank really screwed up. First of all, customers who are aware of skimming may (as in our colleague’s case) falsely alert the bank, which costs time and money. Secondly, telling people that it is normal that some device may be attached to the card slot of some ATMs doesn’t help to raise the awareness about skimming at all, more to the contrary. And third, if you want to prevent skimming attacks with these devices, make sure the ATMs next to the one you’re trying to protect are not completely vulnerable.

But as this weapon of mass hacking awesomeness could not be used for everything, we also needed to do some good old hacking by hand. Literally. Unfortunately a major line of defense of the device were sharp edges, which led to major bloodshed:

So, kids, please don’t try this at home!

So, who says cryptographers only break theoretical constructs? ;-)

Kiel has a large harbor area, which – since 9/11 – is a restricted area.

Anyway, the restricted area does obviously not restrict one to do any fishing inside. Am I the only one thinking about phishing? ;-)

As our host works in the privacy area, we looked out for privacy related things in Kiel as well. But it looks like privacy is already a big issue there:

Lastly, it has been hard for us to find a decent restaurant in the evening in the middle of the week. But it seems that the citizens of Kiel have already solved this problem. Take a look at the mobile BBQ we found on the streets (sorry for the bad image quality):

To summarize: We had some great days in Kiel, although about 2400km of driving by car and 8 hours of shooting for just 8 minutes of air time is rather stressful. Thanks a lot to everybody involved in the shooting, especially to Thilo Weichert and the ULD for their hospitality.

This is it for the moment, as we’re still busy and there’s a lot of work to do. Stay tuned for some pictures we made in Kiel :).

This morning, we wanted to rent a car, like many times before. So, we logged in with our corporate account:

And now, have a look at the brand new source code of the login form:

Sixt effectively removed the login for all of their business clients. Well done, developmestruction team…

The talks were all very interesting. David Kahn (yep, the one who wrote “The Codebreakers”) gave the first talk about (what else) the history of cryptography. He was followed by Whitfield
Diffie (”do you want me to wear that microphone for recording? ‘Cause, you know, I talk rather loud…”) whose talk about SIGINT was pretty entertaining. And one of his first sentences was (I’m paraphrasing) “To know anything about defense, you have to know the offense”. Which, of course, is what we as penetration testers say all the time :).

Andrew Odlyzko gave a controversial presentation about why we survive in such a hostile environment as the internet. It was controversial because he advocated (I’m simplifying here) security by obscurity and messy programming as valid security measures. It would take too long to elaborate on his talk though, so maybe he will put up the slides someday and you can get your own picture about it. But it was really interesting. After him, Ian Brown gave an overview of the current privacy situation in England. Scary stuff. Last but not least, Bruce Schneier gave a talk which elaborated on the difference in what we feel about the state of our security and how secure we really are in an objective way. The talk came without any technical terms and was going more into a psychological/biological way. Pretty interesting topic. The day ended with a panel discussion with all the speakers, complemented by Dan Bernstein, Bart Preneel and Corien Prins.

So, all in all, it was a very nice event, with top speakers and participants in the panel discussion. Thanks to the EiPSI (especially to Dan Bernstein and Tanja Lange) for making such a conference program possible. And, if that would’nt have been enough, all guests got the present in the following picture when leaving :) :

Oh, and I dare you to click it! ;)

They asked us for an interview and a live demonstration of a real attack against online banking systems using the iTAN, which we kindly provided. The (Windows XP) box of the victim gets trojanised by us (via a very cute easter greeting card ;)) so we can start a man in the middle attack and manipulate the data stream.

The demo “trojan” we wrote is actually quite simple. All we really do are two things: First, an entry is added to the etc/hosts file (yes, Windows has one, too; on XP, you’ll find it under C:\windows\system32\drivers\etc\hosts) with the banking site’s domain name going to our own IP address. And second, to circumvent any warnings about an invalid SSL certificate, we add our own root certificate to the system. This will actually provoke a window popping up with a warning message. But Windows allows us to send a message to the window, telling it that the “OK” button got pressed, so the window will go away in a split second. Now we can use a fake bank certificate and the browser will not complain about it being self-signed or anything.

The server side is just a Python script doing the man in the middle, manipulating any money transfer data.

Oh, and as I may already disclose to you, the trojan was not detected by any antivirus programs. But I guess that’s not really surprising to anyone.

We’ll be presenting in two tracks. The first presentation is a peer-reviewed paper about a graph-theoretic approach to estimating the costs of penetration tests and how to efficiently distribute the given time for the tests, which will run in the academic track. The paper was written in cooperation with the Pi1 – Chair for Dependable Distributed Systems of the University of Mannheim. The second presentation is a more practical talk about “ubiquitous” IT security, running in the NETSEC panel.

We also exhibit at the conference, as we are sponsoring the event, so be sure to visit us at our booth. We even may have free posters there ;).

Day 1: Got my new account data.

Day 2: Everything works as expected. Changed the initial password (5 digits) to a more secure one (more chars).

Day 3: Everything works as expected (with new password).

Day 4: Everything works as expected.

Day 5: Can’t login. Account has been disabled. Called the bank.

The answer: “Well you have used more than 5 digits for your password. Please use exactly 5 digits for your password, just like the initial one. Otherwise it is possible, that your account will be disabled after some days.”

Without any comments…

function validate_sql($input){

  $searchstrings = array(
    0 => "/drop/",
    1 => "/--/"
  );

  for($j=0; $j<count($searchstrings);$j++){
    if( preg_match($searchstrings[$j], $input) == true){
       return null;
       exit;
     }else{
      return $input;
    }
  }
}

The building itself looked secured well, with guards on every door. So not everybody can enter the non public areas, where the offices are located. Anyway, we are pentesters, so if nobody asks us, we just move on, regardless of the guards. That worked quite well: In about 3/4 of our tries we could just walk through, no guard asked anything. Of course, you have to wear the right clothing, so you look like any other employee and you cannot stop anywhere to look for the right direction, otherwise, it is just a matter of time, but you will look conspicuous ("May I help you?"). Anyway, we knew where to go, so we just did so.

You can of course minimize the risk of being stopped more, one possibility is looking very stressed out with a phone on your ear (Especially blackberries are a good for that type of social engineering attacks. Many people combine blackberries with important business people and you cannot stop an important person, can you?). If you are asked who you are and where you want to go, sometimes even an internal business card of some employee is enough to pretend you are internal ("You do not know me? I am working here for years…"). Works well sometimes, but does have a high risk, if the guard knows the guy you pretend to be…. better run then *g*.

Back to the internal pentest. Someday our contact person asked us, how we were able to enter the building, as he never got a call from the guards (that was the normal procedure if any external wants to enter the important areas).

"We just walked in…".

The last day testing we made an appointment for the final presentation. Our contact person got a piece of paper, wrote down a telephone number but then threw it away and told us:

"This is the number you can call to enter the building. Oh, well, no, I think, you do not need that number to enter the building. We will meet at 10am in conference room T7.14. I am sure, you will find a way to get there."

We did…

Funniest thing about it: “Nett” is the german word for “amiable/nice”.

]]> http://blogs.23.nu/RedTeam/2008/01/antville-17053/feed/ 0 http://blogs.23.nu/RedTeam/2008/01/antville-16942/ http://blogs.23.nu/RedTeam/2008/01/antville-16942/#comments Thu, 03 Jan 2008 07:30:34 +0000 jensl http://3.blogs.23.nu/RedTeam/2008/01/antville-16942/ Once ago last year a member of our team went to a medium size company for an appointment. Some weeks later one of my friends told me the following:

“(Smiling). Do you have an actual business connection with $medium_size_comany?”

- “You know, we generally do not talk about our customers. But why are you asking?”

“Well, an employee has seen somebody of your company in there.”

Actually the following happened: When the RedTeam member went to the appointment, he has been seen by some employee there. This employee talked to other employees immediately:

“(nervous) Do someone know anything about a pentest going on here?”

- “What? A pentest? Here?”

“There are members of RedTeam Pentesting inside the building. I have seen them.”

Despite the fact, it was only one member, it had just been a normal business meeting. Nothing spectacular, no pentest. Anyway, looks like we are well known in some companies and we have to hide ourselves well, when actually doing a stealth pentest.

md5: e8008c4d123d24a70964a2390146df02
sha1: 71f88e8eef333f5d1a24e734dbde41597bb9c521

Good luck!

… I just hope they don’t want their hub back.

“This felt like a James Bond movie. But a bad one…”

(a customer after a total network 0wnage)

Chaos in the laboratory, or: what’s cooking?

Harvesting fingerprints produced with wood glue and graphite.

Mixing dental compound…

…to produce a finger form.

Heating up some gelatine for producing fake fingers.

As I can assure you, the team had much fun not staring at their screens exploiting software, but hacking hardware for a while.

Oh, and before you ask: no, we can’t tell you the scanner model. But here’s a hint: It’s a swipe sensor.

Getting the internal cabling of the office and the internet uplink working:

Buying furniture…

…and assembling it.

Well, time flies: Right now we are thinking about moving into bigger offices, as ours begin to get crowded.

Tuesday morning the admin rushed in the CEO’s office. He even forgot to knock on the door. The admin spluttered: “They are in!” and presented a notebook showing evidence of the activity of the penetration testers in the internal network. This moment, the CEO started to smile and was happy.

At a first glance it seems absurd that the CEO is happy that the company’s network is insecure. We often see that customers are glad if we find security weaknesses, the reason being that they’re left in uncertainty if we do not succeed in hacking his system. The customers will then ponder if their systems are indeed secure or if the pentesters just showed a poor performance. Finding security weaknesses and fixing them, on the other hand, gives them the confidence that the money for the pentest was well spent.

Unfortunately the fair itself was rather disappointing. One hall less than in the last years. One day shorter. Less exhibitors and less visitors (heise (in German)). Compared to last year the aisles seem empty and the halls seemed to have lots of space left that was hidden behind flexible walls. For next year we now will have to check the alternatives again.

(Except for the switch for the main uplink, which we 0wned 15 minutes after the opening of the conference [see screenshot below] :-) ,) we can only say:

Well done hack.lu team! We will see you next year!

We all want to be there of course, but this year we really had to fight for some free time. A lot of our customers want to get their pentest as soon as possible. So for the last 2 month it was not clear if we can make it. Anyway, yesterday we won the fight: The three days are pentest-free! To get things going we sent out the registration. Hopefully, we will have at least as much fun as we had last year!

So, if you haven’t registered yet, we can only recommend you do so:

So, maybe we’ll see you there, we’d be glad to. Let’s have some fun!

Yes, it’s a Maestro card. If you know the PIN, you can get money from ATMs. Many shops require the PIN for paying with this card, but if you can provide a fake signature, you can still pay with the card in many shops without knowing the PIN.

Now, when you look at the back of the card it looks like this:

YES! It’s not signed! This means the finder is able to put just any signature on it and go shopping (hint: this would be illegal). Worst thing for the owner: If someone messes around with this card and the bank finds out that he has not signed the card before forgetting it in a rental car, the owner of the card will be liable for all damages.

Of course, we tried to return the card. The bank finally told us it would not be feasible to return the card to their customer and instructed us to destroy it. Which we did. Or didn’t we? ;).

• Alcatel-Lucent OmniPCX Remote Command Execution

It’s the same old story: unfiltered user input gets passed to the ping command on the host system over the web interface. You’d think that this type of vulnerability became extinct after the 80’s. But who am I kidding.

So, don’t skip testing for this because it seems to be lame. These vulnerabilities still exist even in commercial (enterprise) applications, not only in some newbie scripts on Sourceforge.

As a major part of the questions were related to pentesting we spent some time to answer them in detail. Answers to these questions have also been given by other companies, even though some of them obviously can answer even the most complicated questions with only one or two sentences.

Making Promises

Among those answers several lines caught our eyes that we would like to share with you. One of the authors claims for his pentesters:

“Die Tester finden jede bestehende Lücke, [...]” (”The testers find any existing [security] hole,…”)

We will just let Edsger Dijkstra speak here:

“Testing can be used to show the presence of bugs, but never to show their absence!”

One should also remember that customers might take such promises literally, which might have legal consequences if an ev1l haX0r finds a vulnerability after such a super-test.

Another author correctly states on this topic:

“In der Praxis würden vollständige Überprüfungen aller Bereiche Jahre dauern und sind meist nicht durchführbar.” (”In practice a complete check of all areas would take years and is usually not realizable.”)

Please keep in mind that even if one did a pentest with a duration of one year, the network of a typical company would change in the meantime, so that you could start right again.

Workflow of a Pentest

Most of the authors agree that pentesting is a process that has to be individually adapted to each customer. Some of them describe this process as a linear sequence of steps. This corresponds with a well know study on pentesting from the german BSI. In practice we have found that pentesting is in fact a cyclic process. Once we gain access to a system we will start over with reconnaissance and enumeration in order to find new targets to attack.

First of all: Do not send DOC Files:

DOC Files are not considered appropriate as e-mail attachments. Hackers are usually aware of this.

Ok, so you send a PDF file:

Now, remember to also embed the fonts you used! If you use Windings, do not expect my linux box to know about it.

Also, do not forget: Not only Word files can contain hidden information. A closer look at some PDF shows:

With the help of the “strings” command we can see for example all the names of the included files. This is bad if it reveals the names of other companies that also got the application.

Lastly, a non-technical hint: A list of every hacker tool that you know does not tell us anything about your skills.

Do not misunderstand us though. We appreciate every single application! So if you think you would fit into the team, go to our contact page and send us an e-mail.

Take a look at the ServerView advisory we published some weeks ago. We have rated that issue high. Now take a look at how other people are estimating the risk:

• NIST is scoring the vulnerability with a base score of 7.5/10
• Secunia is rating the issue with 3/5 (moderately critical)
• ISS also addresses it as high risk

So, as you can see, the ratings differ a lot. It seems to be hard to rate an issue correctly for all different circumstances. After publishing the advisory we got some comments on our rating, sounding like: Well, a ServerView interface is always in a completely separated management network, so nobody but the admins themselves can exploit that issue, so one should rate it to low or medium. Absolutely correct, if it is in such a management network… In practice we (or any other attacker) often can find a way into most of the internal networks. And suddenly, a formerly low rated vulnerability has a high impact.

So, what do we do in our reports? We try to rate the risk individually for our customer. How hard is it to exploit that error and what advantages can we get by doing so? Let me give an example: If you are attacking a web shop, trying to extract credit card information out of the backend database, we would rate a vulnerability giving us that info as high as possible; Even if we have no root exploit. Some people will tell you again: Well, this cannot be a highly critical vulnerability, as a root compromise would be even worse. But from the customer’s perspective it is totally uninteresting if an attacker gets root if he already has the credit card data.

What can we learn? Always rate a security issue yourself, from your perspective. Do not trust any rating that is not individually composed for your special case. That’s why we need a disclosure of the complete bug. Otherwise, nobody is able to calculate the risk and the rating may not fit for your environment.

]]> http://blogs.23.nu/RedTeam/2007/07/antville-15508/feed/ 0 http://blogs.23.nu/RedTeam/2007/07/antville-15354/ http://blogs.23.nu/RedTeam/2007/07/antville-15354/#comments Fri, 06 Jul 2007 11:21:38 +0000 phof http://3.blogs.23.nu/RedTeam/2007/07/antville-15354/ We published two new advisories about security vulnerabilities in Fujitsu-Siemens products found during a penetration test:

• rt-sa-2007-002: Fujitsu-Siemens
  ServerView Remote Command Execution
• rt-sa-2007-003: Fujitsu-Siemens
  PRIMERGY BX300 Switch Blade Information Disclosure

Heise also runs a news item:

• German: Lücken in
  Server-Produkten von Fujitsu Siemens
• English: Holes in
  Fujitsu Siemens’ server products
]]> http://blogs.23.nu/RedTeam/2007/07/antville-15354/feed/ 0