Posts by Dr. Vesselin Bontchev100 posts • joined Wednesday 27th June 2007 04:45 GMT
This article contains the typical incompetent crap you can expect from an ElReg article. The only surprising thing is that the blame does not lay only on the stupid journo who has written it (as is usually the case) but also on the AV companies from whose blogs he has taken the info.
You see, folks, there ain't no such thing as "Android Instagram SMS Trojan". This thing is not specific to the Instagram app in any way. You see, the scam works like this.
There is a site (a whole network of sites, actually), which claims to be a repository of Android apps - mostly free ones. It's not a market, technically - it's just a site from where you can download app. The site is Russian. Why would anyone want to use a dodgy site instead of the Google Market/Play or whatever it is called this Thursday? Beats me. We're talking Russia, remember? Maybe they don't have an easy enough access to all these apps - remember, Google restricts them by country. Maybe it's too slow or expensive to connect to the genuine market. Maybe they just don't know better. Whatever.
Any time the (l)user tries to download an app from these Russian sites, no matter which app s/he has specified, s/he gets something completely different. It is actually a "download app". This app sends 3 SMS messages to premium numbers (some variants even say that they would do so, although they don't specify clearly the numbers and the costs) and then download the real app that the user has ordered. Which app it is is written in a data file inside the APK file (APK files are ZIP archives) of the "downloader app" - but the code of the "downloader app" is one and the same, no matter which particular (genuine) app the user has ordered.
In addition, random data files are added automatically to the APK file of the downloader, in to fool AV programs that depend on whole-file checksums. This is done automatically before every download of the "downloader app".
But that's not all. In addition, very often (almost every workday) the code of the "downloader app" is edited manually, some trivial changes are made in it (e.g., the classes are renamed, some lines are switched around, variables are defined, etc.) and the "downloader app" is recompiled. This is done in order to fool AV programs that checksum the file inside the APK archive that contains the actual code (classes.dex).
So, basically, the thing uses server-side polymorphism. It's a downloader and it is stupid to name it after one particular app that the original researcher has initially downloaded without thinking or analyzing the thing.
It's not really new, either. It's called FakeSMSInstaller and has been around for several months already. But since a new variant appears almost every day, some poor excuse for an AV researcher has decided that they have found something genuinely new. Not so, grasshopper!
So, you have forgotten how to read English? "These guys" have no problem reading the x86 disassembly and understanding what the code DOES. What they are wondering is what language it was originally written in and compiled from. It definitely wasn't hand-written x86 assembly.
From the looks of it, my guess would be one of the relatively less-widely used object-oriented languages. Maybe compiled Pyhton or Forth... Compiled Perl might be worth looking at, although personally I think it's unlikely.
"AV-Test reckons there were more than 11,000 strains of Android malware"?! You've got to be kidding! There are just a few hundreds of them. Apparently, the AV-Test folks do not understand what a "strain" (or "variant") is. They probably have 11,000 SAMPLES in their collection, many of which contain one and the same malware variant.
Malware sandwiches have been with us since the time of the Jerusalem virus (remember that one?).
Even more interesting (but similarly not new), some computer viruses can "mate" and exchange malicious code, resulting in new, previously unknown variants. Used to happen a lot in the MacOS (that was before Apple switched to a Linux variant for the OS of the Macs, for you youngsters out there) and the macro virus world.
But self-replicating malware (i.e., viruses) is mostly irrelevant nowadays. Most of the infections are caused by various kinds of Trojan horses (i.e., malware that does not replicate itself).
So, I'd classify this "news" item as "yet another AV company seeking attention".
Sadly, that's not practical. There are thousands of new apps or updates of old apps uploaded every day. It is not humanly possible to examine carefully each one of them before allowing them to the Market. This is precisely why Google doesn't want to do it.
Some anti-virus companies routinely download apps from there (and from many alternate markets) and scan them for malware, but since the scanning is pretty much automated, it is not guaranteed to detect everything.
In fact, even manual examination won't detect everything, as Charlie Miller demonstrated by getting his malicious app into Apple's walled garden...
You are very right about the first part - it is a big problem that the Android security paradigm does not allow the user to choose which of the requested privileges to grant to the app. (And be later able to grant or revoke any other privileges.)
Sadly, you are wrong about the second part - it is not practical to implement this without a complete re-design of Android.
While the apps in question are indeed not viruses (they are Trojans at best; no viruses for the Android exist yet, while at least two viruses exist for - jailbroken - iPhones), the existing anti-virus programs for Android do detect malware (including Trojans) - not only viruses. In particular, some anti-virus programs detected these particular apps long before Google got wise any removed them.
So, having a good anti-virus on your phone isn't a bad idea, after all. Emphasis on "good", though. Most of those out there suck.
In that particular aspect, Google is even more invasive that Apple, as far as I know. It can not only delete from your phone an app that you have installed from the official Android Market, but it can also force the installation on your phone of an app residing on this Market without your consent. Thank goodness, the removal works only for apps from the official Android Market - not just for anything that you have installed on your phone.
As far as we know, Apple at least can't force-feed you apps. Of course, maybe they can and we just don't know it yet...
Of course, there is a bright side to the force-feeding, too. One of the security companies, Lookout, has a product, called Plan B, which makes use of this "feature". Suppose you've lost your Android phone without taking any measures to protect it - like installing some security software on it. Then you can force-feed it Lookout's Plan B (all you need is the Gmail credentials for accessing the Android Market with that particular phone) and then lock it, locate it, wipe it, etc.
Correspondingly, the dark side is that if a malicious app makes it into the Android Market, anybody who can steal your Gmail credentials for your phone can force this malicious app to be installed on your phone without your consent.
While true, it only means that CarrierIQ is a user-land rootkit, not a kernel-land rootkit.
Apparently, another (or maybe the same?) publisher of dodgy scamware apps is "Miriada Production", see this:
http://www.f-secure.com/weblog/archives/00002280.html
I have yet to get a sample of the scamware, but I suspect very much that it is related to a set of scamware apps used on a group of Russian sites. They all carry a bunch of supposedly free apps, but when you try to get one of them, you essentially get a downloader, which warns you in very vague terms that it is going to send a premium SMS (it doesn't tell you how much exactly it is going to cost and it sends 3 of them) and then proceeds to download the real app that you wanted.
Those Russian apps use server-side polymorphism, though - something which, I suspect, is not possible for malware uploaded to the official Market. The code of the apps (the classes.dex file inside the APK package) is modified by hand almost every day and the data inside the APK package is modified automatically for every download.
Well, it's a matter of choice, really.
You can have a completely closed system, be allowed to run only what the system producer thinks is good for you, be relatively save from malware and be left without recourse if something bad happens (like, the producer screws up big time).
Or you can have an open system, vulnerable to malware (because it is just as opened to the bad guys too), which leaves the responsibility for your protection mostly on your own shoulders, and have freedom to run on it whatever you want (including malware) and get quick help from more knowledgeable enthusiasts whenever a need arises.
I realize that each of these two alternatives appeals to different kinds of people. Me, I'd take malevolent freedom over benevolent dictatorship any time - but not everybody might feel the same.
Define "hiding". Do you know how many processes are running on your average PC, which aren't immediately obvious? Should AV programs "warn" about each one of them too?
Not defending CarrierIQ (or the carriers pre-installing it) here - I personally think that it is a huge privacy violation - but AV programs have to be more particular than reporting anything you don't immediately see.
Not CarrierIQ. The carrier. It is the carrier who instructs CarrierIQ what data to collect and send. Yes, it is remotely triggerable (configurable, more exactly). Adding new functionality - no, but there is plenty of existing one.
The fascist government doesn't need to mandate the use of CarrierIQ. First of all, they can go directly to the carrier (with a secret court order or just with a big gun, depending on how fascist the government is) and require access to all the phone-related traffic of the victim, CarrierIQ or not. Second, the GSM phones use the A5 encryption algorithm, which isn't that difficult to crack in real-time. I've seen offers from security companies that have devices doing it within 0.3 seconds.
I guess you've missed the message that the iPhone was found to record your whereabouts and keep a week worth of information of this kind on the phone (accessible to anyone with physical access and a bit of knowledge) and send it to Apple too.
We know it very well. It IS a purely diagnostic tool. Nobody is disputing this. The problems are two:
First, in order to provide exhaustive and useful diagnostic information, it can collect vast amounts of privacy-sensitive data. (I wrote "can collect" as opposed to "collects", because what it actually collects can be configured by the carrier.) This is a HUGE breach of privacy.
Second, it tries to hide while doing so and it cannot be easily turned off. This tends to annoy people. If it had an opt-in policy (as opposed to the current no-opt-out policy), if it clearly explained what exactly it collects, for what purpose, what it sends to the carrier and how that can help the user, nobody would have had any problems with it.
Also, it is a bit unfair that CarrierIQ gets all the blame. After all, they are just a software company making a diagnostic tool. This tool does exactly what their customers - the carriers - want. People should direct their ire towards the carriers who have been shipping it pre-installed, instead. Why aren't they telling their customers what kind of information they are collecting on them and why there is no easy way to opt out?
Ah, you are mistaken. It doesn't use any undocumented Android functionality. The reason why it cannot be removed (without rooting the device) is because it comes pre-installed by the carrier and resides in an area of the device's memory to which the user doesn't have write access on a non-rooted device. it is no more and no less difficult to remove than any of the other pre-installed apps.
Some of the questions raised in the article are relatively easy to answer.
1) Why are some AV companies reluctant to label Carrier IQ as malware and, most importantly, add detection of it in their main scanners and even if they do implement detection, they do it in a separate app? Well, dunno about Kaspersky, by Lookout comes pre-installed by several carriers on their phones. Most of these carriers also pre-install CarrierIQ. Imagine now if the pre-installed malware scanner starts reporting out-of-the-box that the phone contains malware. What will happen? The carriers will drop the AV product, of course - leading to financial losses for its producer. Ergo, the producer isn't going to do detect CarrirIQ as malware with its main product.
2) Why don't they offer removal? CarrierIQ comes pre-installed by the carrier, which means that it resides in the firmware, among the other pre-installed apps. The only way to remove any of those is by rooting the phone. A security company can't afford to do this routinely on the phones it processes - or its own product would be classified as malware by some.
3) Why weren't the AV products detecting CarrierIQ heuristically, using the fact that it requires many dodgy privileges? Unfortunately, Android's privileges are not granular enough to be usable as a base for good heuristics. By this I mean that you can't easily pick a set of privileges and say that if an app requires, then it is suspicious. There has been a rather deep study of this issue (an AV company comparing the privileges used in the known malicious and in the apps on the Android Market) and the conclusion was that it is not possible to determine the maliciousness of an application from the set of privileges it requires.
While it is true that there are snake oil salesmen in the mobile security business (which field of business doesn't have them?!) - like scanners with pitiful detection rates and overblown estimates of the number of Android malware programs out there - this DiBona chap is so full of it that it's not even funny.
Smart phones are not "inherently more secure than PCs". Just like with the PCs, the weakest link is the user. The user would install anything from anywhere without ever stopping to think. And it's kinda difficult to protect people from themselves, you know? No solution is fool-proof, because the fool is always bigger than the proof...
Mobile malware hasn't caused "much of a problem"? OK, let us assume, for the sake of argument, that it has hit only ONE user (in reality, thousands have been hit, but humor me). That certainly wouldn't be "much of a problem", compared to the millions of smart phones out there, right? Now, stop and think for a moment. What if that ONE user was YOU? Do you still think that protection for mobile devices is useless because malware "isn't much of a problem"?
No major cell phone has a virus problem?! I guess, he doesn't count Nokia as a major brand of cell phones, then. In the early days of Symbian (S60) - the OS that most Nokia smart phones used - many mobile viruses spread accross such phones over Bluetooth and MMS.
Regarding the "no Linux desktop has a real virus problem" crap, with the risk of being flamed by all the Linux fanbois here, I'd say that it again depends on how you define "no" and "a real virus problem".
One more point regarding the "snake oil salesmen". Please note that many (most?) Android security vendors offer their scanners for FREE and only sell for money their other, non-malware related cervices, like backing up the information on the phone into the cloud, tracking the phone, locking the phone and so on. You can hardly call a "snake oil salesman" somebody who is giving you their product for free. Or is Mr. DiBona actually claiming that the other security services are worthless?!
Now, speaking of worthless and incompetent stuff, how about a long and hard look into the Android security model, huh?
1) Android, out-of-the-box would install and run any signed app (if configured to use alternate markets). Signed by anyone, I mean. As opposed to that, the iPhone would run only apps signed by Apple. That's not necessarily a good thing - personally I'd take malevolent freedom over benevolent dictatorship any time - but it does have a negative impact on security.
2) Android is plagued by bugs, exploited by the various rooting exploits, the fixes for which take ages to reach the end user. This is not only Google's fault - much of the blame falls on the mobile operators - but fact is that Apple's model provides better security in this aspect too.
3) Android has the same user-incomprehensibility problem that has plagued the Windows security software for ages. You download an app. It tells you that it requires X, Y and Z rights. The vast majority of people have absolutely no clue what these rights really mean and why the app might need them. Android's description of them is pitiful. The responsibility for making a correct security decision is dumped entirely on the user. In such a situation, most users will fail to make the correct decision.
Why is it not possible to grant only some of the rights that the app requests?!
Why is it not possible to change later the rights granted to an installed app?!
1) While occasionally malware has made it into the Android Market, the vast majority of such malware comes from alternate markets and stand-alone APK files distributed by various Web sites.
2) If malware has been installed on the user's phone from the Android Market, Google has the capability to remove it from there without requiring the consent of the said user. Remove it from the user's phone, I mean - not just from the Android Market. However, this capability is not present, if the malware has been installed from alternate sources.
3) Lookout is exaggerating a bit, IMHO. The known variants of Android malware are about half of what they state. 400+ - not 1000.
4) It is most definitely not true that the Android applications store model "lacks signing". Just the opposite - every app must be signed, or it cannot be installed on a non-rooted device. The problems are elsewhere: (a) the apps are signed by their producer, not by Google (for comparison, the iPhone apps are signed by Apple) and (b) there is no review process. Arguably, the app access rights model is also flawed. It relies on the user being able to decide whether to install an app that requires specific rights. Most people don't even understand what these rights mean and just allow them. In addition, there is no way of granting only some of the requested rights to the app and later granting more rights or revoking some, if necessary.
"Android Malware "problem" is being vastly over-exaggerated."
Percentage-wise, the Android Malware problem is growing faster than any other malware problem. While there are no viruses for this platform yet, the number of new Trojan horses discovered has reached in the range of several per day (on average). Given that there were just a handful in existence about a year ago, this is tremendous growth. And it is just a matter of time until a full-fledged worm appears. (We have botnets already.)
"The bottom line is if you have left that "allow non-marketplace apps" tickbox unticked, and you quickly check the app permissions and download count before installing, then you have nothing to fear."
You are very much mistaken here. First of all, there have been several cases of malware appearing on the "official" marketplace (and Google had to pull it very fast). Second, there are ways to bypass the permissions protection by using already existing apps. For instance, a malicious app might not request the permission to access the Internet, yet still do so by using an already installed browser app that can act as a server.
"The only people saying otherwise are those trying to sell you an app to protect you."
The test was of FREE protecting apps, in case you haven't noticed. The results sound about right, too - in the AV business, when you get a free anti-virus program, you usually get what you pay for. (Sadly, the opposite is not necessarily true - buying a paid AV program doesn't guarantee you quality.)
I wholeheartedly agree with your remark about iOS, though.
Of course not. We, the anti-virus people, are not dumb users. We have special, in-house developed tools for extracting of such information.
"The features include steganographic processes that encrypt stolen data and embed it into image files before sending it to attacker-controlled servers, an analysis by NSS researchers found."
Actually, if you bother to follow the link to the NSS report, you'll see that its authors, being knowledgeable researchers, don't use the word "steganography" at all. And rightfully so, because Duqu doesn't use it. Obviously, the ElReg reporter has heard the buzzword from somewhere, has half-understood it, hasn't even looked at the Duqu code, and has decided to include this buzzword in his article to make it more "juicy".
What Duqu does, is APPEND (not "embed") the collected and encrypted information at the end of JPG images. The reason for this is to conceal the fact that it is sending such information from casual observers of the 'net traffic. However, if somebody is actually LOOKING for this info in these JPG images, it is blindingly obvious that it is there.
As opposed to that, when REAL steganography is used, the information is encoded by toggling single bits in the image. If it is done right, it is practically IMPOSSIBLE to detect that hidden information is present in the image, unless you have the original image to compare it with. Calling what Duqu does "steganography" is like calling wearing sunglasses a "professional disguise".
As for the similarity between Duqu and Stuxnet, it is more appropriate to say that one of the components of Duqu is very similar to one of the components of Stuxnet. But the similarity ends here.
Facebook has absolutely nothing to do with this. As usual, the journalists (not just ElReg's) reporting a technical issue have screwed up.
My guess is that the only one of the people mentioned who is playing Mafia Wars on Facebook is the "anonymous defence official" - the source quoted by Associated Press. And since "military installation hit by Mafia Wars virus" sounds sexy, all the stupid journos have jumped on the bandwagon.
In reality, the computers of the drone program have been hit by a keylogger. A keylogger logs whatever the user types - usually as login passwords to web sites. Yes, it could be the password to your Mafia Wars account. Or to your GMail account. Or your bank account (which is usually the real target). Or whatever.
It does not mean that you are playing Mafia Wars on that computer. Or that you're using it to check your GMail account. Or to do Internet banking. The only thing it means is that your computer has been infected by a keylogger.
Which is, actually, much worse. If one of the infected computers is used to login to a classified account without using anything besides a user name and a password (e.g., smart card, a biometric scanner or whatever), the attackers now have access to that classified account.
How did the military get infected? Certainly not by playing Mafia Wars. Most likely, the infection came from an USB drive. The drone pilots often bring updates to maps, etc. on USB drives.
Why wasn't autorun disabled on these computers? Incompetence.
"How is it targeted?"
It isn't. Doesn't have to be. It's a Trojan, remember? Not a virus. It doesn't spread by itself. It has to be installed on the computer of the victim.
"Any electronic equipment that is taken out of your sight by German customs must be assumed to be compromised."
The-he-heee... They could always try. As long as Germany doesn't outlaw encryption (like France) they will fail. The best they could do is to boot from an external medium (and that won't be easy, either - they will have to bypass the BIOS password) and instal either an MBR or a BIOS rootkit. Which I'll detect during the proper boot process. ;-)
"Better not have any commercial confidential information on it either - clean it before travelling."
Better have it properly protected.
"Basically treat travel to Germany like travel to the USA."
Trust me, it's nothing of the sort. German security is generally polite and competent.
Not being an expert in German law, I cannot comment on whether the use of commercial spyware is legal or not. However, being an expert on malware, I can confirm that this particular commercial spyware is shoddy and sloppily written. It's not worth 100 euros, let alone 2 million... Gosh, I'm in the wrong business... :-(
"You suggest it's appropriate that expats and workers overseas be required to spend time and money traveling simply to register the change of a phone number?"
Indeed, it is a problem for such people. But do you see a better solution?
"it's time for the banking industry to step up and take an honest look for ways to rectify the problems."
Like, how? Security theory suggests that both sides should authenticate themselves to each other - i.e., the bank should be certain that it is talking to you, and you should be certain that you're communicating with the bank. But how to achieve this if you communication channel is compromised? Public-key encryption can do that only if the channel provides at least authenticity during the key exchange (confidentiality of the channel is never needed and authenticity is not needed after the key exchange). But if the channel is completely compromised, you can't have even that and you get man-in-the-middle (or man-in-the-browser) attacks.
The best the banks can do for now is use and additional, out-of-band channel (the phone). But if that's compromised too, all bets are off.
One solution is to perform the initial key exchange in person, when you're opening the bank account. But that, too is vulnerable. People will fail to safeguard access to their secret key, malware will modify the transactions on-the-fly, as I explained above, and so on...
"Either that or banks should become liable for the "unusual transactions" to money mules which are at the heart of the fraud involving commercial accounts."
In many countries they already are, if you complain on time. I mean, if you regularly check your account and complain to the bank about any unusual transactions you did not make, the bank will restore you the lost money.
"The use case of infection of home computer and mobile is what you are talking about, right?"
Correct. As I said in my message describing this issue, the mobile malware components are Trojans, not viruses. They don't spread on their own. They are dropped by other malware that has already infected your computer.
"So the real failure here is that the bank allows the addresses used by the of the out-of-band confirmation mechanism to be changed by in-band messaging, which the crooks then intercept!"
This isn't quite true - the bank uses the same out-of-band channel to confirm that you are changing phones that it uses for confirming that it's really you entering your password.
But this, of course, is correct:
"They should require an actual office visit for setting or changing the phone number used for verification."
I don't know which is the bank that is being attacked by this. "As is", the attack won't work against the bank I use. They require the entering of an SMS-received code at the very first step (logging in) - not when you've already logged in and have requested to change your registered phone number. But this is just a technicality - it is trivial to adapt the attack, so that it works in this case, too. Plus, my bank requires an out-of-band confirmation only at login time, not for every transaction, which is a definite minus.
There are viruses which do not attempt to steal your credentials but, instead, simply modify on-the-fly the transactions you are sending, so that when you think that you have just instructed the bank to send $100 to Alice, it has actually received a command to send $10000 to Bob. (They even modify on-the-fly your balance, as shown by the bank's site, so that you don't see that more money than expected have disappeared.) In such cases it would be useful to receive from the bank an out-of-band communication about how much money and where you've just sent.
On the plus side, if I want to change my registered mobile phone number, my bank requires me to appear there in person and to sign a form.
Nevertheless, Alan's point stands. In fact, since I know him personally and he is quite a competent anti-virus researcher, I am surprised that he hasn't realized that the kind of malware he is "predicting" has already appeared - and quite some time ago, too.
The first one that I remember - and I might be wrong on this, in the sense that there might have been an even earlier one - appeared more than a year ago. It was a mobile component distributed by one of the Zeus Trojans. I think we called it Zitmo. It was for Symbian phones and did precisely what Alan is predicting - stole the out-of-bank SMS message sent to your mobile phone (infected with it) by the bank and sent it to the attacker.
Recently a similar mobile component (they are both Trojans; not viruses) appeared for Android phones, too. We call it Spitmo and it was distributed by another SpyEye variant.
As usual, ElReg's journalist has not understood what is really happening and, as a result, his article is incomplete and confusing. You are strongly urged to read the original blog post, in order to understand the situation.
I mean, by reading just this article, we are left wondering - what would be the point of the attacker telling you that you have been "assigned a new phone number", the SIM card for which never arrives? This, by itself, does not divert the communication from the bank to a phone controlled by the attacker, because the bank will keep sending you the one-time passwords to your original phone.
In reality, this is how it is done. First, the attacker steals your bank credentials - user name and password. Second, he enters your bank account and tells the bank, on your behalf, that you are going to switch to a new phone. In this case, the bank requires a confirmation from you, by requiring you to enter a one-time password sent to your OLD phone.
Meanwhile, the attacker has told YOU that you are being assigned a new phone number, blah-blah, and in order to "activate" it, you have to send to IT the "code" that is going to be sent to you by your bank shortly.
So, the bank sends you the code you are supposed to enter as confirmation that you are changing phone numbers, you send that code to the phone number indicated by the attacker, thinking that you are "activating" it, the attacker receives the code and enters it on your behalf into the form on the bank's site, in order to confirm that "you" are switching to a new phone number. Presto, the attacker has replaced your phone number with his in the bank's database.
It is riskier than usual for the attacker, though, since it leaves traces in your phone's logs of a phone number owned by the attacker. That can be traced, so the attacker has to take additional steps to prevent that.
It is surprising how few people understand how bitcoins really work. It is not, however, surprising to see yet another ElReg journalist demonstrate his incompetence. Let us get the facts straight, shall we?
1) If somebody has the standard Bitcoin client installed on their machine, any malicious program that has invaded the machine can steal all the bitcoins there without any effort at all. No "lockpicking", "drilling" and "sawing" is involved, since the present version of the client does not encrypt the wallet with the bitcoins yet. (That's planned for the next version.) Theoretically, one could install the wallet on an encrypted partition, but few would bother, and even if they do, the partition has to be accessible (i.e., decrypted on-the-fly) at the time when the client is working, so nothing prevents the malware from stealing the wallet then.
2) A botnet client designed to mine bitcoins can do this on ANY infected machine. The owner of the machine doesn't need to have any bitcoins there. In fact, the owner isn't required to even know what bitcoins are. What the malware would be stealing in this case wouldn't really be bitcoins (although this is what it would be sending to the botmaster) but computing time.
Many AV companies have already published AV packages for the Android platform. Many of them are free, too, and can easily be found on the Android Market.
As practically all of John Leyden's articles, this one is just a rewrite of a posting to the blog of an AV company - Lookout Mobile Security in this particular case. And, guess what, LMS publishes an AV package for Android. ;-)
"If you use Bitcoins, you have the option to encrypt your wallet" - that's a bit misleading. The present version of the officieal Bitcoin client does not have the option to encrypt the wallet. Silly, isn't it? For a developer of a crypto currency to keep the wallet unencrypted... All you can do is create an encrypted disk partition and tell the software to keep the wallet file there - which is rather inconvenient.
BTW, how do you call a pickpocket who steals your Bitcoin wallet? A "bitpocket"?
"Google makes no promises to vet the security of apps hosted in its own store" because that is impossible. Apple can't do it for the apps hosted on their market, either - Google is simply being more honest about it.
It is possible to design a program in such a way, that it will start performing malicious actions after receiving an external signal and no amount of testing will be able to reveal that it is capable of doing so. Even careful reverse-engineering of the program will only reveal an encrypted area which the program itself has no means of decrypting. The idea is not even new - it was conceived in 1998 and there are even some viruses for the PC that implement it (albeit poorly). Search for "clueless agents" to, uhm, get a clue.
True, execution of decrypted code is more difficult to implement in Java, especially with code signing, than it is in assembly language - but combining that idea with the "interpreter" idea mentioned in the article makes it perfectly possible.
There is no need to disable the ability to access the USB. It is enough to disable Autorun and Autoplay.
1) AV scanners have been encrypting their malware detection databases for the past, oh, 25 years.
2) WinPatrol is not a scanner; it's a behavior blocker.
3) The "artemis" part of the report from McAfee's scanner suggests that the file was detected by their Artemis in-the-cloud scanning engine. That engine doesn't use "signatures" (i.e., scan strings). It uses cryptographic hashes of the whole file. Therefore, WinPatrol's installation package was not reported because McAfee's scanner mistook it for some other (malicious) file - it was reported because somebody at McAfee has added (erroneously) this particular (WinPatrol) file as a malicious file to detect - probably because they didn't analyze it carefully enough.
This is nothing different than when polymorphic viruses started using the instruction of the numeric processor (the FPU) or when they started using Windows API calls in their decryptor. It just means that the emulator of the scanners has to be improved to handle the new set of instructions, too.
So, for this trick to work, the malicious code that does it has to be run in the first place, right? 'Coz if it isn't run, it won't do a thing - neither this trick, nor anything else.
Hello? Ever heard of on-access scanners? Those are programs that run on your machine all the time and scan every executable you try to run (or even access). Either it is malicious, or it is not. If it is not - no worries. If it is malicious, either it is known to the scanner, or it is not. If it is known to the scanner, it won't be allowed to run, period. So, no worries, it doesn't matter what it tries to do.
If it is not known to the scanner, it will be allowed to run. This is bad news. But how is this trick relevant? First law of computer security: if you run the bad guy's program on your machine, it's not your machine any more. Once running, the malicious program can do ANYTHING without resorting to this trick at all. It can deactivate or delete the virus protection, it can destroy files, it can sniff data - ANYTHING.
Ergo, this trick is totally irrelevant.
"MessageLabs security team was the first to stop and name LoveBug" - no, they weren't:
http://www.f-secure.com/weblog/archives/00001946.html
"Crucially, a security shortcoming of the time means the final .vbs extenuation was hidden by default from Windows users" - of the time?! Well, the time is now, 'coz it's still there.
"The worm used infection routines written in VBScripts" - VBScript, not "VBScripts".
I don't care about Apple's products, but Flash is evil and should be purged from the Web. I use a plug-in for Firefox that disables Flash on the Web pages.
Do you folks *really* want to run just about any unapproved application on your phone? Including a malicious one that is a virus and/or makes phone calls without your knowledge? It's bad enough that even approved applications sometimes do that...
"A virus signature is a hash of a variable length string."
No, it is not. It is clear, that you have no clue how virus scanners work. Your knowledge on this subject is outdated by some 15 years.
"Isn't it patently obvious by now that Anti-Virus software doesn't work."
No, it is not. You falsely equate "Anti-Virus Software" with "virus scanners", you assume that a false positive every few months means "doesn't work" and you seem to think that using virus scanners against the current threat landscape is considered a proper line of defense. I suggest that you leave the anti-virus stuff to the anti-virus people and concentrate on something you actually know something about.
"A better solution is a core OS that only allow a whitelist of approved apps to run."
Aw, really. And who is going to approve them? The user? S/he will approve malware in a snap. The security administrator? Guess who's the secadmin for the home machine? Some kind of central entity (like a whitelist-producing company)? There are a few and they admit that the number of known good progras is SEVERAL ORDERS OF MAGNITUDE larger than the number of known malicious ones.
If there was an "easy" solution to the malware problem - don't you think that somebody would have come up with it by now??
I'm sure the Millenium Falcon could make this run in less than 12 parsecs.
BTW, "Endor" isn't the name of the Ewoks' moon - it's the name of the *planet* around which this moon orbits.
If we implement detection of some sample based solely on the fact that XYZ's scanner detects it, we're being accused of not doing proper analysis and copying other company's detection. If we don't detect the sample because our analysis has shown it is obviously not malicious, it gets into the testes' test sets and our detection rate in the tests is lowered. When we protest, we're being told that "but half a gazillion other products already detect it".
Welcome to the world of anti-virus research, where your only choices are bad ones and worse ones.
AV software became "basically completely useless and ineffective" about 5 years ago, when the malware threat landscape switched from viruses-written-for-glory to Trojans-written-for-money. Nevertheless, we can't "fix the problem at source" without making the computer unusable. Any general-purpose computer will be plagued by malware, as Dr. Fred Cohen proved mathematically almost a quarter of a century ago.
Of course, the my-OS/browser-is-better-than-yours morons have never bothered to acquaint themselves with his works. It's much easier to blame the evil AV software producers.
1) Hackers aren't "targeting jailbroken Jesus Phones". It's just that only jailbroken phones will run programs (including malware) not approved by Apple - and Apple isn't going to approve malware, at least not knowingly.
2) Yes, most people are idiots.
3) Change your password, eh? How long before a worm appears that tries to crack it by using a list of common passwords, like the Morris Worm did, oh, some 30 years ago?
"MS claims early success for freebie security scanner"
What did you expect MS to claim? "Our product was an abject failure"?
"Redmond estimates 1.5 million users downloaded its freebie security scanner software during its first week of availability earlier this month."
But how many of them will still be in use the next month?
"Windows XP machines were more likely to be infected than Vista boxes which, in turn, were more bug-filed than Win 7 machines."
Of course. There are many more XP machines than there are Vista machines - and of the latter there are many more than Win7 machines.
"Measured and non-partisan"? Fox?! Ho-ho-ho.
@Dr Patrick J R Harkin: "SysConst.pas is a source code file on a development machine, I'd expect the logged in user to be able to edit it regardless of whether they have admin rights or not."
Haven in mind that:
1) Development has nothing to do with this. The file SysConst.pas is the source code of one of the libraries. Developer or not, there is no need to modify this file yourself - ever.
2) If Delphi is installed by the admin and the user is running with non-admin privileges, the (infected) user won't have the rights to modify this file (which will be owned by the admin), if the system is properly set up. Note that this also means that the user won't be able to update Delphi.
3) Using ACS, it is possible to deny write access to this file to all - including to its owner (admin or not). Again, this means that Delphi won't be able to update itself. In addition, the owner (or a virus running with his credentials) will be able to re-enable write access to the file - but this virus doesn't try to do so.
@ProductMan: Aw, cut the spin, man! First of all, don't take the author (John Leyden) too seriously. He's just yet another incompetent moron who hates the AV industry but is too stupid to write something creative and instead copies stuff from the blogs of the various AV companies.
Yeah, this is just yet another silly little virus (buggy, too) - the only unusual thing is that it is, in a sense, a "compiler infector" instead of the usual variety of application infector. But even that is not original - there have been similar things for C (I think) years ago.
"we at Embarcadero take threats of this nature very seriously" - aw, gimme a break, man! Whatcha gonna do, seriously, huh? A grand total of NOTHING. There is absolutely nothing you can do about threats like this (besides posting silly comments like that, I mean). You can't change anything in Delphi to make it more resistent to such viruses, you can't force people not to run as admins, you can't make the Delphi developers more security-conscious. So, just relax and enjoy the fun.
"This is a programming and compliance issue" - no, it's a security issue. If you let your system become infected, you're running the risk of infecting others (like, your customers). Surprise!
"The best ways to combat these types of issues are to establish a deployment protocol that checks for viruses and trojans before shipping any applications." Nonsense! This thing has been around for more than a year and it is only now that the AV programs have started to notice it. You could have scanned your applications before shipping them all you wanted - and you still would have shipped them infected.
Instead, people should try to ensure the integrity of their development systems. Don't connect them to the 'net and don't play games on them (duh!). Don't have any foreign executables on them besides the OS and the compiler, transfer the sources there and compile them there. Run some kind of integrity checker to make sure that your compiler distribution hasn't been tampered with. That sort of stuff.
Now, everybody, take a deep breadth and relax. This is another three-day wonder. In a month, everybody would have forgotten it.
