To the german speaking people: the Pirate Party Austria has published a letter that you can send to your MEPs. The list of austrian MEPs can be found here. The list of german MEPs can be found here.

STOP written declaration 29 NOW! This declaration wants every search engine query in the EU to be tracked and watched!

A more accurate analogy would be going fishing for tuna and accidentally catching a dolphin.

This is why another poster said that accidental would be if that had happened on one car in one city during a beta test.

Because after that, you look at the data you have gathered and discover your accident. Imho this should be discovered even before such a beta test, as any company that respects privacy should have internal audits set up that discover that kind of misconfiguration.

So, after Google went fishing for tuna and accidentally caught many dolphins, they must have noticed this but obviosly decided that they were absolutely okay with a process that illegally caught as many dolphins as tuna fish and even decided to do this all over the world for years.

Accident? I don't think so. Within that four years that Google has been sniffing the private data, many persons must have noticed that fact.

This means that Google does not give anything about privacy and does not even implement the most basic protections against accidental privacy violations in their workflow.

Google is probably the one company with the most intimate knowledge about a very large mass of people. They know all your search terms (Google Search), your emails (GMail), your documents (Google Docs), your journeys (Google maps) and even your health records (Google Health). Also they now have pictures of your car, your house and garden as well as the SSID of you WLAN, your MAC and in some cases even some data from within your WLAN.

Now, if such a powerful company with that large amount of private data demonstrates, that it is not even remotely capable of not driving through the whole world without violating everybody's privacy, don't you think that this should in fact concern me or anybody?

Just as a person shouting from a window has no reasonable expectation that passersby will somehow "shut their ears" [...]

Just as I should have a reasonable expectation that it will not be recorded and that such a recording would be published without my consent by a passersby when I talk to a friend on the open street, I should have a reasonable expectation that no large corporation is peeking over my fence into my garden or sniffing my WLAN traffic in order to publish/sell/give away that data.

The folks at VUPEN have found a way to bypass DEP as long as javascript is enabled.

Because so many posters here wrote that DEP is the cure I'd like to make clear that DEP is not a panacea.

DEP makes exploitation of the flaw much harder to do and the exploit that was used does not work with DEP enabled, but that does not mean that the underlying vulnerability can't be exploited with DEP enabled. It's just much harder to do. Even Microsoft admits that:

from the security advisory:

You are right. However, this was a reply to this parent post.

The parent asked for recommendations for what end users could do to protect themselves and whether AV detection would catch it. Now why is your comment informative and mine is modded offtopic? I just pointed out to the parent poster, that some of the informations he claimed to be missing was actually in right in the TFA.

according to TFA:

Malware description
Threatname: Backdoor.Win32.Buzus.croo
Aliases: Trojan-PWS.Win32.Lmir (Ikarus, a-squared); TR/Hijacker.Gen (AntiVir); Trojan/Win32.Buzus.gen (Antiy-AVL); W32/Agent.S.gen!Eldorado (F-Prot, Authentium); Win32:Rootkit-gen (Avast); Generic15.CBGO (AVG); Trojan.Generic.2823971 (BitDefender, GData); Trojan.Buzus.croo (Kaspersky, QuickHeal); Trojan.NtRootKit.2909 (DrWeb); Trj/Buzus.AH (Panda).

Hiring hackers (part 2).

Text:

This is the second of a two-part series on hiring hackers and criminal hackers into IT groups as programmers, network administrators and security personnel.

In a previous series of articles in this column in 2005, I discussed general principles of security when evaluating candidates for any position. A more extensive resource is "Personnel Management and INFOSEC" which, with some expansion, became the chapter on "Employment Practices and Policies" in both the Fourth and Fifth Editions of the Computer Security Handbook (CSH5).

Chapter 12 of the CSH5 is "The Psychology of Computer Criminals" by Dr. Q. Campbell and David M. Kennedy. The authors point out that research on computer criminals suggests that some criminal hackers may exhibit addictive or compulsive behavior resulting from "a combination of compulsive behaviors and curiosity." In addition, "the need for power and recognition by their peers may both be motivating factors for some cybervandals. Computer criminals report feelings of enjoyment and satisfaction when they prove themselves better than system administrators and their peers." [p 12.3]

