Companies and organizations are becoming more aware of these type of vulnerabilities and have come up with some ways to supress these security holes, one of which is called “war-walking”, otherwise known as “war-driving”.  War-driving is primarily something a hacker would do which consists of having a laptop with a wireless access card, and driving/walking around sniffing for wireless networks, noting the vulnerable ones.  By using one of hacker’s most used methods of finding vulnerabilities, companies can find them before they can be used.  Security professionals can perform a walk of the building looking for any wireless access points that are unauthorized and pinpoint the ones that aren’t.

As with all battles between security professionals and malicious adversaries, the hackers have come up with methods to resist their own attack methods.  One is to use a wireless access point that broadcasts on a frequency that is out of range of the strict FCC regulated frequency.  Such WAPs can come from Europe or Japan, in which these frequencies are legal.  This makes these wireless access points undectable to people sniffing in the legally operating range.   Also, 802.11n is a fairly new technology, which many companies have not updated to yet, and therefore if they are using a card that uses the older wireless methods, they will be unable to sniff for the 802.11n WAPs.

Also, in addition to 802.11 wireless, even bluetooth, a technology assumed by most to only operate at short ranges, could be used in the same way that WAPs are used.  Since the war-walking company security experts would most likely be using an 802.11 card, the bluetooth traffic would be unrecognized.

One final method strikes me as very clever: wireless knocking.  A WAP is kept dormat, blocking any traffic on all ports, until a certain event happens.  When the correct sequence of ports are attempted to be accessed at this WAP, it opens up a specified port on the WAP for traffic to go through.  This is essentially like a passcode encoded into the WAP.  It makes it very hard for anyone to try and guess the “knocking sequence”, but quite easy for the adversary who installed it to access it and gain access to whatever networkt he WAP is hooked up to.

This current event (of analyzing WAPs) makes me realize that, although most malicious adversaries are out to weaken other people’s security and find security holes, in the meantime they themselves are creating their own security mechanisms in order to block being detected.  To this it is the security professionals that must work to break this security – and the vicious cycle continues…

Professional cycling, however, is a very different story. Combining the commercialism of motorsport racing with athletic demands exceeding almost any other sport, the pressure on riders to perform is tremendous. Good performance not only makes careers, but it pleases sponsors and significantly impacts their economic standing. Sponsoring a winning Tour de France team brings in tremendous revenue for a company in Europe. Continuous defeat, on the other hand, can have devastating consequences. As such, riders must reach for the leader board not only to meet their own expectations of success and competition, but simply to remain employed.

For years, dopers and anti-doping agencies have played much the same cat-and-mouse game that security researchers play with crackers. Riders use performance enhancers; researchers create tests to detect them; riders find new drugs to use, and so on and so forth. Doping was present in cycling long ago already, but it was the 1998 expulsion of the entire Festina team from that year’s Tour de France that signaled the beginning of the “doping era.” Since that year, every “grand tour” (the class defined by the Tour de France, the Giro d’Italia, and the Vuelta a España) has been plagued by expulsions, positive tests, litigations and scandals. In order to restore honor and fairness to the sport, many are crusading against the use of performance enhancing drugs. Until recently, the fervor of athlete and corporate lust for success seemed unbeatable.

According to an article by Juliet Macur in the February 28^th, 2009 edition of the New York Times, the anti-doping community has developed a new methodology for detecting cheating. Rather than attempting to detect traces of illicit chemicals in riders’ bloodstreams, drug testers are attempting to develop a “biological passport” for each rider. By comparing a rider’s current blood work against earlier tests, it is now possible to detect telltale signs of substance abuse via the changes observed in that rider’s blood. Legal action has already been brought against several riders with this biological passport as evidence.

Assets

• Riders don’t want to suffer in the ranks as a result of their competition using performance enhancing drugs
• Sponsors and team owners don’t want the cheating of other riders to reduce the acclaim, visibility, or overall performance of their respective teams.
• Race officials and fans want to see respectable racing, not battle-of-the-druggies. Cycling has been tainted in recent years by the proliferation of doping scandals.
• Every non-adversary wants final rankings to be representative of rider athleticism and effort.

