After lunch it was Sergey Bratus and Travis Goodspeed's turn to speak about the security of USB ports
, telling how it is possible to compromise the whole system via a unattended USB port. This was a really interesting talk that one can explore by himself taking a look at some good documentation on Travis' blog
The talk “We Came In Peace – They Don’t: Hackers vs. CyberWar”
was next. He gave his opinion about the actual cyberwarfare and the difference between the point of view of Governments and cybersecurity experts about this subject. Some ideas from his talk: avoid the use of 0-days as weapons through Full-Disclosure, learn how to protect you playing CTFs and don't give up.
Submitted by jesparza on Sun, 2013/04/07 - 14:16
Until now I had not had enough time to write about my experience at my first Troopers
. Due to some good comments about it
I had had in mind going to Troopers since some time ago, but for one reason or another I hadn't been able to do it. Last year I had the opportunity to share table with Enno Rey, Troopers
organizer and CEO of ERNW
, at BlackHat Europe. That time I saw they were a good team and good people, and this year, living closer to Heidelberg, I had no excuses to go.
I arrived in Heidelberg at 3:30AM after 9 hours on the road due to the bad weather conditions. I was able to rest to be ready for the talks
in the next morning. I missed the keynote by Rodrigo Branco
, but I heard that it was really good. The first talk I attended was “Paparazzi over IP”
by Daniel Mende and Pascal Turbing about hacking a CANON camera, equipped with a wireless adapter and other features. The result was that it was possible to see all the photographs taken, control the device remotely and intercept the images while they were about to be sent to a cloud storage.
Submitted by jesparza on Sun, 2013/04/07 - 13:52
After reading the Eurograbber report and taking into account that there were a lot of similarities with Sopelka Botnet, which I had analyzed some months before
, I decided to write a blog post about it
. At the same moment, the Rooted CON CFP was closing, so I submitted this subject and then I forced myself to research further to demonstrate that Eurograbber was just a hype. Thanks to the investigations by S21sec
there was more than enough information.
Submitted by jesparza on Mon, 2013/04/01 - 21:25
More than one month ago I gave a presentation about the NFC credit cards privacy at No cON Name (NcN), a well known Spanish security conference. It's not a new subject and, also, some researchers presented talks about it in other conferences during this year, but, until that moment, there were no proofs of concept with Spanish credit cards (at least public ones). You can take a look at the presentation here (Spanish).
As I have mentioned in some posts about this subject, NFC payments are a normal part of life in some Asiatic countries, like Japan. However, this technology has arrived this year to Spain and other European countries, supported by banks, mostly. The result is that a person could have an NFC credit card in his wallet without even knowing it. It wouldn't be a problem if data were correctly protected, but we can't assume anything in the security world and this is another proof of that.
Submitted by jesparza on Fri, 2012/12/21 - 15:51
Publication date: 2012-12-21
Description: Program based on readnfccc (by Renaud Lifchitz) to read some private data from credit cards, like cardholder, Permanent Account Number (PAN), expiry date, etc., using NFC technology. It has been tested with Spanish contactless credit cards, but can also be used with other countries cards. Take a look at this post (Spanish) and this video.
Requirements: libnfc (and an NFC reader, of course!)
After installing libnfc, just compile the code:
$ gcc nfc_creditcard_reader.c -lnfc -o nfc_creditcard_reader
Place an NFC credit card close to the reader and execute it:
botnet started life in May this year and was taken down by end of September. It has been called Sopelka
because of the path used in the distribution of binaries and configuration files, and was an odd mixture of variants of the known banking trojans Tatanga, Feodo and Citadel.
This botnet’s objective was the collection of banking credentials from European entities, mostly banks from Spain and Germany, but also Holland, Italy and Malta. In addition, it made use of different mobile components for Android, BlackBerry and Symbian phones. Symbian was the first operating system where this type of malicious component emerged two years ago.
During the botnet’s lifetime there were at least five campaigns and it’s likely that more were carried out. Of the five known campaigns, three of them installed variants of Citadel (versions 220.127.116.11 and 18.104.22.168), another Feodo, and Tatanga was the chosen trojan in the other one. All the Citadel campaigns carried the name “sopelka” (a flute type in Russian) in their download paths for binaries and configuration files, but this was not the case with Tatanga and Feodo.
Submitted by jesparza on Wed, 2012/10/17 - 18:00
Here I'm going to focus on the URI records
and their possibilities to perform actions in NFC capable mobile phones when reading this type of tags. The URI specification says that these are the supported schemes:
URI Identifier Codes
Submitted by jesparza on Sat, 2012/06/30 - 20:42
NFC is based on the ISO/IEC 18092 standard, published at the end of 2003, and it's compatible with other standards like ISO/IEC 14443 A/B (RFID) and ISO/IEC 15693 (FeliCa - Sony). As probably you know, it's a short distance wireless technology (normally < 10cm), high frequency (13'56 MHz) and low speed (normally until 424 Kbps). Unlike RFID, NFC is capable to perform bidirectional communications, and the time to establish the communication is much lower than using Bluetooth.
The aim of this blog post is not explaining how NFC works but giving some advice to setup a lab and start playing with this technology. The first thing we need is a NFC reader/writer. After looking around the most used are the following:
Submitted by jesparza on Mon, 2012/06/04 - 00:21
One month ago David Barroso
visited one online banking user. David extracted one file from his mobile phone and I picked some ZeuS files up from his computer.This was the starting point of the so-called ZeuS MitMo
When ZeuS injects HTML code it usually asks the user for the necessary TANs in order to carry out a fraudulent transaction, but sometimes this information is not enough. Some banks ask for an additional code, sent by SMS, that the user (or criminal) must enter to finish the process. Until that moment this type of authentication (two-factor authentication) was successful, but not since then. This ZeuS gang had modified the configuration files to ask for the mobile phone number too. It's not so strange, but yes using it to commit the fraud. They sent to him an SMS with a link inside, telling the user that he should install that "certificate". When the user installed it, the malicious application
began to monitor all the incoming SMSs, looking for the bank SMS and forwarding it to the criminals. This way they already had all the information they needed to make the transaction, game over.
Apart of asking for the user phone number the configuration file had other curious things. When the user visited the online banking URL ZeuS added an script element to the legitimate web page pointing to an URL, avoiding to store all the HTML code in the config file. But this is not the strange thing, it's that normally the src attribute it's an absolute URL while in this case was a relative one:
Submitted by jesparza on Thu, 2010/10/28 - 20:19
Today has been released the source code
of the Jailbreakme exploit, so maybe this explanation comes a bit late. In the update of the previous post
about this subject I knew that I was right about the overflow in the arguments stack when parsing the charstrings in the Type 2 format, so here is a little more info.
After decoding the stream of the object 13 we can see the following bytes (talking about this file):
The selected bytes are the important ones for this exploit because the overflow occurs when parsing them. Like I mentioned, the Type 2 format is composed of operands, operators and numbers, and use the stack to push and pop values. This stack has a maximum size of 48 elements. We can understand better the meaning of these bytes with this tips:
Submitted by jesparza on Thu, 2010/08/12 - 18:49
Some days ago Comex
published his JailbreakMe
for the new iPhone 4 in the Defcon 18. The interesting thing is that in order to root the device he used a PDF exploit for Mobile Safari to execute arbitrary code and after this another kernel vuln to gain elevated privileges. I've being taking a look at the PDF files
and these are my thoughts about it.
The PDF file itself has no many objects and only one encoded stream:
The stream is encoded with a simple FlateDecode filter, without parameters, and if we decode its content we can see this strings, related to the JailbreakMe stuff:
As this object seems to contain the vulnerability we are looking for we'll take a closer look to this stream and what this is for:
Submitted by jesparza on Wed, 2010/08/04 - 00:40
Some time ago I wanted to recover the deleted SMS from a friend's SIM card and I tried to find some programs to do it. After some time searching the web I found SIMCon and SIMEditor which made well the job, showing all the SMS slots, deleted and not, with the help of a SIM reader, of course. I was curious about the raw process of these programs so I search the web again ;)
First of all we'll need some software to send commands to the SIM card. I'm a Linux user so I used scriptor, contained in the pcsc-tools package. We need to know what to send and what the SIM card structure is. For this we have the GSM specification, a brief resume of the commands we must send and we can receive, and some information about the directories within a SIM card. These commands are called Application Protocol Data Units (APDU). After reading this links we know that we have to send the following commands:
- VERIFY CHV (20): PIN authentication.
- SELECT (A4): selection of the file we want to work with.
- GET RESPONSE (C0): read the response data.
- READ RECORD (B2): read the specified record.
Submitted by jesparza on Tue, 2010/07/27 - 23:06