The german hacker club CCC claims that they found a trojan malware used by german federal police (german source).
It seems that the software has many security issues and, even worse, has abilities which are illegal under german law.
The interesting question is now: Does it really originate from german authorities? Of course they deny that. And if so, how would one prove that? It seems that the trojan uses command servers outside of germany. At the moment it is unclear who operates these machines.
I do not expect that this will ever be resolved completely. It's way too embarrassing.
Update: The Bavarian Government accepted responsibility for the trojan. Antivirus vendors claim that it would be caught be heuristic malware detectors. Looks like there is an egg on someone's face.
Showing posts with label vulnerability. Show all posts
Showing posts with label vulnerability. Show all posts
Monday, 10 October 2011
Monday, 8 November 2010
ZeuS uses unpatched IE exploit
The Eleonore toolkit, which is the tack vector for the ZeuS malware, got support for the
recent CSS vulnerability of IE 8 which is still not fixed. This means that there will be more broken webservers distributing the exploit and bigger damage to affected users.
recent CSS vulnerability of IE 8 which is still not fixed. This means that there will be more broken webservers distributing the exploit and bigger damage to affected users.
Position:Zeppelinstraße,München,Deutschland
Tuesday, 28 September 2010
ZeuS attacks m-TAN
ZeuS e-crime toolkit now supports man in the mobile also. It seems that the malware on the PC tricks the user into installing malware on their phone with a classic social engineering manipulation.
The fraud is then straightforward: The trojan on the PC starts a transaction, the telephone malware grabs the m-TAN confirmation message and forwards it to the malware on the PC where the fraudulent transaction is completed.
This will become increasingly dangerous with the success of smartphones, which allow more attack vectors, in particular if the telephone is regularly connected to the PC, e.g. for synchronizing or charging.
I have written about this problem already one month ago.
Labels:
android,
e-crime,
mobile phone,
TAN,
vulnerability
Sunday, 15 August 2010
Smartphones Not Ready for Mobile TANs
In the last weeks we had an outbreak of security issues with smart phones. The most famous was the pdf font bug that hit the iPhone and other iOS devices which was fixed by Apple with iOS 4.0.2. This one was really dangerous because it could infect iPhones just by opening an infective web site.
Then we had a rootkit for Android phones. A first criminal exploitation was a Trojan, also for Android, that sent text messages to premium numbers.
Of course there is much more. The reason for this is, of course, that there is no magical security for telephones. Old-style telephone-and-SMS-only phones were simply too dumb to be hacked (if we disregard the occasional bluetooth hack). Modern smartphones are normal computers that happen to contain a radio baseband chip.
However, we have that security feature M-TAN or Mobile TAN for online banking. When a M-TAN user has entered their transaction into the online banking website, they get a SMS with some details on the transaction and the M-TAN number. If the details of the transaction look good, they enter the M-TAN into the web site to complete the transaction.
So, here is the criminal master plan:
- own as many PCs as you get
- own as many smartphones as possible
- match smartphones and PCs
- start phony transactions on the PC
- capture the resulting SMS
- send the M-TAN to the Trojan on the PC
- Profit
Sounds complicated, but if everyone has a backup of their smart phone on the PCs step 3 should be quite easy and the only remaining issue for the criminal is whether they find enough matches so that the plan is worth the effort.
A promising version of this plan would be to attack the smart phone via the infected PC. In iPhone speak this would be called the "trojan jailbreak". If this can be done without the user noticing it, the M-TAN is completely broken.
I don't recommend using M-TANs on a smartphone.
Labels:
android,
apple,
e-crime,
malware,
mobile phone,
real world,
vulnerability
Friday, 12 February 2010
EMV Broken by Inventing Card Response
EMV user verification uses several methods, one of them is a PIN entered by the user. However, please note that this proves the user identity to the card, not to the terminal. If no-one checks the security state of the card, this is pretty pointless. They simply catch the verification request sent to by the terminal to the card, throw it away and reply with a code that means "PIN was OK".
So what now? Actually, the responsibility for a correct transaction is with the merchant, because only the merchant has at least a possibility to ensure a correct transaction: If a proper terminal is used and there is no strange cable coming out of the card (see the video on the linked page) the transaction is still good. However, the damage goes to the customer, not the merchant.
And, of course, there is a huge hole in the protocol.
There is only one way to do it properly:
- User enters PIN
- Terminal asks card to sign the transaction
- card signs the transaction if and only if it has received the correct PIN
And everything done with mutual authentication end, message confidentiality and message integrity.
Where is the problem with this? It requires chips that are a little more expensive than the most simple ones. It's called "dynamic data authentication"and "Transaction Cryptogram" in the EMV world, but unfortunately it is not used in this case.
Tuesday, 19 January 2010
The Missing Bus Error
Apple was slammed for not fixing an exploitable bug. That made me curious and I compiled and ran the following:
#include
#include
int
main()
{
char s[]="111.111111...11";
float a=atof(s);
printf("%f",a);
}
which is said to cause a bus error. However:
Opportunity:misc ullrich$ gcc -o buserror buserror.c
Opportunity:misc ullrich$ ./buserror
111.111115Opportunity:misc ullrich$
on my trusty MacBook, which looks more like a rounding error to me. Maybe they just fixed it - I use 10.6.2
#include
#include
int
main()
{
char s[]="111.111111...11";
float a=atof(s);
printf("%f",a);
}
which is said to cause a bus error. However:
Opportunity:misc ullrich$ gcc -o buserror buserror.c
Opportunity:misc ullrich$ ./buserror
111.111115Opportunity:misc ullrich$
on my trusty MacBook, which looks more like a rounding error to me. Maybe they just fixed it - I use 10.6.2
Tuesday, 29 December 2009
Legic Prime Has No Cryptography at All
This is really weird: Karsten Nohl and Hendryk Plötz have shown that the Legic Prime contactless smart cards neither a random generator nor an encryption algorithm. Users of Legic Prime are recommended to upgrade to Legic Advant which contains AES and is compliant to FIPS 201.
Heise article (german)
Heise article (german)
Monday, 16 November 2009
"Anomalies" in Spain Speed up EMV Transition
It's not really clear what has happened there. It seems that massive amounts of credit card data were lost at a spanish credit card processor. New cards are sent to customers. At least some of these actually have an EMV chip. Another nail in the coffin of the obsolete magnetic stripes.
Update: Tonight it was in the news: more than 100 000 cards have been exchanged.
Saturday, 29 August 2009
MacOS X is not Invulnerable
Apple has fixed a nasty longstanding bug. This bug seems to enable user space programs to overwrite arbitrary locations in the kernel memory. The impact of this depends on how easy it is to guess the location of the target. A technique called Address Space Layout Randomization is expected to help here. Attackers need to guess the location of target variables or code for many computers in order to create a worm or rootkit that spreads using this vulnerability. However, it seems that the kernel memory is not randomized so all macs prior to the latest version of Leopard are vulnerable.
Subscribe to:
Posts (Atom)