In another section, the authors report research that suggests that criminal hackers may "alter their thinking to justify their negative actions.... Immoral behaviors can be justified by comparing them to more egregious acts, minimizing the consequences of the actions, displacing responsibility, and blaming the victim[s] themselves."

Another problem is that some criminal hackers may exhibit traits associated with clinical personality disorders such as the narcissistic personality disorder. One of the most important aspects of this disorder is the sense of entitlement. Campbell and Kennedy write, "Entitlement is described as the belief that one is in some way privileged and owed special treatment or recognition.... When corporate authority does not recognize an individual's inflated sense of entitlement, the criminal insider seeks revenge via electronic criminal aggressions."

Dr. Jerrold M. Post wrote Chapter 13 of the CSH5, "The Dangerous Information Technology Insider: Psychological Characteristics and Career Patterns." He agrees that many criminal hackers who are employees (insiders) show signs of personality disorders. In particular, he warns that several types of insiders who have a past history of criminal hacking may engage in dangerous hacking such as inserting logic bombs for extortion, theft of information for industrial espionage, and development of a sense of ownership over the entire system for which they have been hired as system administrators.[p 13.7]

Post has a list of recommendations for all IT hiring which are as follows:

• The hiring process for employees in sensitive positions should be redesigned.

• Monitoring, detection and management should be improved.

• Clear information technology policies should be formulated and briefed to incoming employees. An employee cannot be found in violation of a procedure if it is not clearly formulated and communicated.

• Specialized support services for IT employees should be established. For example, IT employees are often reluctant to meet with an Employee Assistance Program (EAP) counselor but may avail themselves of online support services.

• Screening and selection procedures should be augmented to include online behavior by searching the Web using search engines.

• Termination procedures are formalized.

• Management of CITIs [computer information technology insiders] must be strengthened.

• Enforce computer ethics policies and mandated practices.

• Incorporate innovative approaches to the management of at-risk IT personnel.

• Add human factors to computer security audit.

I recommend the following precautionary measures be added to the usual hiring scrutiny when a candidate has revealed a questionable (criminal or borderline) hacking past (or present) or been discovered through a background check to have been or be involved in such hacking:

• Challenge the candidate openly and directly during an early interview about their actions; watch and listen carefully to evaluate the degree of honesty and insight with which the candidate discusses his or her past behavior.

• Ask the candidate to analyze a specific instance (which you select for discussion) of their past behavior from an ethical perspective; evaluate their depth of understanding of the ethical issues and of the ethical-reasoning process.

• Pose a hypothetical case involving a technically gifted employee who is badly treated by a supervisor and comes to feel abused. Ask the candidate to describe how such an employee might feel and what actions the employee might use to act on his resentments. Evaluate whether the candidate sympathizes with or approves of retaliatory behavior (you are looking for a sense of entitlement).

• Describe a case of criminal hacking in which someone's personally identifiable information is stolen and used for identity theft. Ask the candidate to describe how the victim might feel. Look for signs of empathy (or its absence).

It is useful to test these questions on a couple of willing volunteers of known probity and long, loyal service among your technically-gifted employees to establish a baseline of responses from honest people and also for practice in asking the questions.

So before you hire a hacker, verify, then trust, then verify.

I did practice Falung Gong for half a year, and although I no longer believe in it, I still stand up to defend the cultivation practice any time. Their one and only law is that of Truthfulness, Compassion and Tolerance. And every falun gong practitioner I ever met tried to follow these "rules" as best as he could. Thus meaning that Falun Gong indeed is good. And the goverment is prosecuting them, putting them in labour camps and torturing them to death for no other reason than them trying to be compassionate, thruthful and tolerant! This makes China==bad. So, yes, FG=good, China=bad. Falun Dafa hao.

If your first priority is to be truthful and you are a follower but the government tries to get you to deny your believes, you have a problem. And this usually means most severe torture without the practitioner betraying his believes but instead upholding the ideals of Truthfulness, Compassion and Tolerance, even against those who turture them. Now tell me that this is not as good as one can be!

And how can you exercise that right? It's true, you do have that right. But you can only assert that right if you know that somebody is going to upload a picture of you. So, how do you know?

