Domain: securiteam.com
Stories and comments across the archive that link to securiteam.com.
Comments · 134
-
Re:Yet another biased Slashdot story
Google for "Cron core dump vulnerability": http://www.securiteam.com/exploits/5OP0C0UJ5Y.html
-
Re:Security Setting
The security setting for Java defaults to High anyway. You would have to either A) change your security settings specifically lower or B) specifically allow an untrusted applet to run for this to (sometimes) work. I'm starting to get tired of the anti-Java FUD, there are a vulnerabilities found all the time in other languages/frameworks, how come all we seem to hear about is lame Java applet sandboxing issues?
Didn't realize I wasn't logged in when I made that post
-
Security Setting
The security setting for Java defaults to High anyway. You would have to either A) change your security settings specifically lower or B) specifically allow an untrusted applet to run for this to (sometimes) work. I'm starting to get tired of the anti-Java FUD, there are a vulnerabilities found all the time in other languages/frameworks, how come all we seem to hear about is lame Java applet sandboxing issues?
-
Re:Antivirus?
Wow, HELLO, GDI+ exploit! one malicious JPEG parsed in any application *BAM*! Just one example of many. Guess you don't view any JPEGs on the internet do you? I suppose you use absolutely no plugins (Flash, Adobe Reader, Java) in your browser either? Idiots...
-
Re:But wait
Fact: you don't know that the iOS hole hasn't been exploited by others.
This story is about a local root hole. Apple has them, Linux has them, Windows has them, OpenBSD has them. To use it, you need to make the computer run the code, you need an infection vector. Linux is more or less exclusively exploited as a server OS, as it has services running and accepting connections from the outside 24/7. OS X is no different. Not at all. Etc, etc. As a desktop or phone OS, I've never heard of Linux being targeted, but at least I'm not saying it's never happened.
Why is desktop Linux and OS X targeted so rarely? Think about the infection vector: either getting people to install a trojan, or planting malicious code e.g. on a web server, and then hoping that a bunch of random users should stumble across the site, hopefully running the correct versions of the right browsers -- it just wouldn't be very effective. So you don't get widespread infections, and they aren't reported. If such an exploit were to be worthwhile, you'd expect it to be targeted to a specific user or organisation with a known software stack, using your ordinary social engineering skills to lure people into clicking a link, for instance. This shouldn't be too hard, and it would more often go undetected. Perfect for spying. The same goes for iOS, of course, although it's a lot simpler, for obvious reasons.
-
Re:What's more outrageous...No problem, there was a lot of mis-information in this by all concerned (particularly E360 Insight and the press.)
Here's a lawyers comment confirming what I said (and one of the places I got the info): http://blogs.securiteam.com/index.php/archives/664
-
Re:What's more outrageous...
They did to have the case moved to federal court, when the judge declined their request they walked out.
[citation needed], and yes I did Google it, this is all I found, which doesn't support what you said
Get *YOUR* facts straight.
GP's statement was reasonable considering the wording of the summary ("Spamhaus didn't bloody care")
From a link on the page you linked ( http://blogs.securiteam.com/index.php/archives/664 )
it would have been possible for an attorney to make what is known as a “special appearance” before the court without acknowledging the court’s jurisdiction in the case. reading the record, i’m puzzled that this wasn’t the strategy spamhaus’s counsel chose.
4. unfortunately, since that’s not what happened, spamhaus may have waived personal jurisdiction as a defense early on in the case when they not only appeared, but then asked for the case to be removed from state court (where it was originally filed) and moved to federal district court (where it is today). arguably, and this makes sense intuitively even if you don’t understand the finer points of u.s. civil procedure, doing so inherently acknowledged the jurisdiction of the federal court. in the beginning of a case like this there are two choices:
a) you can fight it, or
b) you can claim the court doesn’t have jurisdiction and, basically, ignore it.
you can do one or the other, but you cannot do both. the pickle spamhaus is in right now is largely caused because they appear to have initially tried strategy (a) then switched to strategy (b). there may be a way to still raise the jurisdiction issue, but make no mistake, it’s an uphill battle at this point.
As I said, as an RBL operator, I have been watching this very closely from the start because it could have affected me personally, as it happens it doesn't appear that it will even though it is not a default judgement.
-
Re:Reliable infrastructure....
I really don't see the point in "cyber warfare" other than small-scale attacks on a certain site or ISP, a large scale plan could never fully work because any country could simply switch to basically a huge local network. Would it be hard? Yes. Is it able to be done? Yes.
I think your post betrays a surprising amount of naivete. The Internet is, by definition, international. The amount of foreign transacting that would be decimated by switching to "basically a huge local network" is unfathomable. The Internet is fast becoming the heart and soul of our economy - and cutting it off at the knees is never an acceptable solution. The cost is always too high to justify.
Plus, other than attacks on military infrastructure, the coming diversity of OSes, CPU platforms, and networks would make attacks on civilian devices nearly impossible. You might be able to write an iPhone worm, but you wouldn't be able to write an iPhone/Android/Java/BREW worm that attacks anyone on any cell network. That worm would also not work on a PC running Windows/OS X/Linux/BSD. And the diversity in browsers make exploit-based attacks even harder. It used to be you could attack the weak IE browser and get 90% of web surfers, now you would only get slightly more than half, and you would need to attack Firefox (both 3.0 and 3.5 along with perhaps older versions), Safari, Chrome, Opera and many smaller browsers.
Anybody with a DSL-class Internet connection can take out large swaths of the Internet using common, widely known exploits, such as DNS spoofing attacks. Since this is a DOS attack, it would affect anything at the target points.
You are right in that the Internet is increasingly heterogeneous, but while alternate platforms have flowered, the Internet was never homogeneous! Sure, you could attack 90% of client browsers with an IE attack, but never 90% of the Internet hosts! And certainly not 90% of the "core servers" - high bandwidth servers at the logical center of the Internet.
The Russian mob runs a fairly profitable extortion racket with the force of DDOS attacks. While they currently target semi-legal websites (such as gambling and extreme porn sites) in order to keep their profile low, as their stature grows, they will become an increasing risk to companies doing core, legitimate business.
And the problem is severe. Like I said, anybody with a DSL-class connection can do terrible things - what do you think a mob gang with 125,000 infected hosts can do?
-
Re:Not News!!
Remote Shell trojan (which despite the name is self replicating and therefore a virus). Designed specifically to be spread by users running trustworthy executables without the need for admin rights. And yes, it did infect a number of systems 'in the wild'
-
Re:Basically
you've clearly never tried to look at skype's code then. It has multiple levels of code obfuscation.
Last I checked the majority of the program's contents are encrypted. The loader decrypts it into memory, and also deletes the boot-loader from memory. Additionally, the the program will try and detect if you are running it in a debugging environment and jump into random pages. This in turn is hard to detect because seemingly random jumps are all over the code from checking checksum's on itself (to make sure you didn't put in software debugging).
I'm not even explaining this fully-
from: http://blogs.securiteam.com/index.php/archives/355
read: http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf -
Re:Linux Adpption should be up
Noscript will not be helpful against malware exploiting bugs in displaying code (png library, video codec,
...). And don't say that won't ever happen. And yes, in principle you can block that, but I guess if you block all videos and images, you might as well just not surf the porn site anyway (or maybe there are ASCII porn pages somewhere?). -
Someone just rediscovered XML Entity Attacks
It's difficult to say from the information provided, but it sounds like someone just rediscovered XML entity attacks (as I did a few years ago). Assuming it is the same thing, here are some references from 2002 and 2006 with more details:
http://www.securiteam.com/securitynews/6D0100A5PU.html
http://www.sift.com.au/assets/downloads/SIFT-XML-Port-Scanning-v1-00.pdfI've used these attacks in real-world tests and they are still surprisingly effective - just not new.
-
Re:Viruses Aren't a Problem in Linux = b.s.! apk
"If those were the best examples you could come up withm then I guess you succeeded in disproving your own point." - by parodyca (890419) on Friday June 12, @10:12AM (#28307657) Homepage
Well, @ this point, here are 50++ more evidences of his title of "Viruses aren't a Problem in Linux" subject-line being b.s.!
That all "said & aside"? Here we go:
Threat Encyclopedia Search Results for *NIX oriented malwares/virus/trojans etc. et al (pages 14-25, approximately 50++ more ontop of the 40 or so I have already noted in my prior posts here):
http://threatinfo.trendmicro.com/vinfo/virusencyclo/alphalisting.asp?NAV=14<r=U
http://threatinfo.trendmicro.com/vinfo/virusencyclo/alphalisting.asp?NAV=15<r=U
http://threatinfo.trendmicro.com/vinfo/virusencyclo/alphalisting.asp?NAV=16<r=U
http://threatinfo.trendmicro.com/vinfo/virusencyclo/alphalisting.asp?NAV=17<r=U
http://threatinfo.trendmicro.com/vinfo/virusencyclo/alphalisting.asp?NAV=18<r=U
http://threatinfo.trendmicro.com/vinfo/virusencyclo/alphalisting.asp?NAV=19<r=U
http://threatinfo.trendmicro.com/vinfo/virusencyclo/alphalisting.asp?NAV=20<r=U
http://threatinfo.trendmicro.com/vinfo/virusencyclo/alphalisting.asp?NAV=21<r=U
http://threatinfo.trendmicro.com/vinfo/virusencyclo/alphalisting.asp?NAV=22<r=U
http://threatinfo.trendmicro.com/vinfo/virusencyclo/alphalisting.asp?NAV=23<r=U
http://threatinfo.trendmicro.com/vinfo/virusencyclo/alphalisting.asp?NAV=24<r=U
http://threatinfo.trendmicro.com/vinfo/virusencyclo/alphalisting.asp?NAV=25<r=U
&
New Worm Targets Linux Web Service Holes:
http://www.eweek.com/c/a/Linux-and-Open-Source/New-Worm-Targets-Linux-Web-Service-Holes/
More info on the new Linux worm
http://blogs.securiteam.com/index.php/archives/305
APK
P.S.=> Oh, by the by: If the (so far) 90++ evidences of worms, viruses, trojans, malwares & general faults in Linux' security? I think you're not as experienced in these matters as you'd like to think is all - especially with you're stating & agreeing about this exchange's subject-line of "Viruses Aren't a Problem in Linux" etc. et al... apk
-
Re:Viruses Aren't a Problem in Linux
"Gee, you had to go back 8 years to find three issues. The first one isn't even malware, just bad programming by the vendor that reduces performance. The next two are specific to Apache web servers, NOT Linux." - by parodyca (890419)
on Friday June 12, @10:12AM (#28307657) HomepageDoes it matter how far back I had to go, & no, not all are from "8 yrs. ago", because below also shows otherwise!
So, to prove the subject-line is bullshit? I provided contrary evidence thereof...
However, it appears You need more proofs then, apparently, so here you are/"ask & ye shall receive":
Linux RAMEN Worm:
http://service1.symantec.com/sarc/sarc.nsf/html/linux.ramen.worm.html
Net-Worm.Linux.Mighty:/b>
http://www.viruslist.com/en/viruses/encyclopedia?virusid=23864
DroneBL Security researchers warn of Linux Router worm (PsyB0t)
http://www.tcmagazine.com/comments.php?shownews=25399&catid=5
Linux ADORE Worm:
New Worm Targets Linux Web Service Holes:
http://www.eweek.com/c/a/Linux-and-Open-Source/New-Worm-Targets-Linux-Web-Service-Holes/
gicumz worm:
http://blogs.securiteam.com/index.php/archives/305
Linux malware list (37 Viruses, worms, & trojans on Linux):
http://en.wikipedia.org/wiki/List_of_Linux_computer_viruses
(Want more?? I'll supply them... & they're not all "8 years back either", don't you OR can't you read & determine dates? Apparently not...)
APK
P.S.=> Better luck next time, because all of your "it's old news" b.s. propoganda doesn't matter, if your subject-line is absolute b.s. - gotta love the Linux Penguin crew around here, with their "straight outta pravda" 1/2 truths they spout... lol! apk
-
Re:MD5 Collisions...
The fact that there are collisions is a fun anomoly as long as you can't generate collisions with an algorithm, not anything useful.
Yeah, sure is a good thing that it's not possible to do that with MD5 hashes.
-
msApache
There was a nice post about this issue couple of days ago in securiteam, they called that post msApache
I really liked that name... -
Re:Oh that tears it.
For the current position, here is the referenced address: http://blogs.securiteam.com/index.php/archives/1113 Seems to be partly patched??
-
Next time the MD5 will match?
Isn't creating MD5 collisions (making your changed file match the original MD5 value) something that can be done on a PC nowadays with stuff like this: http://www.securiteam.com/tools/6O00E1FEKO.html
-
Re:Hardware RNG
(P)RNGs are *crucial* to any cryptographic operation that draws it's entropy from it. Since it is such a basic functionality and so important to security, it is critical to do this right. The DNS cache poisoning attack http://www.securiteam.com/securitynews/5VP0L0UM0A.html is all about bad implementation of PRNG.
The big problem that I see is, that it seems that Microsoft did not give the correct implementation of PRNG the importance it should have. -
Re:looking for details on storm botnet control
http://www.securiteam.com/securityreviews/6U00L1P5PY.html
Read this article. -
Re:The real Linux news today.
Does anyone know a timeline for a patch? The securiteam.com article has no comments and I found no mention on the Linux Kernel Mailing List. I know I should just subscribe to LKML but has anyone seen any recent email traffic regarding this exploit?
As parent suggested that later 2.6.23-rc might have fixed this already, I read through the changelogs, but all I found was a reference to a ptrace bug in 2.6.23-rc6 ("On x86_64, this constitutes a regression in IA32 compatibility support.") So I think the vulnerability has not been discussed on LKML yet. -
httponly
In fact, the "cookie grabbing technique" is one of the oldest tricks in the areas of XSS.
... and this is the reason why the "httponly" cookie extension was created. Firefox 3 will support it, and I already modified my PHP framework to use this for the session cookies. -
Re:STILL NOT A WORM
Parent 100% correct. Though it's easy to see how people can be mislead, as even some of the security sites are calling it a worm. http://www.secureworks.com/research/threats/view.
h tml?threat=storm-worm
gives you some information on how it operates (as of 2/07, and the names of the executables you had to click on to infect yourself have probably changed since then)
The original storm.worm (2001) attacked unpatched MS IIS servers, and actually was a worm.
http://www.securiteam.com/securitynews/5DP0B0K4KG. html
How this got so large is a pretty sad commentary. First off, it's proof that people will still click on attachments without verifying whether they're legitimate. I'm not convinced that any amount of training will ever stop this behavior. It hasn't worked over the *last* ten years, at any rate. Second, several virus scanners would have detected it, if they'd been kept updated. Thirdly, I've seen this running from within a couple of corporate LANs, which implies that even corporations don't always keep anti-virus software up to date, or monitor for P2P traffic, which IMO should very seldom be allowed on a corporate network. -
Re:/etc/password
POSIX has getlogin() or getlogin_r() to get the current username.
Some implementations of these are apparently easily tricked, though. -
Re:Why I love IE
Well, there are a couple of things about CWS:
1. It merely used the JVM as a vector to install itself. As a virus, it was actually a Windows program and was reported as such by all virus tools in existence. Thus the original poster would not have known it as a "Java virus".
2. There are actually a wide variety of CWS variants. Some of them used the JVM vulnerability while others used other system vulnerabilities like a hole in the Windows Meta File.
3. As another poster pointed out, it was a hole in Microsoft's VM that was exploited. Which would seem to be further evidence for moving away from IE. -
SECURE THE PROTOCOLS!!!
Just fix the darn protocols, dammit. It's been a year since Blue Security was taken down by PharmaMaster and NOBODY has done ANYTHING to prevent any subsequent DNS amplification attacks from happening.
If ISPs at least blocked forged-ip packets from exiting them, then THAT would be a nice start. -
Re:Accountability
Ask and ye shall receive:
http://blog.washingtonpost.com/securityfix/2006/03 /when_macs_attack.html
http://lwn.net/Articles/222153/
http://www.networkworld.com/community3/?q=node/534 4
http://blogs.securiteam.com/index.php/archives/304
http://www.shadowserver.org/
I can continue for pages and pages if you wish. You know, search engines are useful tools at times ;) Now granted, most of it comes from exploits in 3rd-party apps, such as Apache, PHP, SQL, etc. But...knowing this, and how there are botnets running with Apache priviledge levels.....kind of dumps that whole "don't run as root in *nix" argument right into the toilet. As long as people are people, they can be socially-engineered to offer up their passwords for whatever reason (I'm looking at you, OSX users). Relying on a popup password entry box for security is just as silly as allowing a Windows machine to sit un-patched on the internet.
I am actually quite surprised that more OSes don't have some sort of application firewalling/sandboxing built into them, instead of relying on concepts like UAC or root permissions that are worthless if all it takes to bypass them is someone typing a password into a popup box, clicking Allow (and how many people do we know that use blank or short, all alphabetical passwords, hmmmm?), or running insecure application software that is always accessible via the internet. -
Re:Pretty sad considering...
and even the BSD one has a buffer overflow in it. Perhaps you consider the BSD devs 'dumbfucks' too?
-
Re:Just three million?
The is a vulnerability in the shared folders feature. This is a feature of the VMware Tools which are installed on the guest. It is possible (probable) that there are other vulnerabilities with the VMware tools.
-
Re:semi-secret number bad tool for ID
"You don't need to be an expert in cryptography to realize that a password sent around is plain-text is bogus."
Indeed... -
Here's a plausible version of what happened
-
Re:OK:
Several discussions of Linux Botnets:
http://lwn.net/Articles/222153/
http://blogs.securiteam.com/index.php/archives/815
http://www.networkworld.com/community/?q=www.deb.r adcliff.com -
Yeah but where?
I looked for the data mentioned in the summary and all I could find was this from the Securiteam blog (posted Jan 12). Is that it? Interestingly it says the name of the project has been changed from "Web Honeynet Project" to "Web Honeynet Task Force".
-
Old newsDave Korn just pointed out on Full Disclosure:
Firefox users: paste into your URL bar: "google site:neohapsis archive Full Disclosure" (assuming you've a smart keyword search set up for google - I much prefer em to the smart search bar - but I digress)
Gadi Evron wrote:
> > Noam Rathaus on using Google to anonymize attacks on websites:
> > http://blogs.securiteam.com/index.php/archives/746
> > By placing a URL on any web page, Google will find it, visit it and
> > then index it. With this mechanism, it is possible to anonymize
> > attacks on third party web sites through Google by the use of its
> > crawler.
This technique was described by Michal Zalewski in Phrack years ago.
http://www.phrack.org/archives/57/p57-0x13
cheers,
DaveK
--
Can't think of a witty .sigline today....
-
Re:I've used XP SP2 without AV for years
Now I'm using IE7 as my main browser (quiet!) and don't anticipate any problems with it, either.
Except if you access a site that exploits the current 0day vulnerability. -
ceremonial shovelThere's a convention when camping in the forest that ones digs a little hole beforehand, and pushes some dirt over the hole afterward. Wouldn't the world be a better place if the average slashdot user would raise themselves to at least that minimum level of conduct before pressing submit?
Look what I found with my fold-up trenching shovel: it's the original OpenBSD security advisory with diff output dated to 26 June 2002.
This bug can be exploited remotely if
ChallengeResponseAuthentication
is enabled in sshd_config. This option is enabled
by default on OpenBSD and other systems.
Now let's look at some of the points raised in consideration of why it happened and whether it might (or most definitely will) happen again.
b. We could not alert the community that disabling
ChallengeResponseAuthentication solved the problem, since
this would highlight that the bug is in about 500 out of
27,000 lines of code.
One detail we glean here is that OpenSSH has become a rather large body of code. This is the heart of the troubled teenage years of the OpenSSH project, when the body of code is filling out as it enters its adult years faster than a principled audit can keep pace.
3. Short-Term Solution:
Disable ChallengeResponseAuthentication in sshd_config.
and
Disable PAMAuthenticationViaKbdInt in sshd_config.
Alternatively you can prevent privilege escalation
if you enable UsePrivilegeSeparation in sshd_config.
If UsePrivilegeSeparation had been enabled in OpenBSD at that time, they presently be advertising on their web page having no remote root exploits in the last ten years. Why would do all the work to create this feature, and then not employ it? Another clue emerges:
h. Some vendors were initally upset by this policy of non-disclosure,
largely because the UsePrivilegeSeparation code was only about 90%
functional in OpenSSH 3.3:
People were upset with the suggestion to employ priv-sep because it wasn't entirely finished yet. What is clear however, is that in the time period leading up to the discovery of this exploit, the OpenBSD team was devoting considerable energy to mitigating the risk at the most fundamental level: reducing the 27,000 body of code running with root to a far smaller nucleus.
From an old SecuriTeam commentary (emphasis mine).The basic idea behind privilege separation is that OpenSSH sshd(8) has something like 27000 lines of code. A lot of them run as root. However, when UsePrivilegeSeparation is enabled, the daemon splits into two parts. A part containing about 2500 lines of code remains as root, and the rest of the code is shoved into a chroot-jail without any privileges.
Once this work was completed, the scope for root exploits (as measured in LOC) was reduced by 90% for all time. Alternately, one can view the new landscape as permitting a factor of ten increase in the resources available to conduct security audits on the 2500 lines of code which retained privilege. Perhaps if the key talent hadn't been so busy implementing priv sep, they might have had the resources available to discover the root exploit before it tarnished their unblemished record. Note that this exploit was not present in the 2500 line kernel that retained privilege.
Furthermore, the actual code defect (in the prospective non-privileged code base) was not discovered by some zit-faced l33t or random black-hat.
e. We believed very strongly that the issue was unknown in the -
Re:Exactly, mod parent up!
Looks like you don't know what you are talking about. Read here jackass smartypants: http://blogs.securiteam.com/index.php/archives/66
4 -
Re:You missed a step...
Check out this Illinois lawyer's take on the matter for the full(er) explanation: http://blogs.securiteam.com/index.php/archives/66
4 Very enlightening, but what I'm wondering is, does it really matter whether Spamhaus initially accepted any US court's jurisdiction, when Spamhaus doesn't actually live in the US? I mean, no matter what Spamhaus says, they don't live in the jurisdiction of even the federal court, so the court still doesn't hold any power over them.
-
Re:Huh?According to a very interesting analysis of the case which was originally linked from another
/. story on this case a couple of days ago, Spamhaus's problem is that they tacitly accepted the court's jurisdiction at the start, which makes it very difficult to claim otherwise now:"Spamhaus may have waived personal jurisdiction as a defense early on in the case when they not only appeared, but then asked for the case to be removed from state court (where it was originally filed) and moved to federal district court (where it is today). Arguably, and this makes sense intuitively even if you don't understand the finer points of U.S. civil procedure, doing so inherently acknowledged the jurisdiction of the federal court."
-
You missed a step...
12 Second History
Spamhaus listed E360 as spammers
E360 sued Spamhaus in an Illinois court, saying that they weren't spammers.
Spamhaus said Illinois court has no jurisdiction, take it to Federal courts.
E360 sued Spamhaus in a Federal court, saying that they weren't spammers.
Spamhaus doesn't show up to Federal court, despite having accepted their jurisdiction.
E360 won a default judgement because Spamhaus didn't show up.
Spamhaus still said the court had no authority and ignored the judgement.
E360 filed for an injunction, asking the court to order either ICANN or the domain registrar to block the Spamhaus domain because Spamhaus ignored the judgement.
Check out this Illinois lawyer's take on the matter for the full(er) explanation:
http://blogs.securiteam.com/index.php/archives/664 -
Re:Shoulda seen this coming...
Thanks for the clarification.
I've been puzzled by the comments suggesting that Spamhaus somehow chose a poor legal strategy when they moved jurisdiction to the Federal courts. For instance, in the otherwise excellent discussion of these issues at http://blogs.securiteam.com/index.php/archives/664 , Prince argues that Spamhaus's successful petition to move the case to Federal court "inherently acknowledged the jurisdiction of the federal court."
Assuming that Spamhaus wishes to argue that both the US state and Federal courts lack jurisdiction, don't they have to argue the Federal part of this issue in Federal court? Certainly they couldn't argue in Illinois state court that the Federal courts have no jurisdiction; that argument would be irrelevant in the state court. Didn't they have to first move the case to Federal court before they could contest whether the Federal court had jurisdiction? -
Re:So...get a new domain?Yesterday's slashdot article and the original source claim that the judge is to order ICANN to remove the domain, not just ordering Spamhaus to de-list itself.
There's yet another player, the actual registrar:The Internet Corporation for Assigned Names and Numbers (ICANN), which was created through a Memorandum of Understanding between the U.S. Department of Commerce and ICANN to transition management of the Domain Name System (DNS) from the U.S. government to the global community, and/or Tucows, Inc., ICANN's accredited registrar for www.spamhaus.org, is hereby ordered to suspend or place a client hold on www.Spamhaus.org until such time as they receive a further order from this Court that such suspension or client hold be lifted.
I'm not entirely certain where an Illinois District Court gets the authority to order either Tucows or ICANN to do anything, especially since neither is a party to this suit. But I get the impression that the judge does not understand how DNS works. What does it mean for "ICANN and/or Tucows" to "suspend or place a client hold"? -
One last time...
Spamhaus implicitly asked the court to take jurisdiction when they ask for the case to be transferred from state to federal court.
If they had done nothing, the court probably would have dismissed the charges for lack of jurisdiction.
If they had asked the court to drop the charges because they were a UK entity and a US court doesn't have jurisdiction, the court probably would have agreed.
But no, they explicitly asked for the case to be transferred to federal court, implicitly acknowledging the jurisdiction of the court and then they never came back.
The judge is saying, "You asked for this. We went to a lot of trouble to accommodate you. Where are you? If you don't show up, I'll have to find for the plantiff."
They shot themselves in their own foot.
Matthew Prince has a good summary. -
webserver couldnt handle 100-fold increase in hits
Therefore, here is the blog posting text:
ICANN ordered by Illinois court to suspend spamhaus.org
gadi - October 7, 2006 on 4:12 am | In Web, Commentary, Culture, Networking |
Information about this court ruling can be found on Spamhaus's web site, here:
http://www.spamhaus.org/archive/legal/e360/kocoras _order_6_10.pdf
Apparently, at this stage, it is only a proposed ruling. But I am no lawyer.
This story has been discussed before, when Spamhaus, which is located in the UK, was sued in the US by a spammer.
http://blogs.securiteam.com/index.php/archives/608
They refused to come before the court as "they do no business in Illinois, and are located in the UK.
Legal issues aside, imagine what would happen if Spamhaus was forced to present itself before courts all over the world, where they don't even do business. They are a volunteer organization and spammers will stop at nothing to get at them.
After this court ruling, Spamhaus.org was under a DDoS attack, in my opinion for the purpose of preventing users from reaching the information it provided about the court ruling.
This was done along-side a Joe Job, sending fake email appearing to come from Spamhaus's CEO, Steve Linford. This email provided disinformation about the court ruling, claiming that anyone who uses the Spamhaus service can be facing legal action. This was false.
This court order (potential court order) to ICANN is the one of the most dangerous things that could potentially happen to the Internet, and it needs to be squashed. Next, we would see the court going after Spamhaus mirrors, Registrars or RIRs.
ICANN, while being composed of good people who do try and do good, does very little as an organization where it comes to stopping abuse. A lot of this abuse involves millions on millions of domain names. These are used for spam, phishing, CP, botnets and a lot of other such activities.
IF ICANN can now potentially be used to:
1. Attack an organization that keeps a lot of the Internet sane. Not just spam-free, but rather actively helps the fight against CP, phishing, etc.
2. Circumvent International law, forcing a foreign entity to answer the call of a court around the world, which ruled wrongly on business they don't actually do.
3. Shoot itself in the foot, forcing the formation of a sort of alternate root (we will keep using Spamhaus, folks, no matter what) or a move to a different TLD or a ccTLD. It will no longer be a relevant body. Hey, everybody is talking about how to keep Spamhaus alive. That's an idea that floats around a lot.
It will be a precedent which will open a can of worms, and there will be no end to it. This court ruling needs to be attacked with all possible force, by ICANN, the community, the news and everyone else who cares.
I still have faith in ICANN's good people, and I still have faith in the law enforcement officers who use what Spamhaus freely gives to the world. I also have faith in the judges of the Illinois court, and believe they will make the right call.
This Illinois court will meet with a clue stick and clue up, they don't currently seem to be very tech-savvy to me.
I am not sure at all ICANN can ignore such an order when it comes. ICANN will prevent this legal action, or something else will be done. Otherwise, maybe it IS time for an alternate root, as the alternate evil seems very shiny right now.
This is all yet to be determined, and mostly my opinion beyond the URLs provided. This, however, needs to be addressed. It is serious.
For now, what would be very nice is to see every ccTLD that "cares" provide with a free, courtesy domain name, and point to Spamhaus's IP addresses. Spamhaus.co.il, Spamhaus.jp, etc.
I am rather inflamatory in this post, but to be honest, the world isn't going to end, I will still go to Spmahaus's website even if I have to go to .co.uk instead of .org.
Gadi Evron -
ZERT fix and FAQ entry written tooThere was a 3rd party fix from Zeroday Emergency Response Team http://isotf.org/zert/ (ZERT) available too and FAQ document written: http://www.securityfocus.com/bid/20096/references
FAQ document here: http://blogs.securiteam.com/?p=640
-
Re:firefox
Yes some of hosting prefer to used Usermin because it consists of a simple web server, and a number of CGI programs which directly update user config files like ~/.cshrc and ~/.forward.But the posibilities of the exploit to discover vulnerability in Webmin/Usermine slightly higher and you have to upgrade the patch frequently. Some of the latest vulnerability updates: http://www.securiteam.com/exploits/5GP0F00J5S.htm
l and yet cPanel have some input that isn't properly sanitised before being returned to the user. This can be exploited to execute arbitrary HTML and script code in a user's browser session in context of an affected site. -
Article misses every single relevant point
Of course you lose personalization when you're anonymous. The reporter should change his name to TautologyMan.
Cookies are less of an issue if you use a proxy that rewrites them on the fly to be session-only and encrypted (like anonymizer.com, if they're still running).
Here are some of the real problems.
To provide reasonable anonymity your proxy has to block Java and Javascript. Many sites will stop working.
Given my line of work I researched Tor and out of the first N places I tried to visit, the fraction that blocked Tor exit nodes was 100%. Now that's a real inconvenience.
If you're using a single-stage proxy instead of Tor then the anonymizing proxy might be a honeypot.
A single-stage proxy only protects you from being identified by the destination web site. Your ISP could still have records of where you went and when.
You're still identifiable by the remote site if you've ever visited it before, if it left a cookie, and if you don't have something in place to block cookie transmission. One visit to cheerleadersincombatboots.com you might explain as a slip of the mouse, weekly visits over a year could get you in trouble.
It's hard to get IP-hiding proxies right. Your IP might leak if there's a transparent proxy between you and the anonymous proxy, if you use Internet Explorer, or you could be hit by a bug in the anonymous proxy's Javascript blocking. How many undiscovered, unfixed, or reintroduced bugs are there in whatever anonymous proxy you use? -
Article misses every single relevant point
Of course you lose personalization when you're anonymous. The reporter should change his name to TautologyMan.
Cookies are less of an issue if you use a proxy that rewrites them on the fly to be session-only and encrypted (like anonymizer.com, if they're still running).
Here are some of the real problems.
To provide reasonable anonymity your proxy has to block Java and Javascript. Many sites will stop working.
Given my line of work I researched Tor and out of the first N places I tried to visit, the fraction that blocked Tor exit nodes was 100%. Now that's a real inconvenience.
If you're using a single-stage proxy instead of Tor then the anonymizing proxy might be a honeypot.
A single-stage proxy only protects you from being identified by the destination web site. Your ISP could still have records of where you went and when.
You're still identifiable by the remote site if you've ever visited it before, if it left a cookie, and if you don't have something in place to block cookie transmission. One visit to cheerleadersincombatboots.com you might explain as a slip of the mouse, weekly visits over a year could get you in trouble.
It's hard to get IP-hiding proxies right. Your IP might leak if there's a transparent proxy between you and the anonymous proxy, if you use Internet Explorer, or you could be hit by a bug in the anonymous proxy's Javascript blocking. How many undiscovered, unfixed, or reintroduced bugs are there in whatever anonymous proxy you use? -
Re:Injection preventation doesn't need input check
Well, better to light a candle rather than curse the darkness.
Here is an article for beginners about SQL injection hacks. -
PowerPoint vulnerability FAQ document released
There is related Frequently Asked Questions document published too, it was mentioned at CVE entry http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE
- 2006-3590 of this PowerPoint vulnerability:
http://blogs.securiteam.com/?p=508