Potential Adversaries

• Riders whose competitive spirit may drive them to seek “help” in order to win.
• Riders who suffer from excessive pressure from sponsors to perform.
• Sponsors, team owners, or team managers wishing for more team/product/brand visibility thanks to front-running riders.
• Doctors and researchers developing new doping methods.

Potential Weaknesses:

• Though I don’t claim to understand the biology, and while I can’t imagine that an attack this simple would be possible against the “latest and greatest” in anti-doping technology, I see one fundamental flaw in this approach. If detection of substance abuse relies on change between two test dates, the test is vulnerable to a rider who is never tested prior to adopting a doping habit. Because blood may not change once routine doping is adopted, there might not be a difference between old tests and current tests either.

Potential Defenses:

• In addition to using these “biological passports,” parallel research should continue into discovery and detection of new doping techniques. These detection methods should be applied in addition to any delta-comparison between bloodtests.
• If it is possible, attempt to correlate blood of dopers, as well as the blood of likely non-dopers (very poor performers, amateurs, etc.). It may be feasible to derive a model that can detect riders for whom an accurate “clean” sample is unavailable.

]]> http://cubist.cs.washington.edu/Security/2009/03/13/security-review-new-weapons-in-the-fight-against-doping/feed/ 0 http://cubist.cs.washington.edu/Security/2009/03/13/current-events-one-more-botnet-related-legal-fray/ http://cubist.cs.washington.edu/Security/2009/03/13/current-events-one-more-botnet-related-legal-fray/#comments Sat, 14 Mar 2009 04:52:13 +0000 oterod http://cubist.cs.washington.edu/Security/?p=1265 As part of an “expose’” on cyber crime, BBC’s “Click” team took it upon themselves to hire a botnet. With the stated goal of demonstrating the power of “cyber criminals” in today’s world, the journalists purchased the use of ~22,000 compromised machines. As part of their demonstration, they directed massive amounts of spam to two specific test addresses, and finally, used their botnet to bring down a security firm’s backup website via DDoS. The DDoS attack was done with permission from the “victim” company (Prevx).

Now the BBC group is in a spot of legal trouble as their use of a botnet could potentially implicate them in the violation of the UK’s Computer Misuse Act. While BBC claimed that their use of the botnet was purely academic, and therefore not criminal, they did take control of non-consenting citizens’ home PCs. More importantly, in purchasing the use of a botnet, reportedly at somewhere between $300-$400 per machine, the news network essentially funneled a few million dollars into the hands of cybercriminals. And all so that they could demonstrate what many papers and news articles before them already had.

The journalists, at surface level, did a good job of keeping things academic and avoiding any sort of cybercrime. They spammed their own test e-mail accounts. They DDoS’d a prepared and willing target. They also put warning documentation on the infected machines, at experiment’s conclusion, explaining to their users that they had been infected, and how to best avoid future infections. Ultimately, however, by mere involvement with and commandeering of hijacked personal machines – and especially thanks to funding the true criminal party – they did indeed commit some level of criminal act. To what degree they are held responsible is now a matter for the British courts to decide.

