Supreme Court to Decide if Drug Dogs Pass Constitutional Smell Test

Miami-Dade County Police Department K-9 “Franky” has discovered more than 2.5 tons of marijuana. Photo: Courtesy of Miami-Dade County Police Department

The Supreme Court on Wednesday is set to hold oral arguments concerning the novel question of whether judges may issue search warrants for private residences when a drug-sniffing dog outside the home reacts as if it smells drugs inside.

In a second case involving drug-sniffing dogs, the justices also will entertain arguments Wednesday concerning a Florida Supreme Court decision allowing defendants to challenge the authenticity of a drug sniff, by bringing up past evidence of false alerts and how well-trained the dog and handler were.

The home-sniff case, also arriving from the Florida Supreme Court, tests a decade-old U.S. Supreme Court precedent in which the justices ruled that police need a warrant to use thermal-imaging devices outside a house to detect marijuana-growing operations, saying it amounted to a search. In that case, the high court ruled in 2001 that “rapidly advancing technology” threatens the core of the Fourth Amendment “right of a man to retreat into his own home and there be free from unreasonable governmental intrusion.”

Wednesday’s argument in the home-search case concerns a suspected Florida drug dealer and tests the limits of government intrusion into the home — substituting drug-sniffing dogs for thermal-imaging devices. The justices and lower courts have routinely sanctioned search warrants based on trained drug-detecting dogs responding to packages like airport luggage or vehicles stopped during routine traffic stops.

The issue is being watched closely by at least 18 states that warned the Supreme Court that the case “jeopardizes a widely used method of detecting illegal drugs” (.pdf). The Obama administration has also weighed in, telling the justices that a drug-sniffing dog’s duties amount to no search at all (.pdf) — and hence no Fourth Amendment scrutiny is warranted.

The case before the justices stems from a Florida Supreme Court ruling last year in which Florida’s justices tossed evidence of 179 pot plants that Miami-Dade County authorities seized from the residence of Joelis Jardines in 2006. Authorities made the bust after a trained dog “alerted,” or indicated that it detected drugs, while outside the home.

Florida’s top court said the case, which comes as studies suggest drug-sniffing dogs reflect police bias or are wrong, sets a bad precedent and “invites overbearing and harassing conduct.”

Such a public spectacle unfolding in a residential neighborhood will invariably entail a degree of public opprobrium, humiliation and embarrassment for the resident, for such dramatic government activity in the eyes of many — neighbors, passers-by, and the public at large — will be viewed as an official accusation of crime. Further, if government agents can conduct a dog ‘sniff test’ at a private residence without any prior evidentiary showing of wrongdoing, there is nothing to prevent the agents from applying the procedure in an arbitrary or discriminatory manner, or based on whim and fancy, at the home of any citizen. Such an open-ended policy invites overbearing and harassing conduct.

The dog used to nab Jardines was Franky, a chocolate Labrador. Miami-Dade County officials said the canine, now retired, discovered more than 2.5 tons of marijuana, 80 pounds of cocaine and millions in cash during its career.

Jardines’ attorney, Howard Blumberg, urged the justices to uphold the Florida Supreme Court. He said the government’s deployment of a dog was akin to the “device” (.pdf) used in the thermal-imaging case. The dog, like thermal imaging equipment, was used “to explore details of the home that would previously have been unknowable without physical intrusion.”

Florida prosecutors told the high court that it must undo the Florida Supreme Court decision, saying dog searches are a “valuable tool” (.pdf).

Law enforcement is significantly hampered if required to develop probable cause without the assistance of dogs. The Florida Supreme Court’s decision requires that the officers have probable cause before employing a dog. It is the dog’s alert, however, that often provides the probable cause to obtain the search warrant. This Court should grant certiorari to directly hold that a dog sniff of a house is not a search and to restore this valuable tool in the detection of numerous illegal and dangerous activities to law enforcement.

In the other case to be argued Wednesday, the Florida Supreme Court last year invalidated a search that found meth-making chemicals in the vehicle Clayton Harris was driving, and suppressed the evidence that was seized based on an alert by Aldo, a Labrador retriever. The court said an alert by the truck’s door handle was insufficient evidence by itself to get a warrant to search Harris’ truck. Florida’s high court said other evidence was required, like the dog’s track record, and records regarding the handler’s and the dog’s background and training.

