edit: never mind, I thought this was novel. Never heard of ransomware before.
I can imagine lots of things, but I don't see any reason to believe that that's likely.
seriously the only to stop this is to:
- not get infected by opening random exe
- arrest the thief
How about 300 VND? Seems similar to me. :)
Maybe the psychological part of "Oh God the file is there but I can't use it" or the fact it's ransomware?
And for those who say "my mother can't use Linux", don't be a cheapskate, get your loved ones a Mac - they will definitely know how to use it.
I have tried to find the private key with sample files, using known file byte headers, the public key and brute force on the private key. Sadly, no luck yet.
As long as you keep all drives (/ or ~/) unmounted, I assume it would be `safe' to test it.
Might be a simpler environment to analyze CryptoLocker in, as apposed to a full Windows install.
What email client automatically unzips AND executes any containing .exe files?
It's still all toast.
That level of backup would handle any kind of physical failure - a dead drive, the destruction of your house, the failure of Google... but still, this thing would kill it.
There's only so much you can expect from a person when it comes to keeping their personal documents and family photos.
I mean obviously, if you're running a company you need a real backup solution, but for family files or a one-man-show business? There is no reasonable precaution.
Someone here mentioned the encrypted versions of the files are the original size + a little extra. To me that indicates that they use a public key (of which the private component does not reside on your computer, and never has, but which you can buy). The public key is used to encrypt a key for a symmetric algorithm (AES, DES, ...), which encrypts the data, and the RSA-encrypted version of that symmetric key is then prepended as a header of some sorts.
So using a debugger you'd be able to see the public key, which I suppose is infected-useraccount-specific. It's not useful for decryption, you'll need its private counterpart.
You'll also see the symmetric key, of which a new (random) one should be instantiated for each file that is being encrypted. Should, but might not... if they slipped up, the latter might be reused (for your user account). In which case you can win, if you can observe it encrypting a new file — you'd be able to decrypt the other files too.
They'd have to be quite stupid to slip up like this, but it happens.
Update: Reading a reverse engineering report¹ it appears that it indeed works as described above. And yes, they didn't slip up; a new symmetric key is generated for each individual file.
¹ http://www.kernelmode.info/forum/viewtopic.php?f=16&t=2945
So, by the time the user is notified that there is malware on their PC, it's too late. People who know to detect viruses while they're running don't run attachments in the first place.
So the encryption process does not know how to decrypt it.
Imagine a combustion engine, you know how to burn gas to extract energy and CO2. But this engine does not know how to make gas from CO2 and energy.
This type of thing only works because the backup user has identical permissions to the backup contents as the user being backed up (because they're the same).
It wouldn't work on any system where the backup user is a separate, privileged process that is the only one with write access to the stores of backed up files.
ZFS with a snapshot script is a good way to implement this for a networked drive on Samba, since it's implicit, automatic, and the point at which it hits would be really really obvious since your snapshot sizes would suddenly explode. The same story is true of volume shadow copy (but MS idiotically limits the user's ability to set a known and trustworthy shadow copy schedule).
%AppData%\*.exe
%AppData%\*\*.exe
sidenote: this virus actually scares me, and it sounds like it actually scares most people who work in IT. This is the shittiest thing anybody has ever seen, it sounds like.
If the "1002.exe" sample on Reddit is accurate the installer is unsigned, so forbidding unsigned binaries should be sufficient. The number of legitimate unsigned Windows binaries is small enough that you should be able to whitelist them by hand.
http://technet.microsoft.com/en-us/library/ee424382.aspx
That being said a very restrictive Software Restriction Policy as linked below would mitigate CryptoLocker as it exists today. It has worked well for me so far.
Edit: It's the BTC aspect that's worrisome. Ransomeware is nothing new -- AIDS Information Trojan did it in 1989, but the (potentially) safe method of payments in crypto currency seem to be a new factor that will attract much more innovation in these type of attacks.
Anyway, what really makes me nervous is Microsoft's insistence of executing any data that a their programs touch.
> The first known ransomware was the 1989 "PC Cyborg" trojan written by Joseph Popp
GitHub for Windows and dozens of apps it installs in there F.lux Anything installed with ClickOnce Chrome GMVault Xamarin's Android Support Markdownpad SkyDrive Join.me
Assuming that everything in there is a virus is too much, I think.
Yes, and from a security point of view it should be treated as hostile accordingly.
There is no need to actively circumvent Windows security like this. Firefox, among many other examples, is quite capable of automatically updating itself using a proper Windows service mechanism.
It's long past time that Google were called out on this one. Not only is it a potential security risk, it also interferes with backups of %AppData%, which is generally an area of Windows PCs that you do want to save regularly in case of disasters.
Every time my interent connection slows (WiFi) I know it's Chrome Updater so I kill it via Task Manager and everthing is good again.
There doesn't apear to be away to turn it off inside Chrome itself and turning off updates via the registry does not seem to stop it.
dir /S /P "%userprofile%\AppData\*.exe" > %userprofile%\Desktop\FoundFiles.txt dir -Path "$env:userprofile\AppData" -Filter *.exe -Recurse > "$env:userprofile\Desktop\FoundFiles.txt"
Pull-only backups were the savior here, although because we didn't notice until the next day, the pulled backups on that system were also overwritten with encrypted/corrupt files. Luckily we had VSS versioning on the pull-only backup location. There was a close call in that the 2 TB or so of "new" data ended up pushing VSS over quota and we almost lost our good versions of the files that way. If not for the VSS versions, we would've had to resort to cold backups which would've been a bit older. As it stood, no file recovered was more than a few hours old.
Auditing on the file share indicates which workstation was infected. Pertaining to that: it surprises me that in 2013, a default install of Windows will not log any useful information about shared folders by default. You must enable object auditing in Group Policy and specifically declare which users or groups are subject to said auditing on a share-by-share basis. In a world without logrotate, I suppose a sensible default is to just let a bunch of shit happen without recording it.
What gets me wound up most of all is the amount of engineering involved for an average home user to protect themselves. I thought a Mac with Time Machine was enough, but a similar virus would easily corrupt those backups if they were available to it over a mapped drive.
It is the goddamn 21st century, and users are still losing work by overwriting documents by accident, or opening a document as an e-mail attachment and not being able to find the actual file they edited. Should people really need an IT guy with ten years of experience to be protected from simple mistakes? Google has made progress on that front with the Chromebook, I suppose.
One trivial solution would be OS level automatic versioning of files (ala Dropbox or Sparkleshare) - the original files would be written to location that is read only to the user and only accessible via the OS, hence, backups could always be restored from it, but never destroyed without admin rights.
Of course, with people having great internet and whatnot, an automatic cloud based solution would be much more likely and useful.
I think with Windows 8.1 and onwards, Microsoft are automatically doing this by setting up the "Documents" type folders in SkyDrive - a great think moving forward.
Backups are, obviously, a much better solution but require extra storage and usually cost money.
So there might be a niche for a freeware product that runs as an admin that automatically versions files - perhaps even as simple as having an admin-owned .git repo for the Documents folder.
The worrying thing about this attack is that targeting user data is trivial on all OSs, because of the way we think about privileges - it could be done to us Linux users through something nasty in our shell rc using GPG or whatever. There is no need to compromise anything.
Well, it doesn't. This is a problem that should have been solved at the level of OS permissions/UI long ago. Why does a modern OS include UI functionality allowing a standard user to run an uninstalled executable in a non-sandboxed environment? There's no good reason for it.
In some cases the problem been solved (e.g., restrictions that allow only signed apps to be executed). But I guess none of those cases include Windows, its standard UI, and popular e-mail programs. :-(
Use ZFS and make read only snapshots that are only accessible to the sysadmins. You'll solve many problems that way. We do snapshots at 6am,noon and 6pm and then keep the 6pm one for 7, 14 and 30 days.
Or, better, the above is the best case scenario that IT dreams of achieving some day. In practice, a huge share of the crucial data sits on people's machine, with no backups, and go on vacation every year.
With such a setup, the only situation in which sysadmins are required are when end-users accidentally copy sensitive data to the file server, remove it, and need sysadmins to also remove the snapshots to permanently remove the sensitive data.
(Tested backups are the first three rules of IT.)
IIRC ZFS snapshots are read-only by definition. Clones are the writable ones.
Translation for techies who aren't familiar with email's many acronyms?
DMARC means: http://en.wikipedia.org/wiki/DMARC
And the person below you doesn't understand how search engines work.
"This infection is typically spread through emails sent to company email addresses that pretend to be customer support related issues from Fedex, UPS, DHS, etc. These emails would contain a zip attachment that when opened would infect the computer. These zip files contain executables that are disguised as PDF files as they have a PDF icon and are typically named something like FORM_101513.exe or FORM_101513.pdf.exe. Since Microsoft does not show extensions by default, they look like normal PDF files and people open them."
I haven't got a Windows box handy to try this on but I assume there is at the very least an extra warning dialog when opening an exe - even a zipped exe?
Not that that mitigates this at all. The inability to distinguish executables from data files - and although that doesn't apply in this case - the ability of data files to hide executable payloads either via design or error - is a major and currently uncorrected flaw in the system.
The silly bit is the fact that the file extensions are hidden by default, and users can only use the icon to check the file type.
I find this is good insurance against the inevitable phone calls I receive as the only computer-literate member of the family: "Hey Cory, all my documents disappeared and I can't get them back. Do I have a virus?"
Hadn't been ransomware it could have very well been a disgruntled employee, to the same effect.
This said, I'm not blaming home users, but IT folks who failed to secure corporate data and should have known better.
If you want, copy my message and share with your family, friends and co-workers:
"Hi folks,
There's a new virus out there that I want to raise awareness of, it's called CryptoLocker. Basically what this virus does is that it tracks all your files - hard drives, flash drives, usb sticks, network drives/shares - then it encrypts the files it finds.
The only way to unlock the files again is to pay $300 to get the key used for the encryption. The encryption used is RSA with a 2048 bit key which makes it extremely hard to crack, I'd say impossible with the time span and todays computers.
You have 72 hours before they trash the key making it impossible for you to get your data back.
This can be extremely devastating if you are running a business and all your files are gone. If you sync your files to the cloud, you're still not safe, it syncs the encrypted files as well. If you are able to restore to previous versions of your files in the cloud - great.
Let your friends, family and co-workers know about this.
Here are some simple ways to avoid getting a virus in general:
1. Don't open e-mails from people you don't know
2. Don't open attachments in e-mails unless you were waiting for the attachment
3. Don't go to websites/click links that you don't fully trust
4. Don't download and execute files that you don't fully trust
It might seem obvious to the most of us to don't do the above, but to a lot of friends, family and co-workers it might not be.
Imagine waking up and having to pay $300 to get your data back. However, the police tracked down one of the servers that serves the keys and shut them down which means the keys were not delivered and the data was lost, this means even if you do pay the $300, there is no guarantee that you will get the data back.
Raise awareness of this and avoid having your files lost."
Joking aside. I'd love for everyone to just jump on a virus free OS, but as soon as that OS is mainstream there will be viruses.
The problem isn't the OS, the problem is that people trust everything that is for instance sent to them via e-mail. Users need to be educated on security, no matter the OS.
Given the cost of computers these days, at least in business a separate 'browsing' machine and 'business' machine seems to be the best solution. I wonder if you could provide wireless for employees to bring their own laptops which had no 'office' connectivity (but internet connectivity) and machines that were hard wired and MAC filtered to the 'business' network.
Makes me wonder whether they use the $100 variant in markets that $300 would be too much to pay.
If, is as reported, this virus is pulling in around ~$5million / annum, then that is a great basis for setting up a professional organisation to run the virus and extract maximum value from it.
While ransomware isn't anything new, the fact that the authors of such software are using currencies like Bitcoin make it that extra bit harder to track and stop these people from extorting data. I sense a new wave of ransomware is about to hit the scene now that Ars have revealed specifics about potentially making millions a year from such a racket. It's hard informing people about these things without encouraging others to go and try writing their own ransomware and expect Bitcoin as payment.
This really worries me.
http://blog.kinnaird.us/the-coming-age-of-ransomware-cloud-s...
1. Your machine is infected, and it encrypts everything it can.
2. The 72 hour countdown begins, and during that time your machine has been re-purposed to crunch BitCoins.
3. All you have to do is wait 72 hours, and everything will un-encrypt and uninstall, leaving you perfectly fine.
Creators profit by having millions of machines crunching BitCoins in their name.
Are there any recommendations of a simple way to at least enable automated backups of local documents to the cloud on a windows box?
Evidence that paying the ransom actually results in the files coming back is the most troubling aspect here - these people are looking to establish a longer term criminal enterprise.
Fortunately the virus did that by some filesystem driver level hack, because after I booted into Linux I was able to mount the partition and get my files back.
(One of the little problems with the UNIX-style user permissions is that it is designed to defend the OS, not the user. Sure, that little executable may not be able to corrupt "the system", which may amount to 5 or 10 GBs of easily-replaced code, but it will have its way with the 2TB of the single user's media files.)
The only faint defense Linux/UNIX can claim is the slightly higher probability that you'll be on a checkpointing file system and can roll back, and I say only "slightly" because they still aren't very popular yet compared to conventional file systems.
No affiliation, just a user.
I'm so sick of this. The "open/save" dialog is in sore need of being revamped. There's really no such thing as "open" anyway -- it's really "save to some obscure profile temp directory and then open". Try explaining "you can't open a file that's not first saved to disk" to a user, though.
What I recall from my initial investigation was that the binary was completely different, but opening the image did not indicate any changes. Almost like it was converted from RGB to CMYK or something.
I want to believe. I really do. But I'm not so sure based on personal experience.
This article made the rounds recently, and I think it is apt: http://www.coding2learn.org/blog/2013/07/29/kids-cant-use-co...
The pull-only archive w/ VSS versions really is massively convenient. It is the first line of defense against the scenario that comes up almost all of the time: "Help, I messed up this important file!"
You make an excellent point, but there is a second and perhaps even more sinister side to it. Encrypting your data and holding it hostage is one thing, but even if you have indestructible backups, there are probably still many sensitive pieces of information that can be acquired by a blackmailer with only user-level privileges: bank details, company trade secrets, personal mail/photos/videos, etc.
Having a back-up of these is important, but probably so is ensuring that they aren't distributed to people they shouldn't be. This requires a very different model of access control and user/application privileges, and unfortunately I don't think any mainstream OS is even close to solving this one yet.
I'm not sure it does require a different model of access control. It just requires people to actually use the access control mechanisms that exist already.
You should not access banking details or any other sensitive information in the same user-level context as you use to generally browse the internet. The privileges needed for each task ("browse the internet" vs. "check bank statements") should be different. I personally have a separate user account on my machine set up specifically for "sensitive" tasks.
Separation of data access via privileges is nothing revolutionary, nor is it something that can't be done on any modern OS. Unfortunately, online services are still behind. For example, I would probably switch to an online banking provider that let me create one account for viewing balances and another for transferring cash. But these services will get there in time.
User education is a different story.
The problem is seemingly solved by OS X app sandbox and Mac App Store review process (the sandbox alone is not enough, because it allows to declare 'exceptions' like full disk access, so human reviewers are needed to watch out for those).
The sandbox may occasionally be causing some pain (in fact, would be very painful if I had to support OS X 10.7), but at the same time my app can no longer access any user data that the user hasn't explicitly whitelisted, which is a good thing.
Windows Metro apps also live in a sandbox, but they are sort of a different platform (no access to the file system at all, as far as I know). Over time, I can see them gaining some access to a subset of the file system, perhaps via SkyDrive.
And the virus will encrypt anything writable, so the backup needs to be "pull", if the infected machine is the one doing backups and has write access to a non-cold-storage backup location it will may encrypt the backup itself.
So even if this virus encrypted your backup on Nuevo Cloud, you can just pull up the snapshot from a second before the infection, and restore your files.
The interesting change to me is that now viruses have been effectively monetized.
A versioning filesystem looks much cleaner than a different location. Maybe we should start using those again. (Is there any candidate for ext5 already?)
And yes, partitioning the data permissions for the same user is a much needed change. Nobody got a solution for that yet, and there are lots of people trying. Apple, for example, is just giving up on iOS; Google has a subpar solution on Android that does not actually work on practice (the cyanomod people did improved it a bit) but is the closest we have from something viable.
A modern OS lets us do that because lots of users are the sole user of their PC and do not understand the idea of permissions.
On Linux there is a specific flag that has to be set and is not set per default to make a file executable.
So if you run something, you know that you are running it as a program and not opening it as data.
Windows on the other hand marks everything as executable which begins with MZ and whichs filename ends in .exe or .com
In the normal case, unzipping a file on linux will result in the executable bit being restored if it was included on the original file.
This is normally what you want - imagine an app that was distributed (over https) as a zip file where you then had to go and manually add the executable bit to each relevant file.
But a zip file that was opened as an email attachment is largely indistinguishable from one that was opened from an HTTPS download (it need not be that way, but it is), so the OS has no reliable way to allow you to run executables you download in a zip, but not ones you received as an email in a zip file.
There are certainly ways around it, but the executable bit isn't really the solution here.
Better to sandbox any executables received from external sources.
Windows does too. It's called FILE_EXECUTE permission.
It just happens to grant them to everything by default, but the problem isn't the lack of the feature.
1. Educating users to stop running random programs in zip files attached to emails, is apparently impossible. Maybe email-clients should scan the contents of any zipfile it receives and if it finds any kind of executable, put up all kinds of warning dialogs saying "You really don't want to run this. There's no reason to get a program in zipped email attachment nowadays. Please go consult your IT-admin or somebody who knows about computers for a 2nd-opinion"
http://fc13.ifca.ai/proc/1-3.pdf http://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf
Imagine something just like the malware we're discussing, but instead of a 72 hour timer, it's a 4 hour timer - and at the end, it pops up a "gotcha! just kidding. but if this were real malware, you would have either lost hundreds of dollars, or all your documents. Don't open attachments like me."
1. http://www.carbonite.com/ 2. http://www.crashplan.com/ 3. http://www.backblaze.com/
"Backup solutions like Carbonite are no good against this as they will commit the encrypted files to the cloud."
You need "cold" backups to get around this without paying.
[1] http://www.reddit.com/r/sysadmin/comments/1mizfx/proper_care...
I quite like duplicati. Slightly opaque to set-up but I'm using it with SkyDrive for some files as at the time of set-up SkyDrive gave me the most free storage with the lowest level of pain [for me] setting up.
I have mine set to backup every 4 hours. It versions the files as well so you can restore to a previous backup.
The real problem, I think, is that Microsoft thinks requiring admin rights to write to "Program Files" is the be-all and end-all of solving the "application-environment integrity problem." That works for enterprise-wide deploys of sysadmin-supported software, but falls down for user-specific installations. On OSX, "application-environment integrity" can be enforced easily enough, since the OS delineates applications by a line called "the app bundle." OSX can (though I'm not sure it does) just disallow apps from writing into other apps' bundles without a "do you really mean it" prompt. But in Windows, the The Directory Is The Application Bundle[1], and so Windows doesn't know that this directory is special and should be protected from having other apps in other directories tinkering with it.
[1] http://blogs.msdn.com/b/oldnewthing/archive/2011/06/20/10176...
No more viruses, no more headaches.
My impending move to Tails OS is also timely considering this new virus. We just spent two days dealing with this after an exec launched one of these and encrypted a bunch of files on one of our servers. This, after two emails warning about it.
Obviously there are of course issues running stuff like this as root - if the daemon was compromised in any way it's game over.
1. Immediately kill the messenger, and
2. Continue to open executable mail attachments, because nothing bad has ever happened that didn’t work itself out in the end.
In the confusion, I missed that JPGs with certain naming patterns were encrypted and others were left alone. I took two unrelated facts, 1) that plenty of images were readable, and 2) that plenty of images had binary differences, and put them together to arrive at a faulty conclusion. I am not going to be too hard on myself based on how that day was going for me.
IMG_????.jpg and presumably DSC?????.jpg were encrypted and other patterns were left alone. I presume this is to inflict damage as quickly as possible without getting bogged down encrypting stuff from "Temporary Internet Files" for hours.
I wonder if they'd improve their conversion rate by leaving behind a thumbnail to remind people of how much they liked their pictures that now risk being gone forever.
There are a couple of anecdotes on Reddit about Canadians and other non-US residents scrambling to find a physical Bitcoin storefront or Craigslist contact to pay the ransom for them since Moneypak wasn't available in their area.
http://shop.wikileaks.org/donate
Now, how the malware-writer goes about verifying payment is beyond my understanding...
The authors run a key-storage service which notifies the client (and provides a private key) once payment is received.
In this case the authors are still at a substantial advantage, though - as long as enough unlocks work that "just pay up" is the advice given online, they don't have to care if their C+C server is down half the time or the feds take it down, because the money rolls in even when the decryption isn't working.
I do not work for backblaze, but I am a happy user.
1 Google search = 1/35 of a boiled kettle.
So asking the question just saved about 285 boiled kettles of carbon footprint.
(http://green.tmcnet.com/topics/green/articles/216400-google-...)
Also, experts often have insights that introductory articles lack. Better to ask the source if they don't mind composing.
I often prefer a succinct summary from an expert to, say, a wikipedia entry.
https://blockchain.info/wallet/send-shared
(Please note, before downvoting, that I'm not saying that's a bad thing)
Particularly evil malware could probably encrypt the data irreversibly if the command and control servers were unavailable, since as long as the decryption works some portion of the time lots of people will pay, but thankfully this particular example doesn't seem to be there yet.
On the other hand, if only explicitly authorised applications can create outbound Internet connections at all, and if applications like browsers and e-mail clients need explicit permission to read a general user file (as opposed to, say, accessing their own designated configuration or data files), then you significantly decrease the degree of vulnerability a user has to data leakage attacks (among other types).
$ sudo -u banking gnucash &
$ firefox &
If we create a script 1:
#!/bin/sh
echo "I'm doing something secure"
#!/bin/sh
echo "I'm doing something insecure".
sudo echo "I'm doing something malicious".
$ sudo ./script1.sh; ./script2.sh
Highlights:
The crypto is pretty bad - it's using blowfish in CBC mode with a static IV of 0c22384e5a57412b (convert each byte to decimal...).
The client-server protocol use 32 bit nonces and MACs, which is.
License key validation works by decrypting some packed data from the key after converting the alphabet back to hex. The key is blowfish-cbc encrypted data and the only validation done is verifying the padding - about 1 in 256 randomly generated ones will have valid padding, and the length is not checked.
I assume you're using a temp because of the DMCA?... :(
Or try Firefox!
You could say it's in its DNA
/ducks
ClickOnce-installed applications are limited to "Internet Zone" permissions. This can make them immensely frustrating to develop with, actually, since many of MS's own development frameworks fail miserably in Internet Zone even when they have no reason to do so (mostly they generate temporary files in places they aren't allowed).
I'm not sure how Google Chrome gets permissions to save files into your documents and whatnot from there - I don't recall Chrome requesting a permissions escalation during install or anything.
[1] http://msdn.microsoft.com/en-us/library/142dbbz4%28v=vs.90%2...
They have had it for ages, presumably to answer your mentioned complaints.
EDIT: If I want to run/update something (Chrome) in Userland, why should an OS security model stop me? My guess is, Microsoft have successfully confused a common business requirement with a security one.
The test key:
/com/code42/license/LicenseKey.java: private static final byte[] KEY = "Brian in the Conference Room with the Mouse. To be.".getBytes();
I assume this is some inside joke referring to Brian Bispala.
You don't even need to do that. You should need administrator access to install software initially, but that installation process can set up a system service that handles any subsequent updates automatically. This then runs independent of any current user on the system, and therefore does not depend on their personal privileges, nor does it need to prompt anyone for permissions for every update.
Clearly there is a risk involved with any process that can automatically download code you will subsequently execute. However, with proper access control, at least a compromised application running in user space can't do things like modifying its own executable so the malware has a place to live or, more generally, anything else that the user couldn't do without elevating their privilege level.
This certainly doesn't get us to an ideal security model. As I noted elsewhere in this discussion, a user on most systems today can probably still do things like e-mailing all the sensitive work documents they can access to a hostile party with just their normal privileges. However, it does at least prevent one common kind of attack.
How many Macs would you have to compromise before you randomly stumble upon a registered developer, let alone a registered Mac developer (of which there are far fewer than iOS developers)? And how much more secure is a developer's machine likely to be, and how much less is the user of such a machine likely to fall for common email attachment-based infection attempts?
At some point, the feasibility is low enough not to bother. That's what all security ultimately is, since nothing is foolproof.
Of course, Windows has now partially solved that with UAC. Unfortunately you can never know if you can trust the software or not though. However this does stop malware from secretly running without your permission, since it would require a UAC prompt to run. Then we get into uneducated users.
In windows there are too many ways to get elevated. And only one level of elevation.
I fail to see the difference. Sorry.
After all, there are tons of popular projects requesting users to run "curl http://... | sudo sh" and consider that a good idea, too.
I keep trying to teach my nephews that the default answer to that question is no... but of course, "yes" is the way you get anything done.
Do you know one of the most asked questions in Mac OS X user forums from new users is how to disable root?