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.
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:
This vulnerability is more difficult to exploit successfully if Data Execution Protection (DEP) is enabled for Internet Explorer.
Even still, this blog post is fucking useless. What CMS? What input is not being validated? Is it an underlying problem with Drupal? Wordpress? Joomla? What version? On top of that, it doesn't give any recommendations for what end users could do to protect themselves. Does anti-virus software already detect it? Can you simply alter your hosts file? Disable Javascript?
The blog post is completely fucking useless.
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.
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 hirin
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.
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
I do also suspect that the CR/LF conversion might be the source of your 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 COFEE stick is used for "merely" acquiring digital evidence. See this part of your quote:
for later interpretation by computer experts
The summary describes a tool that will also interpret the evidence found.
What COFEE will do for you is to gather volatile information on life windows systems like running processes, open network connections, system date and time, RAM contents etc. The disk contents are not acquired as they will supposedly remain as they are.
In contrast to this the tool the summary mentions should not acquire any evidence but instead search through existing evidence and interpret it, like searching through your harddrive for keywords on a bad word list or searching for hashes of known kiddypr0n etc.
There is a big difference there:
If Microsoft's tool is the equivalent of a toolkit designed to help a cop take a sample of your blood for later testing of anything illegal in your blood that will not be there anymore several hours later when a doctor will do the same, the tool described in the summary is the equivalent of a tool designed to tell the cop if there is anything illegal in your blood without acquiring the blood for later analysis by an expert.
Although this is quite a bad analogy as the device in my analogy might well be technically feasibly. Let's instead consider the following analogy:
Instead of using a camera in order to take pictures of a suspected crime scene they want to use a device similar to a camera that instead of acquiring evidence from suspected crime scenes will allow a cop to look through it at any scene in order to see if a crime has happened at all.
Imagine a cop on the open street looking through a camera at you and then getting arrested because the camera told him that you somehow supposedly committed a crime.
Disclaimer: this is a redundant posting but I wanted to make sure the author of the comment saw my post which quotes a blog entry by Scott A. Moulton who is a forensic and data recovery expert and currently teaches the SANS 606: Drive and Data Recovery Forensics course.
Spinrite is not data recovery software.
I get many questions about why I left off Spinrite on my recommendations of recovery software. I specifically leave off Spinrite because under the strictest terms it is not data recovery software. Almost every single data recovery package knows, and will warn you not to write the data back to the original source drive. Data Recovery/Forensics software almost always recover from a source to a destination. Spinrite does not do that, it refreshes the surface and controls reads to get the maximum amount of data from the sectors and then puts it back down on the same drive.
I think it does quite a few things very well and it does an excellent job at reporting and reading the SMART info and refreshing the surface of the hard drive. However, I would like to first try to get the data from the drive before scanning it and trying to rebuild sectors. There are many reasons for this, but the most important one being that the drive can die in the process of running Spinrite. It is possible to do more damage to the drive by doing excessive read and writes. There are times that you only get once [sic] good chance at data and if you use a tool that just goes in and surgically removes the data you want BEFORE doing the scan you will be a lot safer.
If I was going to use Spinrite, I would get everything I could off the drive to another destination first and then use Spinrite to try to get anything I could not repair (although I never have to with the tools I use). Another horrific story I have seen with drives sent to me, is that if Spinrite it runs successfully, people are under the impression that the drive is repaired and is usable again and continue to use it. Big mistake and it usually dies again shortly. On a Windows Hard Drive I would try NTFSExplorer/FatExplorer first in the hopes of doing a surgical recovery as oppose to spending days rewriting sectors in the hopes that my drive can live though it as Spinrite does. But for $80 it is well worth the attempt if you are going to do nothing else. Good Luck.
Oct 6, 2008 11:26 PM ~ Scott A. Moulton
Also, you can find some very interesting papers/presentations/videos here.
Disclaimer: this is a redundant posting but I wanted to make sure the author of the comment saw my post which quotes a blog entry by Scott A. Moulton who is a forensic and data recovery expert and currently teaches the SANS 606: Drive and Data Recovery Forensics course.
Spinrite is not data recovery software.
I get many questions about why I left off Spinrite on my recommendations of recovery software. I specifically leave off Spinrite because under the strictest terms it is not data recovery software. Almost every single data recovery package knows, and will warn you not to write the data back to the original source drive. Data Recovery/Forensics software almost always recover from a source to a destination. Spinrite does not do that, it refreshes the surface and controls reads to get the maximum amount of data from the sectors and then puts it back down on the same drive.
I think it does quite a few things very well and it does an excellent job at reporting and reading the SMART info and refreshing the surface of the hard drive. However, I would like to first try to get the data from the drive before scanning it and trying to rebuild sectors. There are many reasons for this, but the most important one being that the drive can die in the process of running Spinrite. It is possible to do more damage to the drive by doing excessive read and writes. There are times that you only get once good chance at data and if you use a tool that just goes in and surgically removes the data you want BEFORE doing the scan you will be a lot safer.
If I was going to use Spinrite, I would get everything I could off the drive to another destination first and then use Spinrite to try to get anything I could not repair (although I never have to with the tools I use). Another horrific story I have seen with drives sent to me, is that if Spinrite it runs successfully, people are under the impression that the drive is repaired and is usable again and continue to use it. Big mistake and it usually dies again shortly. On a Windows Hard Drive I would try NTFSExplorer/FatExplorer first in the hopes of doing a surgical recovery as oppose to spending days rewriting sectors in the hopes that my drive can live though it as Spinrite does. But for $80 it is well worth the attempt if you are going to do nothing else. Good Luck.
Oct 6, 2008 11:26 PM
Also, you can find some very interesting papers/presentations/videos here.
You can get a very good explanation of why not here.
I am referring to a blog entry from Scott A. Moulton who is a forensic and data recovery expert and currently teaches the SANS 606: Drive and Data Recovery Forensics course.
Spinrite is not data recovery software.
I get many questions about why I left off Spinrite on my recommendations of recovery software. I specifically leave off Spinrite because under the strictest terms it is not data recovery software. Almost every single data recovery package knows, and will warn you not to write the data back to the original source drive. Data Recovery/Forensics software almost always recover from a source to a destination. Spinrite does not do that, it refreshes the surface and controls reads to get the maximum amount of data from the sectors and then puts it back down on the same drive.
I think it does quite a few things very well and it does an excellent job at reporting and reading the SMART info and refreshing the surface of the hard drive. However, I would like to first try to get the data from the drive before scanning it and trying to rebuild sectors. There are many reasons for this, but the most important one being that the drive can die in the process of running Spinrite. It is possible to do more damage to the drive by doing excessive read and writes. There are times that you only get once good chance at data and if you use a tool that just goes in and surgically removes the data you want BEFORE doing the scan you will be a lot safer.
If I was going to use Spinrite, I would get everything I could off the drive to another destination first and then use Spinrite to try to get anything I could not repair (although I never have to with the tools I use). Another horrific story I have seen with drives sent to me, is that if Spinrite it runs successfully, people are under the impression that the drive is repaired and is usable again and continue to use it. Big mistake and it usually dies again shortly. On a Windows Hard Drive I would try NTFSExplorer/FatExplorer first in the hopes of doing a surgical recovery as oppose to spending days rewriting sectors in the hopes that my drive can live though it as Spinrite does. But for $80 it is well worth the attempt if you are going to do nothing else. Good Luck.
Oct 6, 2008 11:26 PM
Also, you can find some very interesting papers here.
One thing that nobody seems to have mentioned yet is freezer trick. If the drive is just not spinning anymore (and you do not hear a click of death), just throw your drive in a ziplock bag into the freezer for a couple of hours. Often times it will then run long enough to make a bit-to-bit (dd) copy as others already mentioned.
Slashdot Mirror
Your EFF donation link is broken. Instead, use this link. I am a bit worried that I was the first to point this out...
There, I fixed that for you: http://slashdot.org/submission/1266460/Elgato-offering-vuvuzela-filter-to-EyeTV-users?art_pos=2
STOP written declaration 29 NOW! This declaration wants every search engine query in the EU to be tracked and watched!
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 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.
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:
This vulnerability is more difficult to exploit successfully if Data Execution Protection (DEP) is enabled for Internet Explorer.
Even still, this blog post is fucking useless. What CMS? What input is not being validated? Is it an underlying problem with Drupal? Wordpress? Joomla? What version?
On top of that, it doesn't give any recommendations for what end users could do to protect themselves. Does anti-virus software already detect it? Can you simply alter your hosts file? Disable Javascript?
The blog post is completely fucking useless.
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.
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).
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:
I recommend the following precautionary measures be added to the usual hirin
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!
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.
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.
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:
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.
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
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
video.
for later interpretation by computer experts
The summary describes a tool that will also interpret the evidence found.
What COFEE will do for you is to gather volatile information on life windows systems like running processes, open network connections, system date and time, RAM contents etc. The disk contents are not acquired as they will supposedly remain as they are.
In contrast to this the tool the summary mentions should not acquire any evidence but instead search through existing evidence and interpret it, like searching through your harddrive for keywords on a bad word list or searching for hashes of known kiddypr0n etc.
There is a big difference there:
If Microsoft's tool is the equivalent of a toolkit designed to help a cop take a sample of your blood for later testing of anything illegal in your blood that will not be there anymore several hours later when a doctor will do the same, the tool described in the summary is the equivalent of a tool designed to tell the cop if there is anything illegal in your blood without acquiring the blood for later analysis by an expert.
Although this is quite a bad analogy as the device in my analogy might well be technically feasibly. Let's instead consider the following analogy:
Instead of using a camera in order to take pictures of a suspected crime scene they want to use a device similar to a camera that instead of acquiring evidence from suspected crime scenes will allow a cop to look through it at any scene in order to see if a crime has happened at all.
Imagine a cop on the open street looking through a camera at you and then getting arrested because the camera told him that you somehow supposedly committed a crime.
Also, there seem to be many other youtube videos about data recovery there as well.
Quoted from here:
Spinrite is not data recovery software. I get many questions about why I left off Spinrite on my recommendations of recovery software. I specifically leave off Spinrite because under the strictest terms it is not data recovery software. Almost every single data recovery package knows, and will warn you not to write the data back to the original source drive. Data Recovery/Forensics software almost always recover from a source to a destination. Spinrite does not do that, it refreshes the surface and controls reads to get the maximum amount of data from the sectors and then puts it back down on the same drive.
I think it does quite a few things very well and it does an excellent job at reporting and reading the SMART info and refreshing the surface of the hard drive. However, I would like to first try to get the data from the drive before scanning it and trying to rebuild sectors. There are many reasons for this, but the most important one being that the drive can die in the process of running Spinrite. It is possible to do more damage to the drive by doing excessive read and writes. There are times that you only get once [sic] good chance at data and if you use a tool that just goes in and surgically removes the data you want BEFORE doing the scan you will be a lot safer.
If I was going to use Spinrite, I would get everything I could off the drive to another destination first and then use Spinrite to try to get anything I could not repair (although I never have to with the tools I use). Another horrific story I have seen with drives sent to me, is that if Spinrite it runs successfully, people are under the impression that the drive is repaired and is usable again and continue to use it. Big mistake and it usually dies again shortly. On a Windows Hard Drive I would try NTFSExplorer/FatExplorer first in the hopes of doing a surgical recovery as oppose to spending days rewriting sectors in the hopes that my drive can live though it as Spinrite does. But for $80 it is well worth the attempt if you are going to do nothing else. Good Luck.
Oct 6, 2008 11:26 PM ~ Scott A. Moulton
Also, you can find some very interesting papers/presentations/videos here.
Quoted from here:
Spinrite is not data recovery software. I get many questions about why I left off Spinrite on my recommendations of recovery software. I specifically leave off Spinrite because under the strictest terms it is not data recovery software. Almost every single data recovery package knows, and will warn you not to write the data back to the original source drive. Data Recovery/Forensics software almost always recover from a source to a destination. Spinrite does not do that, it refreshes the surface and controls reads to get the maximum amount of data from the sectors and then puts it back down on the same drive.
I think it does quite a few things very well and it does an excellent job at reporting and reading the SMART info and refreshing the surface of the hard drive. However, I would like to first try to get the data from the drive before scanning it and trying to rebuild sectors. There are many reasons for this, but the most important one being that the drive can die in the process of running Spinrite. It is possible to do more damage to the drive by doing excessive read and writes. There are times that you only get once good chance at data and if you use a tool that just goes in and surgically removes the data you want BEFORE doing the scan you will be a lot safer.
If I was going to use Spinrite, I would get everything I could off the drive to another destination first and then use Spinrite to try to get anything I could not repair (although I never have to with the tools I use). Another horrific story I have seen with drives sent to me, is that if Spinrite it runs successfully, people are under the impression that the drive is repaired and is usable again and continue to use it. Big mistake and it usually dies again shortly. On a Windows Hard Drive I would try NTFSExplorer/FatExplorer first in the hopes of doing a surgical recovery as oppose to spending days rewriting sectors in the hopes that my drive can live though it as Spinrite does. But for $80 it is well worth the attempt if you are going to do nothing else. Good Luck.
Oct 6, 2008 11:26 PM
Also, you can find some very interesting papers/presentations/videos here.
I am referring to a blog entry from Scott A. Moulton who is a forensic and data recovery expert and currently teaches the SANS 606: Drive and Data Recovery Forensics course.
Spinrite is not data recovery software. I get many questions about why I left off Spinrite on my recommendations of recovery software. I specifically leave off Spinrite because under the strictest terms it is not data recovery software. Almost every single data recovery package knows, and will warn you not to write the data back to the original source drive. Data Recovery/Forensics software almost always recover from a source to a destination. Spinrite does not do that, it refreshes the surface and controls reads to get the maximum amount of data from the sectors and then puts it back down on the same drive.
I think it does quite a few things very well and it does an excellent job at reporting and reading the SMART info and refreshing the surface of the hard drive. However, I would like to first try to get the data from the drive before scanning it and trying to rebuild sectors. There are many reasons for this, but the most important one being that the drive can die in the process of running Spinrite. It is possible to do more damage to the drive by doing excessive read and writes. There are times that you only get once good chance at data and if you use a tool that just goes in and surgically removes the data you want BEFORE doing the scan you will be a lot safer.
If I was going to use Spinrite, I would get everything I could off the drive to another destination first and then use Spinrite to try to get anything I could not repair (although I never have to with the tools I use). Another horrific story I have seen with drives sent to me, is that if Spinrite it runs successfully, people are under the impression that the drive is repaired and is usable again and continue to use it. Big mistake and it usually dies again shortly. On a Windows Hard Drive I would try NTFSExplorer/FatExplorer first in the hopes of doing a surgical recovery as oppose to spending days rewriting sectors in the hopes that my drive can live though it as Spinrite does. But for $80 it is well worth the attempt if you are going to do nothing else. Good Luck.
Oct 6, 2008 11:26 PM
Also, you can find some very interesting papers here.
One thing that nobody seems to have mentioned yet is freezer trick. If the drive is just not spinning anymore (and you do not hear a click of death), just throw your drive in a ziplock bag into the freezer for a couple of hours. Often times it will then run long enough to make a bit-to-bit (dd) copy as others already mentioned.