Bogus Firefox add-on FORCES WITLESS USERS to join vuln-hunting party Cybercrooks have brewed up a botnet that uses a bogus Firefox add-on to scan the web for hackable websites. The so-called Advanced Power botnet runs SQL injection attacks on websites visited from infected machines. The malware, disguised as a legitimate add-on for Mozilla Firefox, found its way onto 12,500 systems, reports …
@Renan "C#" Sousa
I couldn't agree more. I've been using prepared statements and parameters for at least 10 years, so imagine my astonishment when I recently started a new contract and discovered that they're still building SQL using string formatting and concatenation.
Most of what I've done up to now has been in Java, and this is the first time I've seen a C# team at work. Your handle suggests that you may know if this is usual in the C# world, or whether I've just landed among a bunch of dummies.
(Anon for obvious reasons)
"...you may know if this is usual in the C# world, or whether I've just landed among a bunch of dummies."
Cowboys are endemic rather than technology specific. Unfortunately there are many within our field with an axe to grind in favour of some specific language or OS, which distracts from the larger problem caused by there being too many people who wrote their first programs for money rather than their own learning & entertainment.
@Anonymous Coward I've worked with a lot of people, and I see that this is common mostly among two groups: kids and college undergraduates who have just learned programming and have never done anything more complex than a personal site, and people who are still die-hard Fortran or COBOL coders who struggle with "new" technologies - "new" in this case being anything that came to existence after the internet was invented.
When I was in college we would sometimes make workshops and such other things, and those were open to anyone to come and participate. We would show people what an SQL injection vulnerability was, and how to defend against it. One of my favorite activities was having the freshmen count how many people made desperate calls or went running back to their offices as soon as went from theory to practical demonstrations. On sites from local shops. For academic purposes.
Your handle suggests that you may know if this is usual in the C# world, or whether I've just landed among a bunch of dummies.
Officially, it's considered bad practice. C# experts would recommend LINQ for ad hoc queries (rather than composing SQL directly in the application), and those who know what they're talking about would recommend stored procedures for everything else.
But as others have pointed out this is a problem regardless of language. It might be more prevalent in programs written in some languages: COBOL dialects that support EXEC SQL thereby encourage inline SQL (though it's less vulnerable to injection than the string-formatting-and-concatenation approach), for example, and for PHP there are still far too many books and reference sites that teach inline SQL. But I'm sure you can find people doing it with pretty much every web-back-end language you can think of.
By my guess, based on the corporates I've worked for down the years, I'd say that half of intranet/internet sites are vulnerable to some for of basic manipulation (sql/javascript injection or cookies).
Its a stupid state of affairs and ultimately does our industry no good - imagine if half the products you bought were defective in some basic and obvious way. Unfortunately, corners get cut due to time contraints, and the industry lacks a ready means of ejecting the cowboys.
anyone who is still making sites that are vulnerable to SQL injections these days is just asking for it
Yes, it's inexcusable; but OWASP just updated their Top 10 list this year, and injection attacks are still at #1.
Leyden's casual "unguarded sites" really isn't an accurate description, either. While cleaning input from untrusted sources is necessary, as others have noted below, SQL injection can and should be prevented by designing and implementing the Data Access Layer correctly, with parameterized prepared statements. This isn't a class of vulnerability a web application needs to watch for, if it's built correctly in the first place.
I'm teaching a university course in web design next semester, and I've thrown out the "building SQL queries" part of the syllabus. These students will work on front ends - there is absolutely no reason for them to write code that talks directly to the SQL engine. Now, if they subsequently want to go and learn how to create a DAL and write SQL stored procedures, that's another story; but I'm not going to train them in bad architecture.
This one piqued my interest as FF plugins are generally (but not always) cross-platform and the thought of cross-platform malware is pretty horrible! It is not clear if this one really is cross-platform. I guess the fake "Microsoft .NET Framework Assistant" would stick out like a sore thumb on a non-Windows box (as the real one wouldn't even install there) but anybody who downloads dodgy plugins without checking is probably not going to notice that. The fear here is that a more savvy version of this could be cross-platform; could disable the browser's blacklisting feature or prevent its blacklist from being updated and could lodge on a lot of non-Windows machines where scanning for desktop malware (as opposed to server exploits) is often considered unnecessary and hence would not get detected. Maybe it is not as easy as that? Any thoughts?
First, Firefox addons are not actually executable files; they're scripts constrained within the browser's ecosystem, and thus can only access certain features and functions. I'm certain that accessing the blacklist controls would be one of those functions that Mozilla have ensured that addons cannot affect for obvious reasons.
Bear in mind that addons are intended, and permitted, to ultimately do only one thing: to modify the user experience of websites displayed in the browser. SQL injection falls within this purview, since in practice SQL injection is merely the submission of search terms to a web form. In this, its behaviour is similar to an addon (I forget its name, probably TrackMeNot or something like it) that salts search engines with random queries to throw off search profiling. The addon itself isn't actually a real trojan in the same sense as, say, Zeus or or Conficker, because it doesn't run independently of the browser and doesn't replicate a trojan's behaviour. All it does is send SQL injection queries to any web forms it finds, just as anti-profiling addons send rubbish search queries.
What this amounts to is that because of the way addons are constrained within the environment imposed by the browser, it's simply not possible for an addon to be as invasive or potent as a free-running executable installed on your system. It could not, for example, modify the registry, alter firewall settings, or affect operating system files outside of the browser environment.
Theoretically, an addon could be created that, for example, captures anything you type into a webform and echoes it to a scammer's server, potentially allowing the keylogging of your banking details; but such addons are very quickly spotted and eliminated, because this behaviour follows a known malware heuristic. That's why you don't see such addons in the official repository; it's probably got to the point where even the most hardcore crooks don't even bother trying.
This addon escaped immediate detection precisely because it doesn't follow common malware heuristics such as keylogging or DDoSing; all it does is send search queries to the same website the browser is on, which isn't malware-like behaviour. It's actually a testament to the ingenuity of the crooks behind it to think of designing one that worked this way - which indicates that they're already aware that trying to secrete more obvious trojans in the addons repository, like the aforementioned keylogger, is futile.
Also, that only 12,500 users out of the hundreds of millions of Firefox users were affected, shows how quickly Mozilla and its developer community get on top of these things. This is an addon that, despite not exhibiting any malware-like behaviour, still didn't get very far before being spotted and eliminated. This is a testament to the vigilance of Mozilla and its developers, which I find rather reassuring.
So in summary, I wouldn't be overly concerned about addons installed from the official repository being a source of serious malware infections. As with everything that stores information on your computer, a degree of vigilance is certainly warranted; but malware sources such as Javascript-driven drive-by downloads and phishing emails remain a far greater threat source than the Mozilla addons repository. Just check each addon you install and be sure of the exact reason you're installing it.
If you think that's an attack from an unexpected quarter, then how about this?
Since January, Googlebot has been tripping our IDS/IPS, and an examination of the logs revealed why.
At the end of the legitimate downloads of files from your website, come queries like:
"GET /administrator/index.php"
"GET /register.php"
"GET /unexistingfileab.php"
"GET /profile.php?mode=register"" and similar.
Googlebot is being hijacked by hackers, who sail into your website on its back, and seek out vulnerable files.
Despite our repeated reporting of this to Google, it keeps occurring, so watch out...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