This is just one more occurrence in a string of botnet-related legal issues. A similar issue plagued German malware researchers with the means to potentially dissolve the Storm worm’s botnet(s) (see http://cubist.cs.washington.edu/Security/2009/01/11/storm-worm-cracked-but-defenses-may-not-fly/). It seems that academicians of all types are running into a fundamental problem with this particular security threat: there is no way to legally study it “in the wild.” The moment a researcher connects to a botnet, takes control of it, or otherwise interacts with it, he or she risks legal consequences. Whether or not any charges stick is a different matter, and quite frankly, it will take some time before reasonable precedents clarify the legal “consensus,” but regardless these issues represent a significant impediment to progress in anti-botnet research.

Assemblyman Anderson sat down for an interview with news.com to defend his position. In the interview, he argued that there is no good reason anyone would need to clearly see these buildings online, and that the only reasons a person could have for wanting to view these buildings must therefore be malicious. The politician was quoted:

“Who wants to know that level of detail? Bad people do.”

I believe the reason this event arose is because of the growing usefulness and popularity of online mapping tools. The use of the software is free, and it is turning into a necessity for many people when gathering directions to a new location. Having a beforehand image of the destination makes finding it a much easier task. Also, satellite imagery is still a novel technology that is simply fun for users to search. Mr. Anderson recognizes this popularity and sees a vulnerability in allowing the general public access it.

The issue could have been avoided if Google and other mapping utilities had policies on what they would show or requested permission before using imagery of private property. This leads into the broader debate of the ethical nature of these types of services. The satellite-map services already have policies to filer out any obscene content that may be visible, but there is still an open question regarding the rights property owners have to protect themselves from having their imagery published online. Extending from this, Assemblyman Anderson raises the more general question of whether or not particular entities should ever have their imagery publicized, regardless of their position on the matter.

Reactions are sure to be mixed about this event. While there will undoubtedly be some who support the politician, many will challenge his notion that there is no reason to look at satellite imagery of a school, church, or government building that is not malicious. Adding fuel to this is the talk of the constitutionality of requiring the images to be blurred. Assemblyman Anderson likened the situation to the legality of yelling fire. While free speech is protected, there are important circumstances where it is not. He argues that requiring these images to be blurred falls under the same category. This is certain to charge debates, as the constitution can often be a very polarizing document. Regardless, this issue is one that will have to be debated for the time to come, as the power struggle between privacy and the prevalence of information continues on.

Wired magazine has published an article detailing Notarbartolo’s story and how him and his team were able to circumvent all the various  security measures.  It was interesting to see that despite having 10 different high-tech security measures, when each problem was  considered individually, the exploit seemed simple yet ingenious.

For example, the infrared heat detector could be momentarily insulated using a thin layer of hairspray, buying enough time to physically  deactivate the detector.  Polyester shields could also insulate heat signatures, giving balcony access to the team.  Even though a forged  key was made, it turned out to be unnecessary because the guards simply kept it in a nearby supply room.

The question is, how could something like this have been prevented?  As I mentioned, when each individual security measure was considered,  each work-around seemed possible.  Considering all 10 security measures would be a daunting task.  What was interesting to note was that  each security layer protects the vault from becoming compromised, but there didn’t seem to be any specific countermeasures for preventing  someone from tampering with the security devices.  Considering how each security measure could be defeated and how security measures might  complement each other (i.e. protect each layer from tampering) would be a good way to prevent future break-ins.

Also, the thieves were able to break in because they were able to defeat predictable electronic devices.  Prior to the heist, they  gathered detailed information about the vault’s technologies, and they duplicated the vault and all its devices in order to simulate the  heist.  Once working details were confirmed, the same technology could be cracked consistently over and over.  At night, the security was  entrusted entirely to technology — no guard stood by at night to protect the vault.  Posting a guard would add a layer of uncertainty  that increases the risk of attempting a heist.

So that seems to beg the question, how much should we entrust technology to handle our problems?  From a security stand-point, probably  all technologies are fallible and are likely to fail in some way or another eventually.  At the same, the article brought up the issue of  possible insurance fraud.  There was the possibility that some of the diamond dealers were in on the heist and pulled out their inventory  secretly prior to the heist, collecting on the insurance money while keeping their diamonds.  That suggests that there wasn’t much of a  system for keeping track of where the diamonds were and whether they were really lost in the heist or not.  There needs to be a reliable  system for tracking safety deposit transactions while maintaining privacy.

This also brings up the eternal security question — how much security is sufficient?  You would suppose 10 layers of high-tech devices  would be enough to deter thieves from an attempt.  Does there need to be more security?  Or perhaps the security could be used in a more  efficient and effective way.  Who are the stakeholders?  It seems like the bank, the customers with the safety deposit boxes, and the  insurance companies should have an interest in answering these questions.

Overall, the article told an interesting story, almost as if it were out of a movie.  I highly suggest reading it just for entertainment  at the least.

This project rose out of the recognition that relatively recent advancements in cryptography and computer science have paved the way for the possibility of actually implementing election protocols that guarantee ballot casting assurance, universal verifiability, and voter secrecy. One issue that the developers of this system are facing is that the public is not really aware (or if they are, they fail to recognize the implications) of the lack of these properties in our current election system. Especially as absentee balloting is becoming more popular, there is little guarantee that 1) your vote is ever received, 2) that no one changed en route, 3) that it was counted at all, and 4) that is was counted correctly. The Helios system allows the user to verify 1, 2, and 3, and allows anyone to verify 4. The source for the Helios system is available for free under Creative Commons, and an online server is available for general use.