In case somebody uploaded your foto without consent, you can have them remove it and/or sue them but the information is already published and nothing will change that fact.

And how can I know about every photo of me that has been published? How can I search for them? How do I even know when a photo has been taken - say from traffic cams, hidden cams, etc.?

Don't get me wrong, I love this law and this is why google earth had to blur all faces in my country but it does not protect me from somebody uploading my photo. It does not even protect me from somebody then tagging my photo with my real name, e.g. in some social networking site I don't even know exists. And since I can't search for photos that show me but which I do not have (because someone else took it), I will never find out in order to get it removed which would be too late anyway.

The problem here is that the MAFIAA will use this againt the consumer, citing "loss due to piracy". They do not seem to take into consideration that their own behaviour might be turning away customers, it's always piracy.

In effect, consumers have virtually not the possibility to boycott the RIAA and friends as this only seems to strengthen their arguments. Oh, how I hate them and their monopoly.

I agree.

AFAIK, the idea that passwords have to be changed in intervals from one to three months comes from the old days back when many terminal users used one Unix system that had /etc/passwd files. These were crypt() hashed so anybody could read them and start cracking them. One day some TLA calculated how much time it would take an attacker with serious resources (or better, what was regarded as a serious resourece back then) to brute force crack a password. They came up with something like "a crypt hash would be reasonalbe secure for two months, so if it is changed every month, it will be secure. This ended up written into some rainbow book (orange?) and from there on it was simply copied to all other standard security books and references.

According to my knowledge, this is why we are stuck now with every best practice guide still portraying the idea that passwords have to be changed in regular intervals.
[quotation needed]

Of course, this has been outdated at least since shadow passwords were introduced, let alone Moore's law or Rainbow tables.

10. They were just a bunch of students making a cool experiment that got out of hands. Once they realised that the problems started when they tried to make money out of it - since the feds could follow the money trail - they abandoned it. This is also why it did not carry a harmful payload for a long time and why the only malicious payload quickly self-destructed itself.

11. It really is the creation of some TLAs somewhere, from Mossad to CIA or FSB or the Secret Service of Trinidad & Tobago or such. This is why Conficker dropped real malicious payload only for a short time: if you want to have a large army of bots to attack other nations in the case of war, it does not make sense to drop a malicious payload - you don't want to go through the hassle of actually making some money, but you can't afford someone to find this out; also, you do not want to destroy or harm your bots hosts or make your bot appear more dangerous to their host maintainers than necessary since they might put more effort into removing your bot. But not deploying any malicious payload at all turned out to spark all sorts of speculations and media interest so they had to make Conficker drop a plausible payload that self-destructed after a short while.

12. Some mafia guys though of hiring a bunch of experts for the development of the perfect and most advanced botnet and it all worked fine. Until they realized that this one perfect botnet created thousands of times the media and police attraction that all other bots preceding them combined. So as then any Security researcher, every cyber-crime unit and any self-proclaimed virus hunter was watching them they abandoned the project and instead returned to deploying hundreds of less effective smaller-scale bots that also got them loads of money but no media attention instead.

10. They were just a bunch of students making a cool experiment that got out of hands. Once they realised that the problems started when they tried to make money out of it - since the feds could follow the money trail - they abandoned it. This is also why it did not carry a harmful payload for a long time and why the only malicious payload quickly self-destructed itself. 11. It really is the creation of some TLAs somewhere, from Mossad to CIA or FSB or the Secret Service of Trinidad & Tobago or such. This is why Conficker dropped real malicious payload only for a short time: if you want to have a large army of bots to attack other nations in the case of war, it does not make sense to drop a malicious payload - you don't want to go through the hassle of actually making some money, but you can't afford someone to find this out; also, you do not want to destroy or harm your bots hosts or make your bot appear more dangerous to their host maintainers than necessary since they might put more effort into removing your bot. But not deploying any malicious payload at all turned out to spark all sorts of speculations and media interest so they had to make Conficker drop a plausible payload that self-destructed after a short while. 12. Some mafia guys though of hiring a bunch of experts for the development of the perfect and most advanced botnet and it all worked fine. Until they realized that this one perfect botnet created thousands of times the media and police attraction that all other bots preceding them combined. So as then any Security researcher, every cyber-crime unit and any self-proclaimed virus hunter was watching them they abandoned the project and instead returned to deploying hundreds of less effective smaller-scale bots that also got them loads of money but no media attention instead.