The Florida high court said that the courts always side with the dog “with an almost superstitious faith” and that “the dog is the clear and consistent winner.”

The Supreme Court justices usually rule weeks or months after arguments. There is no opinion-detecting dog that can help predict when a ruling is ready or how the court will rule.


Zero-Day World

Zero-day (zero-hour or day zero) vulnerabilities are previously unknown vulnerabilities that have not been revealed publicly but are exploited by attackers. Discovering and exploiting zero-day vulnerabilities helps cyber criminals to increase the success rate of attacks. Attacks using zero-day exploits are tough to identify and analyze because in many cases information is not available until attacks have already occurred. There is practically no protection against zero-day attacks as details of the vulnerability is usually a mystery when these attacks are first observed.

In a typical scenario, when a new vulnerability is found, the company who created the hardware or software is notified, and works to produce a fix in a sensible time. A security vulnerability is a programming error that escapes the testing phase. Attackers can sometimes identify the bug, exploit it, and wrap up the exploit with a malicious payload to carry out zero-day attacks against targets of their choice. Once the security community discovers and analyzes the vulnerability, details of the vulnerability are published in a public advisory, and the affected hardware or software vendor may release a patch to fix the issue at the same time as the disclosure. However, it can take some time for a software vendor to patch the security flaw as it has to go through the cycle of testing and quality assurance before it is released. In the meantime, security vendors update their antivirus and IPS signatures to detect the potential exploits or even the specific attacks seen in the wild.

The lifecycle of a zero-day vulnerability can be divided into the following phases:

  1. Attackers discover a vulnerability either through fuzzing or by accident.
  2. The attackers generate a working exploit that drops and executes a malicious binary on the system.
  3. The attackers use the exploit in attacks.
  4. Security vendors or researchers identify in-the-wild exploits through various monitoring applications or through customer submitted samples. If a security vendor becomes aware of the exploit first, the software vendor is notified before the information is made public.
  5. The vulnerability is revealed to the public, either by the software vendor or the security vendor.
  6. The security vendors release new signatures for antivirus and IPS products.
  7. The software vendors release a patch with the appropriate fixes.

Figure 1. Zero-day vulnerability lifecycle

Attackers take advantage of the vulnerability in the time between the publication of the vulnerability and the installation of the patch on affected systems. The exploitation of the vulnerability increases for a few days after the information goes public. Slowly, the exploitation decreases in the wild due to the deployment of antivirus and IPS signatures, and it becomes lower still after the vendor patches are deployed.

For the past ten months we have observed a number of zero-day vulnerabilities exploited in the wild for commonly installed software. The exploits used in these attacks allowed for remote code execution and demonstrated a high level of technical capability in the attackers.

A number of zero-day vulnerabilities were seen in use up to September 2012. In April 2012, we recognized several different types of malware that were used in combination with the Adobe Flash Player Object Type Confusion Vulnerability (CVE-2012-0779). Soon after, we noticed two other zero-day exploits related to the Microsoft Internet Explorer Same ID Property Vulnerability (CVE-2012-1875) and the Microsoft XML Core Services Vulnerability (CVE-2012-1889).

Figure 2. Notable zero-day exploits in April-September 2012

In September 2012, a zero-day exploit using the Microsoft Internet Explorer Image Arrays Use-After-Free Remote Code Execution Vulnerability (CVE-2012-4969) was discovered on a server associated with the Nitro hacking group. It was also noted that the same server was recently used to serve the Oracle Java Runtime Environment Remote Code Execution Vulnerability (CVE-2012-4681). We have also observed the usage of Flash (SWF) files using various exploits to drop malware including the following:

Zero-day exploits are highly sought after by cybercriminals and they expend considerable efforts to find them. The appearance of zero-day exploits can sometimes catch software vendors off guard as they do not necessarily expect their software to be probed and scrutinized intensely for vulnerabilities. However, security researchers are always keeping a lookout to try and keep exploit activity to a minimum. Leyla Bilge and Tudor Dumitra of Symantec Research Labs, recently wrote a paper entitled “An Empirical Study of Zero-day Attack in The Real World”. In it, they identified 18 vulnerabilities exploited in the real world before full disclosure. They detailed examples of vulnerabilities being exploited in the wild for an average of 312 days before petering out. They have created a useful study that measures the duration and prevalence of these attacks in the real world before the disclosure of the corresponding vulnerabilities, and it makes for an interesting read.

Good High-Level Enterprise Architecture Video

I ran across a really good high-level Enterprise Architecture video last week and thought I would share. It's brought to us by ArchimateMusings blog. This looks to be a video that his company created to articulate EA's overall function and value proposition. Here is the description of the video:

This animation shows the role of Enterprise Architecture starting from the perspective of a business user. That user has understandable wishes and requests, and the IT decisions made for him all make sense. But the result of all business users doing this independently is a 'hair ball architecture'. The role of Enterprise Architecture to prevent this from happening is illustrated.

The video was created by T36 (http:// in Maastricht, The Netherlands for APG Asset Management ( T36 created the story board from interviews with APG AM's Lead Architect, Gerben Wierda. The video is owned by APG and it may move to an APG-owned channel later.

I wanted to share this with everyone because I think it's important for EA's to have a rich set of visuals, examples and media to facilitate the continous education process with our customers. While the video didn't speak of strategy and business enablement directly, I do think this is a good primer or overview of some key value propositions for EA.


Android/FakeToken 2.0 Goes Back to Basics

In March a new type of financial attack on Android devices was found targeting customers of several banks in Europe. Dubbed FakeToken, one of the principal differences of this new threat–compared with previous Trojan bankers for Android such as Zitmo/Spitmo–was the fact that both authentication factors (Internet password and mTAN) were stolen directly from the mobile device. In this case the cybercriminals had no need to first infect PCs to steal bank account passwords.

Recently a new version of this malware was found being distributed through phishing emails pretending to be sent by the targeted bank. According to an alert published by the affected bank, the malware attack simulates the real Internet banking site by asking for confidential information like personal email and phone number. This information is used to initiate the mobile attack.

Another technique used to distribute this malware includes injecting web pages from infected computers, simulating a fake security app that presumably avoids the interception of SMS messages by generating a unique digital certificate based on the phone number of the device. The fake web page provides a URL that is intended to be entered into the mobile browser, prompting the user to download/install the malware on the mobile device.

Finally, a third version injects a phishing web page that redirects users to a website pretending to be a security vendor that offers the “eBanking SMS Guard” as protection against “SMS message interception and mobile Phone SIM card cloning.”

Once the application is downloaded and the user tries to install it, the malware requests almost the same permissions as the first version, but the application doesn’t access the contact list. This change was likely made to avoid raising suspicions.

Another difference between the two versions is the name that the malware authors used for the malicious application. Instead of naming it “TokenGenerator,” the new version gives the look and feel of security software for protecting SMS messages received by the customer.

When the user executes the application, the malware shows a WebView component displaying an HTML/JavaScript web page that pretends to be an mToken app and not the “SMS Guard” used in the name. Instead of asking the user to enter the first factor of authentication this version shows just the fake mToken, which suspiciously never changes.

At the same time, the malware sends to a specific number an SMS message with the device identifier (IMEI) of the affected device. The same identifier, along with others like the IMSI and phone number, are also sent to a remote server to register the infected device in the control server of the attacker. From this point, all SMS content received by the infected device is sent to a remote server and to the phone number specified in the configuration file inside the original APK file.

Taking into account this new version of FakeToken and the recent version of Zitmo, it’s clear that Android Trojan bankers are becoming more prevalent. This is partially due to the increased adoption of mobile banking as well as the constant evolution of cybercriminal methods. By targeting different financial entities and changing their methods, cybercriminal attacks appear more credible (by removing excess functions) to victims and more effective in getting mTANs by intercepting all the SMS messages received by the affected user.

McAfee Mobile Security detects this threat as Android/FakeToken.B and alerts mobile users if it is present on their devices, while protecting them from any data loss. For more information about McAfee Mobile Security, visit