This new development is especially important given the recent Diebold debacle which emphasized the importance of Kerckhoffs’ principle in the development of important security systems. Entrusting something as important as democracy to some proprietary, secret code hacked up by some people under investigation for putting Trojans in ATMs is no way to go. It will be interesting whether or not this new style of election will ever be used in general governmental elections, but it hints that the day when we may actually be able to cast e-votes with confidence is drawing near. If you are interested in more details of the Helios system, a follow-up security review will be posted shortly.

A big selling point of security on many Linux or Unix systems is the distinction of Execute permissions. A downloaded file will not have the execute bit set. This means that, within a window manager, double-clicking will only attempt to read the file so the desktop system may ask what you want to do with it. Only by either explicitly telling this prompt to execute or by editing the permissions of the file from the command line can you execute this file. In either case this is an explicit action that the user must think about.

However, many distributions of Linux use a standardized .desktop ^[1] file format. These files are often used as menu items or program launcher shortcuts: they have an Exec parameter that can take an arbitrary command string to run when clicked.

[Desktop Entry]
Encoding=UTF-8
Type=Application
Terminal=false
Exec=bash -c "touch ~/haxxored"
Name=Write to an arbitrary file.

Users and developers of these distributions have recently been arguing for re-evaluation of this specification for that very reason: they allow arbitrary code execution without the need for an executable bit set on the file.

This opens up the same vulnerability in Linux systems that had previously been avoided. An inexperienced user used to double click to open might download a .desktop file and try to open it. Even a more experienced user might not realize this issue and (expecting the previously mentioned behavior of simply reading the contents of the file) click on it to see the contents.

Even more troubling is the behavior of these Desktop files when used in the menuing system for many distributions: important system applications often have menu entries in /usr/share/applications. However, menu entries with the same name in ~/.local/share (the user’s local directory) with the same Name option will override the system one! A malicious script (perhaps even started by the exploit above) could shadow the desktop entry from one of the important system applications such as the Synaptic Package Manager. Users are used to typing their passwords at the gksu prompt when clicking on Synaptic so they would do so; now a malicious script has root access to the user’s machine.

Possible Solution

The biggest part of a solution to this problem would be requiring that .desktop files simply have execute permission set. On installation of a normal program this would be a trivial addition, but downloaded .desktop files would not be run. In case of some other malicious script gaining user access, normal users should not be able to override root owned .desktop files (like Synaptic).

These solutions are extremely simple, but they have not been implemented yet due to the desire for compatibility between
different distributions. It may take time for these changes to be made.

^[1] Desktop File Specification: http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

However, the information we have is nowhere near enough to show that the certificate generating algorithm has been cracked. For one, despite the large number of new sites reporting the break, all that I’ve seen can be traced back to Outdustry. Before I saw this story, I had never heard of the site Outdustry, and given that it just looks far more like a blog than a credible news source, I must say I am skeptical of the validity of this story. As for the cheap vouchers, they may or may not have been generated by hackers. Perhaps they were bought with stolen credit card information.

Lastly, there is more to an iTunes gift certificate, or any digital gift certificate, than just a number. The agency in charge of redeeming certificates must validate each one. If the validation was entirely contained within the gift code, then there would be nothing to stop the same certificate being used multiple times. No, no matter how the keys are generated, Apple must have some way of telling used certificates from good certificates.