I do also suspect that the CR/LF conversion might be the source of his troubles. Thus, it's not a bug, it's a feature of the ftp protocol. I guess you could simply use binary mode for the ftp transfer.

Now, let's assume that it's not an CR/LF problem but that instead for some unknown reason the ftp transfers get aborted and thus the file size mismatches.

Okay, first of all, if you want to guarantee that a file that departed from one system is the very same file after its arrival on another system it is not wise to use the file size for verification, as the two files could have the same length but different contents. Therefore typically md5sum is used. Or better yet, use both MD5 and SHA-1 hashes so nobody could probably ever produce meaningful collisions for both of them at the same time.

Now, what programs should be used for the transmission itself? Well, that depends on your requirements: Is confidentiality important or is it really just about integrity and availability? Is speed or link saturation a topic? Like, if your current pipe is like 80% full, you probably cannot afford to encrypt your data. Otherwise, of course you should except for like if an IPS/IDS maintainer wants to be able to scan the contents. Let's take a look at both possibilities:

• First: Confidentiality not an issue but bandwidth/speed/IDS is

Basically suitable is every tcp data transfer application that does by itself not meddle with the data itself. So this kind of excludes ftp as it can substitute CR/LF (Unix) line brakes with CR (Windows) ASCII text line brakes while transferring data from UNIX to windows and vice versa. But then again, you can use FTP just fine if used in binary mode. However, even the Swiss army knife of network transmissions can be easily used for the purpose of reliably transmitting files from A to B: netcat.

nc or nc.exe is available for both Windows and Unix and is often used in the forensics world in manual combination with md5 and/or sha-1 hashes to transmit forensic evidence from e.g. a suspect drive to the examiners workstation. Here the chain of evidence would be maintained by recording a hash of the data on the suspect drive, recording a hash of the data on the examiners workstation after arrival and recording the date, time and contents of the transmission. Note that it might be vital to have a log of what has been transferred when so that it can be proven that you sent some data the other party claims to never having received it. So, recapping, e.g. netcat, ftp, SMB/CIFS shares, HTTP and any other TCP based file transfer utility could be used. HTTP and FTP could even be easily scanned for viruses/malware during transit. UDP based file transfer utilities could be used as well as long as the implementation does take care of the integrity. As most likely a short script would be used in order to generate logs containing MD5 and SHA-1 hashes on both sides, the time and date of the transfer and the filename, this script could as well easily handle data retransfers in the case of packet loss.

• Second an better: confidentiality with some bandwidth and CPU constraints

Sorry, this posting by now bores me. So, the recap:

Use SSH (SCP), cryptcat (used among others in forensics for the chain of evidence when confidentiality is an issue), HTTPS, SMIME or any other encrypted transfer tool, really. Hell, you could even generate an encrypted PGP file or whatever with a script and pipe it through whatever data transfer application you want. (Like ftp in binary mode ;) )

So, overall, what are needed here are two small scripts that do something like this:

On the sending side:

10 compute SHA-1 / MD5 hash of a file to be transferred (and optionally compress it) 20 send file 30 receive a SHA-1 / MD5 hash of the transferred file from the receiver 40 compare the hashed 50 complete transaction including logging the date, time, filename and hash, if hashed match 60 else goto 20

On the receiving side: 10 receive file 20 generate SHA-1 / MD5 hash of the received file 30 send SHA-1 / MD5 hash back to the sender of the file 40 goto 10 if same file is resent, otherwise complete transaction recording date, time, filename and hash.

Those are pretty simple scrips but they assume that you can run a script or some custom software on the receiving end. If you can't do so, all you could do is to sniff the transmission traffic, extract the file from that stream and compare the hashes of both. That should be enough to hold even in a court: Here we have the evidence that the file has been sent by the transmitting script/application (hash of application log) and there we have the evidence that it has been transmitted on the wire, including the acknowledgements of the receiver (hash of the sniffer extracted data).

Why again was that trivial question posted on /.?