So all seems fine until we actually try the YapBrowser program, by clicking on its system tray
icon. It then reveals itself to be an embedded IE instance with all the browser features
removed, and some toolbar icons nicked from Firefox. It starts off, naturally enough, at
yapsearch.com, a typical poor-portal strewn with pay-per-click search links, same as
you always find as your homepage when you get hijacked by a CWS infection.
Strangely enough, none of these links are working at the time of writing, so in exchange for
installing 180's intrusive software you get a browser whose homepage is stuck on a portal
with no working links. Another great Zango “value proposition”.
But the really funny bit (or, well... disturbing really, I suppose, but by this point nothing surprises
me) is what happens if you get bored of the broken search site, and try to use the browser to go anywhere else. Type a URL
into the address bar at the top—any URL, or anything at all, or nothing—and
the browser sends you straight to an advert page. An advert page for hardcore child porn sites.
You 'eard. Software downloaded from 180's servers promoting kidporn.
Keepin' the internet free, there.
So who is this ‘Enigma Global Inc’ that the YapBrowser installer claims is
responsible for the program? The language in the licence agreement, claiming that
the software contains no “Grecian horses” suggests English isn't
their first language, that's for sure; the site are hosted at Pilosoft, one of the largest
US ISPs for the Russian-language adult webmaster community and their security exploits,
hijackers and PPC sites collectively known as CWS.
The whois information for yapcash.com, the affiliate scheme for the yapsearch.com site,
is given as “John Malkovich”—obviously fake, but with a probably-not-fake
e-mail address at yahoo. The same details are used for a group of sites at Eltel, a Russian ISP,
including one site that redirects the user to browser exploits at paradise-dialer.com,
which load trojans, spyware (via the CWS Cactus group) and dialers (from PremiumBilling, aka
Coulomb).
Paradise-dialer's whois places it as part of the CWS group known as Dimpy, aka BigBuks. Since the BigBuks
whois is also given by mix-click, referred to by the yapbrowser/yapsearch whois, and
the aforementioned servers at Pilosoft and Eltel (as well as the paradise-dialer server also
at Pilosoft just a few IP addresses away) run many other sites that link back to browser exploits and
child porn promotions run by BigBuks, it seems reasonable to assume that they are the same
group of people.
(Again, full list of domains/info available to security researchers, but contains much that is
unsavoury indeed. Visting any of the domains mentioned here is an extremely
bad idea.)
Nice to see 180 is still picking their partners so very well. (And cheers to Mike Burgess on the
MVP spyware list for spotting YapBrowser!)
Notes on CGI, IIS and Python
Here's some random stuffs that I thought I should leave somewhere for Google
to look at, since the information doesn't seem to be widespread. Do not mock
the CGI. It may be old and unfashionable, but at least it is a proper
cross-server standard.
Most of this probably applies to other CGI scripting languages too.
The command line
Microsoft's Knowledge Base article 276494 recommends you set up IIS to run Python
CGI scripts by going to Administrative Tools -> IIS Manager -> Web Sites -> Properties ->
Home Directory -> Configuration -> Add extension ‘.p’ (phew!) and entering the
Executable command line:
C:\path\to\python.exe %s %s
Unfortunately this is not just wrong, but possibly dangerous.
The first problem is that it'll break if a CGI script's filename has a space in it,
because everything after the space becomes parameters to the script.
Secondly, if the script name starts with a hyphen, it becomes a flag to the
Python interpreter. And there are some dangerous flags—for example
-c allows you to execute any Python code.
If the ‘check file exists’ option is turned on, this is only an annoyance in
that you can't use script names with these characters in. However if
turned off an attacker would be able to abuse these holes without you
having to provide a script with a weird name.
The solution is to put the ‘%s’s in quotes, and ensure that
the ‘check file exists’ option is always on.
Another problem with the above command line is that it starts Python with
a text-mode stdin/stdout stream. This means that any data with newline characters
in will get mangled on the way in and out of the script. For a CGI script, which deals
with streams that are explicitly binary, and may well use CR-LF combinations,
this is undesirable.
In particular, symptoms you may see are:
- scripts that return binary data such as downloadable images producing corrupted files;
- scripts that accept file uploads storing corrupted files;
-
scripts that take input as POSTed multipart/form-data mysteriously hanging and never
returning anything. This can happen because the Content-Length request header
counts \r\n as two characters but the script sees only one, which may cause it to try
to read beyond the end of the request body. Since there is no more data forthcoming
from the client end, it'll just sit there waiting for input that will never come, until IIS
times it out.
To stop this happening, you need to use the -u flag to the Python interpreter. So
the Executable command line should actually be:
"C:\path\to\python.exe" -u "%s"
You can also include the second %s if you want, but it's unlikely ever to be needed. It's
for old-school HTML <isindex> queries passed directly in the command line
(see the spec
for more on this little-known and mostly-useless feature).
Buffer bug
Due to an odd and extremely annoying buffering behaviour, requests that have a
body (such as POST requests) must have their entire body contents read
before the CGI script starts writing any significant amount of output. If you try to
write more than an unspecified amount of output*
before the request body is read, the call to write() will block (hang up) until IIS times out the CGI.
This has the side-effect that even scripts that are normally called with GET, or
which don't have any parameters to read at all, must still check for POST requests
and read the entire body before their output anyway. This is most easily done by
using a form-reading library (eg. cgi.py, form.py) at the start of every script, whether
you need to read a form or not.
Unless you intend to work with WebDAV scripting, it's also worth disabling all
the extended HTTP methods, some of which also require a request body to be read.
Set the ‘limit verbs’ option to ‘GET,HEAD,POST’.
Authentication
IIS sets custom error pages by default, overriding several responses a CGI script
can generate. This also sabotages the returned status code.
One of the consequences
of this is that if you want to do HTTP authentication from a CGI script you have
to make sure the ‘Status: 401 Authorization Required’ actually gets back to the
caller. To do this you must turn off the custom error page 401;5. You may wish to
turn off other custom error pages too if you plan to have your scripts generate
those responses.
For some reason in IIS6, a CGI Status: 404 is never
returned to the browser. Instead, unhelpfully, a blank page is displayed. I don't know of a
workaround for this, other than erroneously stating the status was 200 OK the way IIS likes to.
IIS 5.0 and below also set ‘Integrated Windows Authentication’ by default, which
tries to check submitted HTTP authentication against the Windows user database.
This stops them getting through to the script. To stop this, make sure only
Anonymous access is enabled.
Apache also deliberately stops authentication details getting through to the script, because it
thinks it's a security problem that any other local user on the server can see the
authentication details. Whether that's actually really a risk or not depends on how your
server is set up; unfortunately there is still no runtime configuration setting to avoid it.
Instead you have to recompile with -DSECURITY_HOLE_PASS_AUTHORIZATION .
I am guru, hear my hack
Sigh. That was quite boring. Sorry. I just wanted to be able to find it next time I Googled
for it. It's a life hack, you see. They're very popular recently. Never one to miss a bandwagon
by more than about a year, I've decided to become a geek lifestyle guru.
Follow my handy guides and you can achieve anything!
- How to make money—fast!
- Provide some kind of product or service that people need.
- Or steal from people, con them, and write spyware and stuff.
- Or do something else.
- How to stop smoking the easy way!
- Don't have a smoke for one whole day.
- Repeat.
- If you do have a cigarette, pretend you didn't.
- Three steps to a healthier You!
- Do things that are healthy, like swimming.
- Don't do things that are unhealthy, like eating cadmium.
- A healthier You!
- How to be a lifestyle guru
- Say you are one.
- Smile confidently.
- Say you are one, but more convincingly than the first time.
- How to find love
- You must be at ease with yourself. If you have low self-esteem, try to improve it, by having a nice cup of tea.
- Meet new people. For example, why not go out to a tea shop and have a nice cup of tea?
- Oh well, you probably won't find love. Never mind, console yourself with a nice cup of tea.
- How to make a cup of tea
- Boil water.
- Pour onto tea leaves.
- Strain water of leaves into cup. Add milk to taste.
As a sad and geeky programmer type I am 100% qualified to fix your life!
Send money for exclusive seminar don't miss! Bye now!
5th February 2006
It's been a long time, I shouldn't'a left ya. Without some pointless pontification to retch to.
Hello! I've been a bit busy over the last year. Not that you'd know it from this site. Here, anyway,
are the recent site updates:
-
A load more stuff at Losertown. Yes, I've
been Doing Shows again, this time on that there internet.
-
[final] releases of pxtl and
pxdom. Yes, I've fixed a few bugs
here and there and put an ‘It's stable now!’ sticker on the top.
-
A load less stuff at Parasites. Yes, I've finally
given up trying to provide a comprehensive database of unsolicited commercial software.
Sorry. There are a number of reasons for this.
When I started out doing this, as a back-end to the
detector script, there were
about half a dozen families of commercial malware to keep updated, and it was necessary to draw
people's attention to the threats.
Since then of course the Spyware Problem has exploded beyond all possibility of one
person tracking it all. It's now a more widespread and complicated problem than simple
viruses ever were and there are now many companies employing many people to try
and fight it. Of course there are any number of rogue marketing companies trying to
make a quick buck out of anti-spyware too... but in any case, the issue hardly needs
any more attention drawn to it at this point.
Secondly, despite saying “Please contact me if you believe I have unfairly
classified your application!”, I am unable to deal with the queries this
generates. Both due to the lack of time and the bomb-site nature of my mailbox—having
had an e-mail address published across the web for many years means I get pretty much
every spam, virus and bounce going. The best filtering in the world can't clear that up so
it's likely a lot of my mail gets deleted or unread: I can't guarantee to respond in a timely
fashion.
So, for now, the pages are down. However of course as they were Creative-Commons-licensed
there is nothing to stop anyone else from taking them and maintaining them further. And
the information itself is not gone forever; in one way or another it may help an
upcoming project I hope will be very much of use to spyware victims.
More about that later. Watch this space. No, up a bit... left... yeah, that space there.
Microsoft rumblings
Anyhow, the detector script itself also has a limited lifespan now. IE7, by default, prompts the
user before running an ActiveX control that hasn't been used before, and that means the
script won't detect installed components terribly smoothly. Between this feature as IE7
becomes a more widely-used browser, and the rise of more malware using random class IDs
to avoid detection by this and other tools, I expect to phase the script out slowly in the
future.
This feature is, by all measures, a Good Thing, and I congratulate Microsoft for thinking of it, even
if it inconveniences me slightly. Another welcome change to ActiveX was introduced in the MS05-052 IE security rollup,
albeit quietly as it didn't fix an immediate bug. IE now requires controls to
implement IObjectSafety before it tries to run them. Previously, many types
of control from random applications unconnected to IE could be instantiated inside
IE, with potentially disastrous results. (Although more usually it'd just crash.)
This was pretty daft, and it's great that it's finally been fixed.
(And I'm not just saying that because I won an MS Security MVP Award a while ago
so I have to be nice to Microsoft. I'll say something nasty in a minute, just you wait and see.)
MS05-052 should also scupper the parasite detector script really, whose whole
purpose is to sniff for installed ActiveX objects, most of which were never designed to
be instantiated inside IE. Strangely, though, it doesn't. There's something about the
order the checks are done that means you can still sniff the difference between a
blocked control and one that isn't loaded at all. This should be fixed too really—it's
all very well for me to be able to detect parasites using this quirk, but in general
web pages being able to sniff what applications you have installed is still a Bad Thing.
In any case this doesn't help with ActiveX controls that are designed to
be used by IE, but designed badly. There are still far too many completely pointless ActiveX
controls that serve no purpose not already done better by HTML, and usually the
idiot companies involved leave great big security holes in them. If it's not a buffer overflow
it's a complete lack of arguments-checking.
Number one culprit are those ActiveX ‘downloader’ controls,
apparently ‘designed’ to make it ‘easier’ to install software.
You'd think the web already made it quite easy to install software: click on a link to
a .exe file and choose Run, or save it and double-click on it: not rocket science is it?
But no, apparently it's much ‘better’ to require the user to install an IE/Win-only
bit of code that does that painfully-hard double-clicking for you. And then sits around
on the system waiting for any old web site to ask it to download and install whatever
malicious code it likes. Nice one. Company after company have made this same
mistake, as demonstrated last year after the Sony rootkit fiasco exposed both
copy protection uninstallers as independently suffering from the same stupid
schoolboy error.
So we are getting some improvements from Microsoft, but we're not out of the woods
yet. Jim Allchin reckons
Windows Vista is going to be a most excellent security update we
should all buy, but from the betas we've seen so far I'm not at all sure yet.
The biggest addition in Vista seems to be the existence of User Account Protection (UAP). In
theory this allows you to run as a normal user despite actually being an Administrator. You
should then get prompted to perform operations that require further privileges. Supposedly
this should stop user-level programs getting full root access.
This is quite promising, though personally, I'd have preferred to work it the other way—to actually run
as an unprivileged user, with the ability to punt disallowed requests up to admin. An extra
restricted-admin mode just seems like another extra-feature-stuck-on-top rather than a real fix
for the issue of developers not making their applications run as normal users. But in
either case I have to wonder how effective this can be given the number of local-user
privilege-escalation attacks against Windows and desktop applications. (There's also, of course,
nothing to stop restricted apps opening spoofed UI elements.) As I've said before:
I want per-application permissions at the OS accounts level, with the default set to not allow them out
of a sandbox much smaller than the user's own rights.
In any case, UAP doesn't work properly yet, randomly disallowing normal admin activities
and redirecting other changes to a virtual registry where they silently fail. Add to that the
constant prompts any time you run any program, as well as incessant shrieking from unturnoffable
system tray icons, and you have a very needy OS indeed. There are
some really nice ideas scattered around the Vista UI, but they're currently drowning in
inconsistency and clutter. (It also seems really slow, for some reason, even when all
the bells and whistles are turned off.)
Vista is of course still in heavy beta, but given that it's been so long since XP I had honestly
hoped for more progress, and can scarcely believe it's still aimed at a 2006H2 release.
If it's not to become an unloved OS release to beat even Windows-Me, I personally think
it needs more time to mature.
(See, I told you I'd say something nasty about MS. I do hope they can pull Vista around
and make something usable of it, but so far my experience has not been quite as positive
as that of Paul Thurrott and pals.)
Another feature that has garnered a lot of attention has been the announcement of a
full two-way firewall in Vista—that is, filtering outgoing as well as incoming traffic.
MS caught a lot of flak for not including this in XP—undeserved, in my view.
Whilst personal-filewall egress-filtering is useful for keeping track of the legit applications on your
computer, it is not an effective security measure.
Why? Because once untrusted code is running with the same rights as you, you have
already lost, and the firewall itself is compromised. Already many trojans deliberately
detect and disable known commercial firewall products; if we're all running the same
Windows Firewall, every bit of malware is going to punch a hole through the firewall
settings to let themselves through, first thing they do. Hell, even legitimate programs will
probably ‘helpfully’ set up the firewall to let themselves through, so the
user doesn't have to deal with it. And by that point the idea of a firewall is pretty much defeated.
The one-way firewall itself is was a mistake in my opinion: an attempt to fix the problem of
the OS (particularly Windows, though others have had the same issues) opening unsafe services
to the internet by sticking another feature on top. It would have been simpler just to fix the problem,
and have native networking services bind only to interfaces specifically marked as ‘safe’
local networks. But that's a battle long-lost.
Nice Thing about Windows Vista #1: you get some nice fonts with it. How nice!
Spyware: State of the Union
(There isn't a Union of course. I just cleverly stole the phrase to tie in with the US State
of the Union speech. Good eh. Except that was a few days ago now, so maybe it's not really
that clever. Ah, sod yer then.)
As linked by Suzi on ZD's blog,
apparently some spods from the University of Washington reckon there's been a decrease in
spyware activity. I don't think this bears much relation to reality though.
There has been a lull in one particular sector: the US-based mainstream parasites.
The Direct-Revenues, 180 Solutions/CDTs and ISTs of this world have gone pretty quiet of late.
Some, like Vista/Mindset, seem to be bringing their unsolicited-commercial-software to a halt;
many are simply drastically cutting down on the bundling of their software by IE security
hole exploits, particularly CWS-related exploits.
As the article suggests, this may well be due to the beginnings of efforts by the FTC to examine
their activities. It's about time. I don't agree, however, that XP Service Pack 2 has had much of
and impact here; it doesn't really affect spyware bundled by downloaded applications, and
though the range of exploits IE is vulnerable to under SP2 is reduced, it has still been easily
enough for groups involved in CWS to continue their pay-per infection businesses.
And meanwhile, CWS itself is stronger than ever. CWS is not one operator or method, but
a massive distributed ring of interrelated competing and co-operating groups, all
involved in the Russian-language adult webmaster business. There is no one target
the FTC could shut down to stop the attacks, even if it had the authority.
(We call it CWS because it first came to prominence due to homepage-hijackers targeted
at coolwebsearch.com, but that site is really only tangentially related to the CWS groups,
its PPC search results one of the first big revenue-generating sources for their exploits.
Whilst guilty for letting it go on so long, it's not in any way central to the problem.)
So whilst CWS are no longer getting so much income from installing mainstream parasites
from the US spyware houses, the alternative is even worse: the average CWS exploit these
days installs spam/DDoS botnets, keylogger/banking information trojans and rootkits, as
well as the perennial hijackers and dialers.
You also invariably get a rogue anti-spyware application and accompanying ‘YOUR
COMPUTER IS INFECTED!!!!’ scare adverts—for software operated by the CWS groups.
Clearly there is more profit in trying to con people into buying $50 spyware removers from the
spyware companies themselves, than getting ten cents an install from the spyware companies.
So it's swings and roundabouts, and although one kind of spyware is currently in decline, the
rest of the market is making up for it in spades. A “a 93 percent reduction in drive-by
download attacks” is absolutely not anything like what I’m seeing
In The Wild, and I have to question their methodology on this claim. The quotation
“That may be because more people are using anti-spyware tools and employing
automated patch programs such as Windows Update” doesn't even make any
kind of sense when applied to the situation of automated scanners spidering sites for
exploits, so I suspect they may not actually be making that statement.
What a lot of text I just dumped there, with no little stupid pictures at the side
to make it palatable. Better do something about that.