This raises an interesting point. If we assume that the Chinese certificates have been created by a key generator, and if those certificates work to on the iTunes store, then one of two things happened. Either the keygen created a key already in use, but not yet redeemed, or the default state for a certificate is “valid.” I count the first case as very unlikely, and the second case would be almost criminal in its exploitability.

Overall, I don’t believe any such cracking of the iTunes gift certificate format took place. Stolen money/credit cards could explain the cheap, under the table deals on certificates.

Original Source: Outdustry

Summary:

ComputerWorld had an article about Google Voice.  Google Voice is a new service offered by Google to make people’s phones more usable.  Google Voice will automatically transcribe a user’s voicemail into text form, using speech recognition software.  Because the transcription is done with software, there may be some mistakes in the text versions.  The transcriptions will be made available in the user’s inbox.  The service can also e-mail or SMS the messages to you. If I user desires the service can be turned off.

Google Voice builds on the technology of GrandCentral, a company that Google bought a few years ago.  This technology allows a user to have a single number for all of their phones.  When this number is dialed, all of the associated phones also ring.  In this way, a user can be contacted regardless of which phone (home, work, cell, etc…).  Google Voice will initially be offered to current users of GrandCentral.

Assets:

The assets involved are a significant amount of a user’s personal data.

• User’s phone numbers: this is obviously necessary for the technology to work.  Though this information can be found in phonebooks, some people value the privacy of this data.  A person’s phone number can be used for telemarketing, stalking, or (sometimes) even physical tracking using Google Latitude.
• User’s e-mail address: this is needed in order to e-mail transcriptions to a user.  These are valued to avoid spam and other unwanted communications.
• User’s personal information: this is the big one!  Recording a user’s messages may include incredibly sensitive information (perhaps messages from a mistress or creditors).  This information is now converted from sound to text, stored on Google’s servers, sent by e-mail.

Adversaries/Threats:

• Stalker: a person motivated to snoop into the details of your life could learn quite a bit about you from this service.  This personal information could be used to embarrass, blackmail, or incarcerate the user, depending on what was found.
• Government: the government could break into Google Voice, or perhaps subpoena Google into releasing its databases to law enforcement.  This could be used to monitor suspected terrorists or punish petty crimes.

Potential Weaknesses:

• I assume that a user’s transcriptions are password accessible, even if not sent by e-mail.  If this is true, then all the normal password weaknesses apply: the user may have chosen a poor password, it may be a password shared with another site, etc.
• If transcriptions can also be accessed directly from one of the phones included in the GrandCentral list, then this phone must send some signal to Google.  This signal could be recorded, and it is likely that a successful replay attack could then be staged.
• Users are frequently a weak link in the security of any system, and this will hold true for Google Voice as well.  Many users are unlikely to think about the possible security consequences associated with this service.  This may lead them to make especially poor security choices.
• If a user opts for transcriptions to be e-mailed or SMSed to them, there is the additional possibility that these messages can be intercepted.  Google may have very little control of the security of these services, which likely makes this a weak link.

Potential Defenses:

• The transcription database should be encrypted and otherwise properly protected.  It should be secure from physical access, and few employees within Google should have any kind of access to it.
• Google should take steps to properly educate the users of Google Voice of the security concerns.  Specifically, it should mandate “good” passwords and attempt to inform users about the risks inherent in converting private conversations to text, which can easily parsed by computers.  Similarly, it should warn users about the additional risks involved in e-mailing the transcriptions.

Evaluate Risks:

I think that the risks posed above have the potential to cause users significant harm.  However, much of the personal information above can be found by other means already.  The fact that we already have voicemail means that precisely this information is already in databases somewhere, albeit in voice rather than text form.  Moreover, much of this information is likely redundant to other sources of information on a person, which could be found using Google searches, dumpster diving, and general stalking.  For this reason, the biggest risk of Google Voice is that it makes personal information more accessible to adversaries than previously possible, assuming the adversaries can compromise Google’s security measures.

Conclusions:

I am highly suspicious of this service and will not be using it myself.  However, it should be noted that the vast majority of this information is already available in voicemail databases.  I do not think that this technology, if appropriately implemented, poses any new significant threats to the assets listed above.

Reference: ZDNet