Home Tags Federal Reserve

Tag: Federal Reserve

Banks Must Focus More on Cyber-Risk

Recent guidelines from the Federal Reserve are aimed at stemming the tide of successful exploits.

Kaspersky Security Bulletin 2016. Review of the year. Overall statistics for...

 Download Review of the year  Download Overall statistics  Download the consolidated Kaspersky Security Bulletin 2016 Introduction If they were asked to sum up 2016 in a single word, many people around the world – particularly those in Europe and the US – might choose the word ‘unpredictable’. On the face of it, the same could apply to cyberthreats in 2016: the massive botnets of connected devices that paralysed much of the Internet in October; the relentless hacking of high profile websites and data dumps; the SWIFT-enabled bank heists that stole billions of dollars, and more. However, many of these incidents had been in fact been predicted, sometimes years ago, by the IT security industry, and the best word for them is probably ‘inevitable’. For cyberthreats, 2016 was the year when “sooner or later” became “now” #KLReport Tweet Most of all, in 2016, ransomware continued its relentless march across the world – with more new malware families, more modifications, more attacks and more victims. However, there are rays of hope, including the new, collaborative No More Ransom initiative. Kaspersky Lab has designated the revolution in ransomware its Story of the Year for 2016 and you can read more about its evolution and impact here. Elsewhere on the cybersecurity landscape, targeted cyberespionage attacks, financial theft, ‘hacktivism’ and vulnerable networks of connected devices all played their part in what has been a tense and turbulent year. This Executive Summary provides an overview of the top threats and statistics for 2016. Full details are included in the accompanying Review & Statistics. It also considers what these threats mean to organisations trying spot a breach or cyberattack. How ready are businesses to proactively prevent and mitigate a cyberthreat? What can be done to help them? Six things we learned this year that we didn’t know before 1. That the underground economy is more sophisticated and bigger than ever: xDedic – the shady marketplace In May, we uncovered a large, active cybercriminal trading platform, called xDedic. xDedic listed and facilitated the buying and selling of hacked server credentials. Around 70,000 compromised servers were on offer – although later evidence suggests that there could have been as many as 176,000 – located in organisations around the world. In most cases, the legitimate owners had no idea that one of their servers, humming away in a back room or data center, had been hijacked and was being passed from criminal to criminal. xDedic is not the first underground marketplace, but it is evidence of the growing complexity and sophistication of the black market economic ecosystem. “xDedic is a hacker’s dream, simplifying access to victims, making it cheaper and faster, and opening up new possibilities for both cybercriminals and advanced threat actors.” GReAT 2. That the biggest financial heist did not involve a stock exchange: the SWIFT-enabled transfers One of the most serious attacks in 2016 was that using the inter-bank network, SWIFT (Society for Worldwide Interbank Financial Telecommunication). In February 2016, hackers used the SWIFT credentials of Bangladesh Central Bank employees to send fraudulent transaction requests to the Federal Reserve Bank of New York, asking it to transfer millions of dollars to various bank accounts in Asia. The hackers were able to get $81 million transferred to the Rizal Commercial Banking Corporation in the Philippines and an additional $20 million to Pan Asia Banking. The campaign was cut short when the bank spotted a typo in one of the transfer requests. You can read the story here. In the following months, further bank attacks using SWIFT credentials came to light. Following the theft of $100 million many banks were forced to improve their authentication and SWIFT software update procedures #KLReport Tweet 3. That critical infrastructure is worryingly vulnerable: the BlackEnergy attacks BlackEnergy deserves a place in this list even though, strictly speaking, it took place at the end of 2015. However, it was only in early 2016 that the full effect of the BlackEnergy cyber-attack on the Ukrainian energy sector became clear. The attack was unique in terms of the damage it caused. This included disabling the power distribution system in Western Ukraine, wiping software on targeted systems and unleashing a Distributed Denial of Service (DDoS) attack on the technical support services of affected companies. Kaspersky Lab has supported the investigation into BlackEnergy since 2010, with among other things, an analysis of the tool used to penetrate the target systems. You can find our 2016 report here. The BlackEnergy cyberattack on the Ukrainian energy sector revealed the vulnerability of critical infrastructures worldwide #KLReport Tweet To help organizations working with industrial control systems (ICS) to identify possible points of weakness, Kaspersky Lab experts have conducted an investigation into ICS threats. Their findings are published in the Industrial Control Systems Threat Landscape report. 4. That a targeted attack can have no pattern: the ProjectSauron APT In 2016 we discovered the ProjectSauron APT: a likely nation-state backed cyberespionage group that has been stealing confidential data from organisations in Russia, Iran and Rwanda – and probably other countries – since June 2011. Our analysis uncovered some remarkable features: for example, the group adopted innovative techniques from other major APTs, improving on their tactics in order to remain undiscovered. Most importantly of all: tools are customized for each given target, reducing their value as Indicators of Compromise (IoCs) for any other victim. An overview of the methods available to deal with such a complex threat can be found here. ProjectSauron’s pattern-less spying platform has far-reaching implications for some basic principles of threat detection #KLReport Tweet 5. That the online release of vast volumes of data can be an influential tactic: ShadowBrokers and other data dumps 2016 saw a number of remarkable online data dumps. The most famous is probably that by a group calling itself the ShadowBrokers. On August 13, they appeared online claiming to possess files belonging to the ultimate APT predator, the Equation Group. Our research suggests there are similarities between the data dumped by ShadowBrokers and that used by the Equation Group. The initial data dump included a number of unreported zero-days, and there have been further dumps in recent months. The long-term impact of all this activity is unknown, but is has already revealed the huge and rather worrying influence such data dumps can potentially have on public opinion and debate. In 2016 we also witnessed data breaches at beautifulpeople.com, Tumblr, the nulled.io hacker forum, Kiddicare, VK.com, Sage, the official forum of DotA 2, Yahoo, Brazzers, Weebly and Tesco Bank – for motives ranging from financial gain to personal reputation blackmail. A LinkedIn hack made public in 2016 revealed over a million uses of the password ‘123456’. #KLReport Tweet 6. That a camera could be part of a global cyber-army: the insecure Internet of Things Connected devices and systems, from homes and vehicles to hospitals and smart cities, exist to make our lives safer and easier. However, many were designed and manufactured without much thought for security – and sold to people who underestimated the need to protect them with more than default factory security settings. The risk of connecting everything without proper safeguards – after 2016, need we say more? #KLReport Tweet As the world now knows, all these millions of insecure connected devices represent a powerful temptation to cybercriminals. In October, attackers used a botnet of over half a million internet-connected home devices to launch a DDoS attack against Dyn – a company that provides DNS services to Twitter, Amazon, PayPal, Netflix and others. The world was shocked, but warnings about unstable IoT security have been around for a long time. For example, in February, we showed how easy it was to find a hospital, gain access to its internal network and take control of an MRI device – locating personal data about patients and their treatment procedures and obtaining access to the MRI device file system. In April, we published the results of our research into, among other things, the vulnerability of city traffic sensors and smart ticket terminals. Manufacturers need to work with the security industry to implement ‘security-by-design’ #KLReport Tweet Other top threats Inventive APTs At least 33 countries were targeted by APTs reported on by Kaspersky Lab #KLReport Tweet In February, we reported on Operation Blockbuster, a joint investigation by several major IT security companies into the activities of the Lazarus gang, a highly malicious entity responsible for data destruction. The Lazarus group is believed to have been behind the attack on Sony Pictures Entertainment in 2014 #KLReport Tweet Adwind, is a cross-platform, multi-functional RAT (Remote Access Tool) distributed openly as a paid service, where the customer pays a fee in return for use of the malicious software. It holds the dubious distinction of being one of the biggest malware platforms currently in existence, with around 1,800 customers in the system by the end of 2015. Adwind’s malware-for-rent had a customer base of 1,800 #KLReport Tweet APTs everywhere continued to make the most of the fact that not everyone promptly installs new software updates – in May we reported that at least six different groups across the Asia-Pacific and Far East regions, including the newly discovered Danti and SVCMONDR groups, were exploiting the CVE-2015-2545 vulnerability. This flaw enables an attacker to execute arbitrary code using a specially-crafted EPS image file. A patch for the vulnerability was issued back in 2015. Over six APT groups used the same vulnerability – patched back in 2015 #KLReport Tweet New zero-days Zero-days remained a top prize for many targeted attackers. In June, we reported on a cyber-espionage campaign launched by a group named ScarCruft and code-named Operation Daybreak, which was using a previously unknown Adobe Flash Player exploit (CVE-2016-1010). Then in September we discovered a Windows zero-day, CVE-2016-3393, being used by a threat actor known as FruityArmor to mount targeted attacks. In all, new Kaspersky Lab technologies designed to identify and block such vulnerabilities helped us to uncover four zero-days in 2016. The other two are an Adobe Flash vulnerability CVE-2016-4171 and a Windows EoP (Escalation of Privilege) exploit CVE-2016-0165 . The hunt for financial gain Tricking people into either disclosing personal information or installing malware that then seizes the details for their online bank account remained a popular and successful option for cyber-thieves in 2016. Kaspersky Lab solutions blocked attempts to launch such malware on 2,871,965 devices. The share of attacks targeting Android devices increased more than four-fold. A third of banking malware attacks now target Android devices #KLReport Tweet Some APT groups were also more interested in financial gain than cyberespionage. For example, the group behind Metel infiltrated the corporate network of banks in order to automate the roll-back of ATM transactions: gang members could then use debit cards to repeatedly steal money from ATMs without ever affecting the balance on the card. At the end of 2016 this group remains active. Metel launched targeted attacks on banks – then sent teams to ATMs at night to withdraw the cash #KLReport Tweet In June, Kaspersky Lab supported the Russian police in their investigation into the Lurk gang. The collaboration resulted in the arrest of 50 suspects allegedly involved in creating networks of infected computers and the theft of more than 45 million dollars from local banks, other financial institutions and commercial organizations. During the investigation, researchers spotted that users attacked by Lurk had the remote administration software Ammyy Admin installed on their computers. This led to the discovery that that the official Ammyy Admin website had most probably been compromised, with the Trojan was downloaded to users’ computers along with the legitimate Ammyy Admin software. The takedown of the Lurk gang was the largest ever arrest of hackers in Russia #KLReport Tweet The ultimate vulnerability: people 2016 also revealed that targeted attack campaigns don’t always need to be technically advanced in order to be successful. Human beings – from hapless employees to malicious insiders – often remained the easiest access route for attackers and their tools. In July, we reported on a group called Dropping Elephant (also known as ‘Chinastrats’ and ‘Patchwork’). Using high quality social engineering combined with old exploit code and some PowerShell-based malware, the group was able to successfully steal sensitive data from high-profile diplomatic and economic organisations linked to China’s foreign relations. Dropping Elephant and Operation Ghoul confirmed the fearsome power of high quality social engineering #KLReport Tweet Further, Operation Ghoul sent spear-phishing e-mails that appeared to come from a bank in the UAE to top and middle level managers of numerous companies. The messages claimed to offer payment advice from the bank and attached a look-like SWIFT document containing malware. Cybercriminals are using insiders to gain access to telecommunications networks and subscriber data, recruiting disaffected employees through underground channels or blackmailing staff using compromising information gathered from open sources.” Threat Intelligence Report for the Telecommunications Industry Mobile advertising The main mobile threats in 2016 were advertising Trojans able to obtain ‘root’ or superuser rights on an infected Android device – a level of access that allowed them to do pretty much whatever they wanted. This included hiding in the system folder, thereby making themselves almost impossible to delete, and silently installing and launching different apps that aggressively display advertising. They can even buy new apps from Google Play. 22 of the 30 most popular Trojans in 2016 are advertising Trojans – twice as many as in 2015 #KLReport Tweet Many such Trojans were distributed through the Google Play Store: some of them were installed more than 100,000 times, and one – an infected Pokemon GO Guide app was installed more than 500,000 times. Malware distributed through Google Play was downloaded hundreds of thousands of times #KLReport Tweet One Android Trojan installed and even updated as a ‘clean’ (malware-free) app before hitting targets with an infected version. Others, including Svpeng, used the Google AdSense advertising network for distribution Further, some Trojans found new ways to bypass Android security features – in particular the screen overlays and the need to request permission before opening a new app – forcing the user to sign over the access rights the Trojan was looking for. Mobile ransomware also evolved to make use of overlays, blocking rather than encrypting data since this is generally backed-up. To read more on these stories, please download the full annual Review for 2016 here. For an in-depth look at the Statistics for 2016, please register to download the Statistics report here. The impact on business The 2016 threat landscape indicates a growing need for security intelligence The Kaspersky Security Bulletin 2016 highlights the rise of complex and damaging cybersecurity threats, many of which have a far-reaching impact on businesses. This impact is also reflected in our Corporate IT Security Risks Reports (1, 2) based on a 2016 survey of more than 4000 businesses worldwide. Among other things, the survey asked companies about the most crucial metric of incident detection and response: time. Incident detection time is critical Previously unreleased findings from the research show that the typical time required to detect an IT Security event is several days – 28.7% of companies said it took them that long to detect a security breach on average. Time required to detect an IT security event Only 8.2% of businesses managed to detect security breaches almost instantly, and for 19.1% of businesses it took several weeks to detect a serious security event. When we asked how they eventually detected a long-standing breach, the replies were revealing. Going beyond prevention Average time frame required to detect a security event, across all security eventswithin the last 12 months In this chart we combine the average time to discover a security event with the responses we received on how businesses detected a breach. Apparently, businesses that struggle to detect a breach quickly, eventually spot them through one or more of the following: an external or internal security audit, or, sadly, notification from a third party. It turns out that for these businesses a security audit of any kind is the best measure of ‘last resort’ to finally bring it to light. But should it be only a last resort? This is where our report detects an obvious discrepancy between theory and practice. Although 65% of businesses admit that a security audit is an effective security measure, less than half of the companies surveyed (48%) have conducted such audit in the last 12 months. Further, 52% of companies operate under the assumption that their IT security will inevitably be compromised at some point, although 48% are not ready to accept this. In short: many businesses find a structured detection and response strategy difficult to embrace. The cost of delay It is safe to assume that the longer it takes to detect a security breach, the higher the mitigation costs and the greater the potential damage. The results reveal the shocking truth that failure to discover an attack within a few days, results in a doubling, or more of the costs. Cost of recovery vs. time needed to discover a security breach for enterprises For enterprises, an attack undiscovered for a week or more costs 2.77 times that of a breach detected almost instantly. SMBs end up paying 3.8 times more to recover from an incident detected too late. It is clear that better detection significantly reduces business costs. But the implementation of incident detection and response strategies is quite different from ensuring proper prevention. The latter provides a choice of well-established corporate solutions. The former requires security intelligence, a deep knowledge of the threat landscape, and security talent capable of applying that expertise to the unique specifics of a company. According to our special Corporate IT Security Risks report, businesses that struggle to attract security experts end up paying twice as much for their recovery after an incident. Kaspersky Lab’s solution: turning intelligence into protection In 2016 Kaspersky Lab significantly expanded its portfolio with products like Kaspersky Anti-Targeted Attack Platform and security services like Penetration Testing and Threat Data Feeds, all to help meet customer needs for better detection and response. Our plan is to offer security intelligence via any means necessary: with a technology to detect targeted threats, a service to analyze and respond to a security event, and intelligence that helps investigate an issue properly. [embedded content] We appreciate that, for many businesses, going beyond prevention is a challenge. But even a single targeted attack that is detected early and mitigated rapidly is worth the investment – and increases the chances that the next assault on the corporate infrastructure is prevented outright.

Trump says he’s going to get Apple to “build a big...

Enlarge / President-elect Donald Trump walks through the lobby of the New York Times Building following a meeting with editors of the paper on November 22, 2016.Spencer Platt / Getty Images News reader comments 104 Share this story President-elect Donald Trump told The New York Times in a Tuesday interview that he would incentivize Apple to “build a big plant” in the United States. During that interview, Trump touched on numerous subjects, changing his tune on several campaign positions. He backed off threats he made during his campaign to prosecute his political rival, Hillary Clinton, over her use of a personal e-mail server while she was Secretary of State. However, Trump indicated to columnist Thomas Friedman that he is going to double-down on bringing factory jobs back to America, especially in the Rust Belt from Michigan to Pennsylvania. FRIEDMAN: Are you worried, though, that those companies will keep their factories here, but the jobs will be replaced by robots? TRUMP: They will, and we’ll make the robots, too. [laughter] TRUMP: It’s a big thing, we’ll make the robots, too. Right now we don’t make the robots. We don’t make anything.

But we’re going to.
I mean, look, robotics is becoming very big and we’re going to do that. We’re going to have more factories. We can’t lose 70,000 factories. Just can’t do it. We’re going to start making things. Trump's point that America doesn't "make anything" is objectively false.

According to the Federal Reserve Bank of St. Louis, manufacturing is at the highest level it's been in a decade, but this economic output being achieved with fewer workers. Trump continued, saying that he had received a call from Apple CEO Tim Cook. As the president-elect recounted: …and I said, ‘Tim, you know, one of the things that will be a real achievement for me is when I get Apple to build a big plant in the United States, or many big plants in the United States, where instead of going to China, and going to Vietnam, and going to the places that you go to, you’re making your product right here.’ He said, ‘I understand that.’ I said: ‘I think we’ll create the incentives for you, and I think you’re going to do it. We’re going for a very large tax cut for corporations, which you’ll be happy about.’ But we’re going for big tax cuts, we have to get rid of regulations, regulations are making it impossible. Whether you’re liberal or conservative, I mean, I could sit down and show you regulations that anybody would agree are ridiculous.
It’s gotten to be a free-for-all.

And companies can’t, they can’t even start up, they can’t expand, they’re choking. Recently, the Nikkei Asian Review reported that Apple's manufacturing contractors, Foxconn and Pegatron have been looking into manufacturing the iPhone in the US. Apple did not immediately respond to Ars’ request for comment.

Trump did not mention the fact that earlier this year, he called for a boycott of Apple products.

UK Home Secretary signs off on Lauri Love’s extradition to US

#OpLastResort hacker suspect on suicide watch It appears that appeals for clemency have come to naught after the UK Home Office confirmed that the extradition order for Lauri Love has been signed off by Home Secretary Amber Rudd. Love is facing charges that he was part of #OpLastResort, which stole large amounts of data from targets like the US Federal Reserve, the Department of Defense, NASA, and the FBI between 2012 and 2013.

The 31-year-old, who suffers from Asperger syndrome, faces 99 years in prison and millions of dollars in fines if he's convicted. "On Monday 14 November, the Secretary of State, having carefully considered all relevant matters, signed an order for Lauri Love's extradition to the United States," Home Office spokeswoman Rosie Libell told The Reg. "Mr Love has been charged with various computer hacking offences, which include targeting US military and federal government agencies." Love faces up to three trials in the US on hacking charges and, thanks to an extradition agreement arranged by then-Prime Minister Tony Blair, American prosecutors don't have to show evidence before a British court beforehand. Love now has 14 days to appeal Rudd's decision. In court, Love's lawyers have argued that Love, who has suffered mental illness for most of his life, would be at high risk of suicide if extradited.
In September, a British court ruled that this was not enough to stop his extradition, but on Monday Love reiterated that he was not going to travel to the US. Have I mentioned recently that I have absolutely zero intention of being taken to the USA against my will to be subjected to state violence? — Lauri Love (@LauriLoveX) November 12, 2016 (In the event of my death or disappearance a series of automated measures will trigger and numerous newsworthy revelations can be expected.) — Lauri Love (@LauriLoveX) November 14, 2016 Love's case has sparked huge amounts of interest and support. Last month over 100 members of parliament signed an open letter to US President Barack Obama, asking the leader of the Land of the FreeTM to reconsider the extradition. So far there has been no response, and Love is unlikely to get any mercy from President-elect Trump. ® Sponsored: Customer Identity and Access Management

British parliament members urge Obama to halt hacking suspect’s US extradition

EnlargeThe Courage Foundation reader comments 24 Share this story This week, culture minister Matt Hancock and more than 100 fellow MPs (Members of Parliament) have signed a letter calling on president Barack Obama to block Lauri Love's extradition to the US to face trial over the alleged hacking of the US missile defence agency, the FBI, and America's central bank. Love—an Asperger's syndrome sufferer from Stradishall, Suffolk—was told in September at a Westminster Magistrates' Court hearing that he was fit to be extradited to the US to face trial in that country.

The 31-year-old faces up to 99 years in prison in the US if convicted.

According to his lawyers, Love has said he fears for his life. Hacking allegations against Love stem from the Anonymous-related #OpLastResort hack in 2013.

The initiative targeted the US Army, the US Federal Reserve, the FBI, NASA, and the Missile Defense Agency in retaliation over the tragic suicide of Aaron Swartz as the hacktivist infamously awaited trial. Love is accused of participating through SQL injection attacks, Love's legal team have argued that their client's case is similar to that of British citizen Gary McKinnon, whose extradition to the US was blocked in 2012 by then home secretary Theresa May.

At the time, May introduced a forum bar to stop extradition in cases where the defendants' human rights were said to be at risk. Hancock, who is the Love family's local MP, signed the letter alongside a cross-party coalition of 104 other politicos.

The missive to Obama asks: The UK has prosecuted at least twelve computer hackers who have hacked US-based computer systems.
Indeed, Mr Love would be the first UK-based computer hacker to be extradited and denied the opportunity to face a full prosecution in the UK.

The UK criminal justice system is equipped to bring justice through sentencing and rehabilitating people who are adjudged to have committed these crimes. Many of these twelve cases did not involve individuals who have significant mental health issues, nor Asperger Syndrome and were not at a high-risk of suicide, yet they were not extradited. We would like to ask, why then is the United States insistent on Mr Love’s extradition despite the UK having a proven track record of appropriately sentencing and rehabilitating individuals who have committed computer hacking offences against the US? The MPs seek an "act of compassion" from the US president by urging him in his final days of office to personally intervene in the case, kill the extradition order, and allow it to be heard in the UK. "You would be acting to prevent this vulnerable and mentally unwell man from being placed in a situation where he will most probably take his own life," the letter states. Prime minister May—when recently quizzed in parliament by McKinnon campaigner and MP David Burrowes—said of the forum bar: "We subsequently changed the legal position on that, so it is now a matter for the courts.

There are certain parameters that the courts look at in terms of the extradition decision and that is then passed to the home secretary.
It is for the courts to determine the human rights aspects of any case that comes forward." She added: "It was right, I think, to introduce the forum bar to make sure there was that challenge for cases here in the United Kingdom, as to whether they should be held here in the United Kingdom, but the legal process is very clear and the home secretary is part of that legal process." This post originated on Ars Technica UK

How security flaws work: SQL injection

reader comments 69 Share this story A demonstration of SQL injection in action. Thirty-one-year-old Laurie Love is currently staring down the possibility of 99 years in prison.

After being extradited to the US recently, he stands accused of attacking systems belonging to the US government.

The attack was allegedly part of the #OpLastResort hack in 2013, which targeted the US Army, the US Federal Reserve, the FBI, NASA, and the Missile Defense Agency in retaliation over the tragic suicide of Aaron Swartz as the hacktivist infamously awaited trial. Love is accused of participating in the #OpLastResort initiative through SQL injection attacks, an increasingly common tactic.
SQL injections have recently been detected against state electoral boards, and these attacks are regularly implicated in thefts of financial info.

Today, they've become a significant and recurring problem. SQL injection attacks exist at the opposite end of the complexity spectrum from buffer overflows, the subject of our last in-depth security analysis. Rather than manipulating the low-level details of how processors call functions, SQL injection attacks are generally used against high-level languages like PHP and Java, along with the database libraries that applications in these languages use. Where buffer overflows require all sorts of knowledge about processors and assemblers, SQL injection requires nothing more than fiddling with a URL. As with buffer overflows, SQL injection flaws have a long history and continue to be widely used in real-world attacks.

But unlike buffer overflows, there's really no excuse for the continued prevalence of SQL injection attacks: the tools to robustly protect against them are widely known.

The problem is, many developers just don't bother to use them. One of Microsoft's less valuable innovations The earliest description of these attacks probably came in 1998, when security researcher Jeff Forristal, writing under the name "rain.forest.puppy," wrote about various features of Microsoft's IIS 3 and 4 Web servers in the hacker publication Phrack. IIS came with several extensions that provided ways to generate webpages based on data from databases.

Then and now, most databases use variants of a language called SQL (Structured Query Language) to manipulate their data.

Databases using SQL organize data into tables built up of rows and columns.

Each table represents a particular kind of thing.

Each column of the table represents a particular fact about that thing, and each row of the table is an instance of that thing.
So, for example, a table named "people" might have columns for "age" and "name," with each row in the table representing a specific person.
SQL is used for both defining these tables and columns and for manipulating the rows within them. IIS had several different ways of writing SQL commands—"queries"—to find and retrieve information in an SQL database.

The best-known and longest-lived of these is ASP (Active Server Pages), a system for writing webpages with embedded programming (usually using JavaScript or VBScript) that typically include substantial amounts of database access.

At the time, IIS also included something called IDC (Internet Database Connector) that was a less flexible way of sending an SQL query to a database and tabulating the results. Sometimes, the SQL query that these IDC and ASP files used for grabbing information from the database was hardcoded; that is, the same query was used every single time the webpage was loaded.

But because the query was often written to take one or more parameters, the data shown on that page could change as those parameters changed. For example, an online store might have a page named order.asp to display the contents and status of an order.

Each order is identified by an order ID, with the order ID passed as a parameter to the page as part of the URL: order.asp?orderID=1234, say, to view the order with ID 1234.

The ASP page would take the parameter from the URL and combine it into an SQL query, which was then sent to the database for lookup. What Forristal noticed was that the way these parameters were combined to build the query meant that an attacker could force the database to execute other queries of the attacker's choosing.

This act of subverting the application to run queries chosen by an attacker is called SQL injection. A popular tool to this day Since their initial discovery, SQL injection flaws have routinely been discovered in the wild and used to compromise vast quantities of data. While Forristal looked at Microsoft's software first, SQL injection was an industry-wide problem; sites using Java, PHP, ColdFusion, Ruby, and Python have all had SQL injection flaws.
Virtually every technology that can be used to build dynamic, database-driven websites is susceptible to SQL injection. And attacks using SQL injection are abundant.

Earlier this year, a Florida man was charged with felony hacking after using SQL injection to read sensitive data from an election site.
SQL injection vulnerabilities in the Joomla CMS and popular WordPress plugins have put hundreds of thousands of blogs at risk of attack. Security firm HBGary was devastatingly attacked in 2011 after members of the Anonymous collective discovered SQL injection flaws in a custom-developed content management system.

The group responsible for that attack would later go on to call itself Lulzsec. What makes these attacks particularly valuable to attackers—and devastating to victims—is their dual power to both read sensitive data from a database and to write new or updated data to the database. With this power to inject SQL, attackers could potentially read usernames, passwords, credit card numbers, Social Security numbers, or whatever else happened to be stored in the database. But they could also add their own data.
In a well-designed system, passwords, for example, won't be stored as plain text but instead will be irreversibly transformed into a hashed value. Merely reading the database therefore won't be sufficient to let an attacker log in and snoop around; while the database will contain the necessary username, it won't reveal the password.

The ability to write to the database, however, means that an attacker can simply create additional user accounts—ones for which they do know the passwords—and log in with those. Similarly, if the database is used to store any kind of auditing information, such as tracking logins and other user activity, the ability to write to it means that hackers can clean up after themselves, deleting any record of their attack. To understand how these attacks happen, we need to understand how Web applications use databases.

Basic SQL queries have a fairly simple structure.

For example, a call to search for a particular order might look like SELECT * FROM orders WHERE orderid=1234 The * means "retrieve all the columns," orders is the name of the table of data, and WHERE orderid=1234 restricts the data to only include the rows where the value of the orderid column is 1234.

The order ID number being searched for would typically be taken from parameter embedded in the URL.
So the 1234 from order.asp?orderID=1234 is combined with SELECT * FROM orders WHERE orderid= to produce the SQL query SELECT * FROM orders WHERE orderid=1234, and that query will be sent to the database. The fragment of code that does this might look something like: // first, pull the order ID from the URL query var orderid = Request.QueryString("orderid"); // then use the order ID to construct a query var query = "SELECT * FROM orders WHERE orderid = " + orderid; // and send the whole string to the database to execute But two things together make this problematic.

First, SQL databases allow multiple queries to be strung together one after the other.

To perform two searches, one could write: SELECT * FROM orders WHERE orderid=1234 SELECT * FROM orders WHERE orderid=5678 Different options and databases might change this a little—for example, by requiring a semicolon between the two queries—but the basic principle is the same. Second, URLs are not constrained to being numbers; they're just text strings.
So while the order ID should be a single number like 1234, it doesn't have to be.

An attacker could request, say, order.asp?orderID=1234 SELECT * FROM orders WHERE orderid=5678, putting an SQL fragment into the URL itself.
If the application does not take care to protect itself against SQL injection attacks, the query it constructs will include the attacker's code, and the database will run both queries together. The way the query string is built will often change the exact code the attacker has to write.
Integer parameters, as with the order ID, are typically the easiest to handle because they're typically not modified or altered in any way.
String parameters can introduce some additional complexity, because strings have to be wrapped in quote marks within the SQL query.

The code to do this might look something like: // first, pull the name from the URL query var customername = Request.QueryString("name"); // then use the name to construct a query var query = "SELECT * FROM customers WHERE customername = '" + customername + "'"; // and send the whole string to the database to execute In this situation, simply appending an SQL command to the URL won't work because of those single quote marks. Making a request to, say, customer.asp?name=SELECT * FROM orders would produce the following query: SELECT * FROM customers WHERE customername = 'SELECT * FROM orders' This won't reveal any data; it will just look for a customer with the rather implausible name of "SELECT * FROM orders".

But the attacker can solve this, prepending the attack query with a single quote mark, producing: SELECT * FROM customers WHERE customername = '' SELECT * FROM orders' That stray quote mark at the end of the query might cause the database to reject the query, so the usual solution is to comment it out, so that it is ignored, using -⁠-.

Accordingly, the URL would look like customer.asp?name=' SELECT * FROM orders -⁠⁠-, and the query would be: SELECT * FROM customers WHERE customername = '' SELECT * FROM orders --' Query in, data out Attackers can do a lot with the ability to simply run queries.

Destructive actions in particular, such as deleting data, don't really need much in the way of output.
Some databases let you run command-line programs from within queries, which again can be all hackers need to do their dirty work.

But generally, an attacker needs to read information as well as write it, both to retrieve valuable data stored in the database and to learn about the names of the database's tables and columns. Running a query of the attacker's choosing is one thing; seeing the results is another. When a query is run, the usual response from the database is a table of data.

Applications vary in the way they react to this.
Some applications will simply present the user with every bit of data returned in the table, making it very easy for an attacker to extract information from the system. Others will expect the result table to have particular columns and ignore any data not included in those columns.

This isn't an insurmountable problem for attackers, as they may be able to ensure that the data they want appears in one of those columns by altering the form of the query they write. Similarly, an application may iterate through every row of data returned by the query and show them all to the attacker.

Again, this represents the easiest situation for data exfiltration.

Alternatively, if the application expects only a single row to be returned, it may only show the first row that the injected query returns.

The application might even issue an error message if it's expecting only a single row to be returned by the database.

These situations make extracting data more complex, though again, it can be addressed by structuring the injected query just so. The other main response to a query is an error message, indicating that something went wrong.

Typically when injecting SQL, this will be an error from the database to complain that the query was malformed in some way.

Again, applications vary in how helpful they make this error message.

The best case for the attacker is when the developer is lazy and simply spits back the full error message to all and sundry.

This is often done during development, as it makes the develop/test/debug cycle quicker, but it shouldn't ever happen in real production systems. To take advantage of this, the attacker can ensure that every injected query results in an error that reveals some information.

For example, trying to convert a string into an integer will usually result in an error, and that error message will include the string that couldn't be converted.
So, to extract the database name, an attacker could run a query looking like this (in SQL Server): SELECT * FROM orders WHERE orderid=CONVERT(int, db_name()) db_name() here is an SQL Server function that returns the name of the current database.

CONVERT tries to convert that name into an integer.

This will fail, and it will produce an error message looking like: Conversion failed when converting the nvarchar value 'databasenamehere' to data type int. Thereby revealing the database's name to an attacker. Going in blind Better applications will show some generic error page, robbing the attacker of this useful information.

Even when the application is strict in what it displays—suppressing error messages, showing only columns that it's supposed to, and not showing multiple rows when only one is expected—attackers who can inject SQL might be able to piece together the information they need. One common technique for doing this is called "blind" SQL injection. In blind injection attacks, the attacker cannot write a query that simply displays the desired information.
Instead, the attacker constructs queries that extract one bit of data (literally, in the common case) at a time.

Consider again the query to show an order: SELECT * FROM orders WHERE orderid=1234 Presuming that order exists, this request will return exactly one row. We can add additional terms to the query and it will still return that one row: SELECT * FROM orders WHERE orderid=1234 AND 1=1 Conversely, we could make it return exactly zero rows to get some kind of an "order not found" page: SELECT * FROM orders WHERE orderid=1234 AND 1=0 Armed with this knowledge—we have a website that is returning one particular page for "true" and one particular page for "false"—we can start probing the database for information.

For example, perhaps we know that the victim is running Microsoft SQL Server, and we have an exploit of some kind that works against, say, SQL Server 2012. We therefore want to know if the system is running SQL Server 2012.

To do that in SQL Server, we'd run a query like: SELECT SERVERPROPERTY('ProductMajorVersion') = 11 This will return true if running on SQL Server 2012 but false otherwise.

This can be injected to produce a query such as: SELECT * FROM orders WHERE orderid=1234 AND SERVERPROPERTY('ProductMajorVersion') = 11 If running on SQL Server 2012, this will produce the normal order page. Otherwise, it will produce the error "no order found" page, thereby giving the attacker a single piece of information. More advanced techniques built on the same basic principle can allow several bits of information to be extracted at once. It will not be a great surprise to learn that extracting information bit by bit is slow and tedious.

Accordingly, a variety of tools exist to automate the process.

They can systematically send a barrage of requests to a site vulnerable to SQL injection in order to extract data from it.

Because this process is slow, blind injection won't be used to perform mass extraction.
Instead, it might be used to retrieve key pieces of information, such as administrative login credentials, and those credentials will be used to take further system action. String sanitization SQL injection is widely known and, because so much data in databases is sensitive, can be extraordinarily high-impact. Why do developers keep writing such bugs? Much discussion of SQL injection describes it as being substantially a problem of input validation.

The order ID in our example above, for example, should be an integer, not an arbitrary piece of text, and so we could fix the code to make it safe by forcing the order ID to be a number, ignoring any other characters.

For numeric data this is easy enough to enforce, as converting strings into integers is easy and robust. But for strings, which legitimately could contain any character under the sun, the process is a little harder. Or perhaps more accurately, it's a process that developers continue to screw up. The basic idea is one familiar to many developers: the special characters (such as quote marks) need to be transformed so that the query treats them as part of a string, rather than the end of a string.
In SQL Server, quote marks are escaped by doubling them.

A single quote mark, ', is used to denote the start or end of a string; two quote marks together, '', are treated as a literal quote mark when included as part of a string. MySQL uses backslashes for a similar purpose; to embed a single quote into a string, it must be written as \' (and to embed a backslash, use \\). This should, then, be straightforward for developers to handle: make sure any quote marks in the input are escaped, and the database will treat them correctly.

This can be done, and it does work if it's done consistently, with every single string properly cleaned up.

But if even one is forgotten, the security of the entire system can be undermined. Often, the "solutions" to this problem are inadequate at best. Many devs will have come across Web forms that prohibit characters such as the single quote from being used in usernames or passwords.

They might even go further and prohibit SQL-like words, such as SELECT, from being used.

These things are telltale signs that a developer is vaguely aware of SQL injection (and perhaps certain other problems, such as cross-site scripting) but has either opted not to make a robust fix or lacks confidence in the fix they have applied. Better yet: stop treating everything as a string The better solution requires changing how we think of SQL injection. The problem is the way that these applications add the parameters to their SQL queries.
In most programming languages, there's a hard distinction between the various special keywords and syntax of the programming languages, on one hand, and the data values that the program manipulates, on the other.

For example, many languages have a keyword goto to jump from one place in the code to another.

They also support text strings, and a text string could contain the text "goto".

These two things are separated; the program will never see the "goto" text string and try to jump to a different location.

Although the string happens to look like a language keyword, it is opaque; most languages don't try to treat data as if it were part of the program, so there is no risk that a string that reads "goto" will accidentally be interpreted as a goto keyword. (A few languages, such as shell scripting and tcl, blur this distinction in some ways, but few people use these on the Web.) SQL, too, maintains this distinction and does not confuse data as if it were commands. Most programs that work with databases, however, are not written in SQL directly.
Instead, they build their SQL queries as strings of text and send those strings to the database to process. By manipulating the queries as pieces of text, however, they create confusion between program commands and data.
String manipulation is done without concern for the syntax and grammar of SQL.
String manipulation doesn't distinguish between the query and the query's parameters, and so it doesn't correctly handle those troublesome quote marks.

A mere string doesn't know that some quote marks should be escaped, because they're meant to be parameters, and that others should not, because they're mean to be part of a query. Developers use strings to build queries because building strings is a basic part of almost all programming languages, and so it's a very simple, familiar way for developers to accomplish tasks. Most development languages don't have any integrated language support for SQL (though C# does have something along those lines), so using strings and string manipulation is the simplest way to get started with writing database-driven applications. Most beginners' tutorials will start with string manipulation, so the habit is inculcated pretty quickly, too.

At some point budding developers will get bitten by an SQL injection bug, so they'll try escaping strings, and that will be as good as it gets. But mainstream database APIs offer a better way of working with SQL—better both because it isn't prone to SQL injection attacks, and better because it can have slightly superior performance, too.

And unlike escaping of inputs, this alternative approach can't really be screwed up.
It doesn't rely on checking and validating every single parameter individually (leaving an application vulnerable if even one parameter should be neglected). That better way is through the use of prepared statements. Prepared statements provide separation between the query and the parameters the query uses.

The exact details vary slightly from language to language and API and API, but the basic idea is the same: instead of splicing together a bunch of strings to create the query, a prepared statement uses a query with placeholders used for each parameter.

The values that these parameters should take aren't populated by manipulating strings; they're assigned using the prepared statement API. For example, using C# and the ADO.NET API, the code would look something like this: // create the prepared statement object from a database connection SqlCommand command = connection.CreateCommand(); // define the query that the prepared statement uses, with @name being a placeholder for a parameter command.CommandText = "SELECT * FROM customers WHERE customername = @name"; // define the parameter as being a string type of any length command.Parameters.Add("@name", SqlDbType.VarChar, -1); // and set the parameter's value to the query string from the URL command.Parameters["@name"].Value = Request.QueryString("customername"); The API knows that the @name parameter should be a string (varchar is the SQL name for variable-length character sequences), so when the @name parameter has its value specified (in the last line), the API will always do the right thing.
It doesn't matter if attackers try to pass in quote marks, escape characters, or anything else as they try to trick the system into executing their SQL query; the system will always treat the parameter as string data. Using prepared statements like this rules out any chance of forgetting to escape data or escaping it improperly, because it entirely removes the need to escape data in the first place.

The query can still fail—an attempt to put string data into an integer parameter, for example, will still cause an error—but it will do so in a safe way that does not risk executing attacker-specified SQL queries. A problem that shouldn't still be with us, but is When looking at buffer overflows, one of the major themes was a never-ending series of escalations between defenders and attackers. New techniques, such as non-executable memory and address space layout randomization, have been introduced in operating systems to try to make buffer overflows easier to detect by developers and harder to exploit by attackers, but the core problem is caused primarily by the behavior of the C and C++ languages.
It will not go away until those languages are either abandoned or radically altered.

There's no perfect solution that's compatible with C and C++, so we have instead this range of mitigations and defenses. The same is not true of SQL injection. Prepared statements are a robust and virtually universal solution to the problem of SQL injection.

Every API worth using supports them, and yet SQL injection flaws remain in abundance.

Commercial software, open source software, custom-developed software—they're all afflicted. But with developers apparently unwilling to do things the right way, it's time for the creators of these frameworks to do the right thing and force all database access to go through prepared statements.

This won't make it impossible for wayward developers to use string manipulation and continue to create highly exploitable flaws, but it will make it much less attractive as the default approach to writing data-driven applications. Likewise, tutorials and training need to start doing things the right way from the outset.
Instead of creating bad habits and then trying to fix them, developers should be taught to do them properly from the outset. All this makes SQL injection a particularly frustrating flaw.

This is something that should be an historic artifact, a relic from a time before people understood the importance of writing secure applications, before widespread awareness of hackers and the techniques they use.

That it isn't shows that there's something not quite right about industry software development practices: we know how to do better, but we're not. Our credit cards, passwords, and other sensitive data are going to continue to be placed at needless risk as a result.

You’ve been hacked. What are you liable for?

'It won't happen to me...' but best be prepared Hacking is big news and we’re all susceptible.
In the UK, hackers could face jail time under the Computer Misuse Act, but the question on many businesses’ minds will be where the liability lies if they are hacked. The list of successful mega breaches continues to grow; extra-marital affairs site Ashley Madison hit the headlines last summer when data was exposed about its 37 million users, although it appeared many of those were fake accounts.

Earlier this year, Yahoo! revealed the numbers behind its 2014 data breach – 500 million user account credentials were stolen. In 2016, the SWIFT financial payments system was hacked, and this came after another group using the same approach stole $81m from the Bangladesh central bank.

Even the US central bank, the Federal Reserve, detected more than 50 cyber breaches between 2011 and 2015, according to cybersecurity reports obtained through a freedom of information request. Regulator fine Telecoms company TalkTalk has the dubious honour of having received the largest fine ever imposed by the Information Commissioner’s Office – £400,000 – for a cyber attack which allowed access to customer data “with ease”.

The ICO’s investigation revealed that Talk Talk could have prevented the attack by taking simple basic steps to protect customer information. The TalkTalk fine is far lighter than the £3m fine issued by the then-FSA in 2009 for not having adequate systems and controls to protect customers’ confidential information. But even that fine seems small compared to the new fines on the way under GDPR.
In general, failing to take appropriate measures could lead to a fine the higher of €10m or 2 per cent of an undertaking’s total worldwide annual turnover.
If coupled with other data breaches, these figures could be doubled to €20m and 4 per cent. One of the difficulties facing organisations is that data protection legislation is vague when it comes to specifying the standards of protection required.

The Data Protection Directive and the UK Data Protection Act both require the data controller to “implement appropriate technical and organizational measures to protect personal data against accidental or unlawful destruction or accidental loss, alteration, unauthorized disclosure or access”. This concept is carried over to the new EU General Data Protection Regulation, which will be enforced throughout the EU – yes, including the UK – from May 2018.
In fact, it also requires the controller to build in data protection by design and by default. What does this actually mean though? What measures are appropriate? Well, the ICO has not yet stipulated a particular minimum threshold for protection, but it generally penalises organisations that suffer the loss of unencrypted laptops and mobile devices.

The GDPR itself suggests pseudonymisation and data minimisation as part of a data controller's approach to protection. While the vagueness in the legislation might mean businesses aren’t clear on what they have to do, it also means the law doesn’t have to be constantly updated to specify the latest industry standards on data security.

Besides, every CISO I’ve spoken to has a clear understanding of what measures are appropriate, and it’s just whether they can persuade the CFO to allocate the budget for it. Espionage In March of 2016, a Chinese businessman pleaded guilty to conspiracy to hack computer networks of US defence contractors holding information about the Stealth Bomber, which he was claimed to have passed to the Chinese government. If you operate in the defence industry, you are likely to have made various promises to the government under the Official Secrets Act or the US and other national equivalents. You will probably have a fairly good idea of what is expected of you, so we need not go into detail here, save to reiterate that breaches could amount to jail time. Business failure While state-sponsored hacking does happen, it seems most breaches are actually the result of either criminal activity or "kids messing around".

The Chinese government might not be after your business secrets, but your competitor might.

According to a Secure Works report published earlier this year, hacking a competitor could be as cheap as $500 per mailbox. You should attempt to quantify how much it would cost your business if you are unable to prevent others from seeing your customer database or your price list. Or in the worst-case scenario, all your business data is scrambled. Love or hate Coca Cola and KFC, their businesses are based on keeping their recipes secret and out of the public domain.
If their recipes leak out, it could destroy their business. Why pay a premium for use of information if you can use it for free and develop a competitive product? Lawsuits While it’s unlikely you will get compensation from someone who hacks your data, you might have to pay out to your customer or supplier for any losses they sustain as a result. Every commercial and technology agreement I draft, whether I’m acting for a supplier or a customer, has a clause clarifying that both sides will protect confidential information.

This usually acts as a reminder of the general law of confidentiality, but the greater the perceived value of the information in question, the more the clause will supplement that with extra detail.

At the least it will say a party will use information disclosed to it only for the purposes of the agreement and will disclose it only to those people who need to know it and for the purposes of the agreement. A more robust clause might require the parties to get individual employees or subcontractors to execute a confidentiality undertaking.
Some clauses will say a party will protect the other’s confidential information to the same standard as it protects its own and, in any event, no less than a reasonable standard.
It will often have an acknowledgement that if the confidentiality obligation is breached, compensation would not be an adequate remedy and that a court injunction would be vital to protect confidentiality – although compensation will often be payable too though, if it is too late for an injunction. Finally, many agreements contain an indemnity for breach of data protection or confidentiality obligations. Some business partners will undertake a data security audit of your business to ensure you have adequate measures in place.
Some will rely upon a warranty that you comply with ISO 27001 or some other data standard. At the least, it will turn upon whether you took a reasonable standard of care under the circumstances.

There will be no point relying upon a force majeure exception – an event beyond your reasonable control – if you should have taken stronger security measures.
In its criticism of TalkTalk, the Information Commissioner effectively issued a harsh warning to other organisations: “Yes hacking is wrong, but that is not an excuse for companies to abdicate their security obligations.

TalkTalk should and could have done more to safeguard its customer information.
It did not and we have taken action.” It is worth taking note of two recent court rulings (although neither involved hacking).
In October of 2016, the High Court granted an injunction preventing the misuse of confidential information obtained under customer-supplier relationship relating to the production of edible infused oils.
In June this year, in the culmination of a long-running dispute over misuse of confidential information, the Court of Appeal upheld a judgment that a business rival set up by ex-employees had to pay $485,000 compensation for developing a competitive mosquito net product indirectly using confidential information. Reputation damage and loss of customers Ultimately, if your customers desert you because you have lost their confidence after a data breach, this might be more costly than regulatory fines and legal action.

TalkTalk admitted to losing 101,000 customers and £60m due to the hack.

The fine they received from the ICO pales in comparison against this level of loss and is higher even than the new fines under the GDPR. It won’t happen to me Many businesses are convinced it won’t happen to them. Kevin Mitnick, arguably the world’s most famous hacker and now a trusted security consultant, commented recently that 80 per cent of US businesses have been hacked – many not even aware of it – and HR and sales departments are the most often hacked because they are the least computer security aware. It is clear to me that affordable data breach fines will be phased out under GDPR, and Brexit is unlikely to change that.

Also, businesses have a clear remedy for a breach of confidence.
It might be time for you to reassess your data security and your confidentiality obligations. ®

Accused UK hacker to be extradited to the US to face...

BBCreader comments 30 Share this story Briton Lauri Love will be extradited to the US to face charges of hacking, Westminster Magistrates' Court ruled on Friday. Love faces up to 99 years in prison in the US on charges of hacking as part of the Anonymous collective, according to his legal team. Handing down her ruling at Westminster Magistrates’ Court in London, district judge Nina Tempia told Love that he can appeal against the decision.

The case will now be referred to the home secretary Amber Rudd while Love remains on bail. Love, 31, is alleged to have been involved in the #OpLastResort hack in 2013, which targeted the US Army, the US Federal Reserve, the FBI, NASA, and the Missile Defense Agency in retaliation over the suicide, while awaiting trial, of Aaron Swartz. Love’s legal team, led by Ben Cooper of Doughty Street Chambers, had argued that his case was similar to that of Gary McKinnon, another British citizen whose extradition to the US, also based on allegations of hacking, was blocked by then-home secretary Theresa May in 2012. Like McKinnon, Love has been diagnosed with Asperger Syndrome and depression, conditions the defence argued would cause him to struggle in the US prison system.

Cooper said Love should instead face trial in the UK. His extradition has been requested by three jurisdictions: New Jersey, New York, and West Virginia. The case was widely seen as a test of the so-called "forum bar" that would have allowed the courts to block extradition requests. Sarah Harrison, director of the Courage Foundation, which runs Love’s defence fund and support campaign, said his legal team will apply to appeal against the ruling.
She said: This is a very disappointing ruling, not just for Lauri and his family, but for everyone who was angry about what happened to Gary McKinnon. Clear assurances were given that legal changes would prevent the McKinnon situation from happening again and frankly, if the forum bar can't help Lauri Love, it's very difficult to understand how it could ever help anyone. This is not what the public was led to believe at the time and it’s not something we should stand for. Judge Tempia said (PDF) that she was satisfied that her decision to extradite Love was "compatible with his Covention rights." She added: "I am satisfied that there is a substantial risk Mr Love will commit suicide.

The key issue then is what measures are in place to prevent any attempt at suicide being successful.

But I have found the medical facilities in the United States prison estate on arrival and during any sentence if he is convicted available to him, are such that I can be satisfied his needs will be comprehensively met by the US authorities." Tempia said that the US government "is not required to produce a prima facie case and it is not for me to determine if there is a case to answer," before noting that "there is a strong public interest that the United Kingdom should honour its extradition treaty obligations with other countries." In its reasoning, the ruling states that "most, if not all, of the loss or harm resulting from Mr Love’s conduct occurred in the United States," and notes that there are more than 20 witnesses—including an anonymous informant—all of whom are Stateside. What happens next? Extradition expert Edward Grange, a partner at Corker Binning legal firm, described the protection offered by the forum bar as "illusory." He told Ars: "As far as I am aware, since it came into effect in October 2013, no one has succeeded in barring their extradition by reason of forum. Love has four weeks from today to make representations to the secretary of state [Rudd]," He added: "She has a limited remit and can only consider representations regarding: the death penalty; specialty; and earlier extradition from another country. None of these appear to apply to Love’s case." If Love’s appeal to the home secretary against the ruling prove unsuccessful, he can apply to the High Court for permission to challenge both the judge and Rudd’s decision. He would have to do so within 14 days of any refusal from the home secretary to block extradition, Grange said. This post originated on Ars Technica UK

Ukraine's Central Bank Issued Hacking Alert In April

Country's chief financial body told lenders to strengthen security in wake of cyberattack on bank via SWIFT. The central bank of Ukraine issued an alert on April 28 to lenders in the country to review their security procedures after hackers attempted a theft at an unidentified Ukraine bank, according to a confidential message received by Reuters. The note alleged the incident involved a compromise of the SWIFT messaging system similar to the recent Bangladesh Bank cyber heist, but did not say if the theft was successful. Hackers had transferred $81 million out of Bangladesh Bank’s account with New York Federal Reserve earlier this year by sending fraudulent messages on the SWIFT network. The central bank notice, says Reuters, reported that the Ukraine bank incident came to light following SWIFT’s alert to its customers about fraudulent activities on its messaging system. SWIFT said it is working on improving security and has told banks to improve information sharing. Read more at Reuters. Dark Reading's Quick Hits delivers a brief synopsis and summary of the significance of breaking news events.

For more information from the original source of the news item, please follow the link provided in this article.
View Full Bio More Insights

Alleged Brit hacker Lauri Love bailed amid US extradition battle lull

Final arguments to be heard next month over fate of bloke who 'broke into' FBI boxes Alleged Brit hacker Lauri Love, who is accused of compromising US government servers and faces extradition to America, has been bailed by a UK court. US prosecutors want the 31-year-old university student shipped across the Pond for questioning after allegedly infiltrating systems used by the US Federal Reserve, the Missile Defense Agency, NASA, the FBI, the US Army, and healthcare companies. Staff records and credit card details were accessed by Love between 2012 and 2013, it is claimed. He denies wrongdoing and is fighting to stay in Blighty. After a two-day extradition hearing at Westminster Magistrates' Court in London, District Judge Nina Tempia bailed Love and adjourned the case to a later date when both sides will make their final arguments. Wednesday, July 20 was penciled in as a possible date. Love was arrested in 2013 and again in 2015 on suspicion of committing computer crime, and has been under police bail. Love's lawyers argue his extradition should be blocked under section 83A of the UK's Extradition Act, which forbids any extradition that “would not be in the interests of justice.” The court also heard that Love – who lives with his parents in Suffolk, has Asperger's Syndrome and suffers from depression – would kill himself if extradited. His legal team said, therefore, his extradition should be stopped under section 91 of the 2003 act, which states that an extradition should be halted if "the physical or mental condition of the person is such that it would be unjust or oppressive to extradite him." Love is accused of breaking into Uncle Sam's computers as part of #OpLastResort – the codename for a string of online protests that followed cyber-activist Aaron Swartz's suicide in 2013. While cross-examined this morning by US government lawyer Peter Caldwell, Love spoke of his admiration for Swartz and described him as a wunderkind who was “persecuted by the Department of Justice.” Love's lawyers had drawn a comparison between their client and Schwartz, who killed himself after he was accused of breaking into a network hardware closet on the MIT campus to download almost five million academic papers. Love also spoke of his Asperger's Syndrome diagnosis and battle with depression, and scratched his anxiety-triggered eczema while recollecting childhood memories and answering questions about his past relationships. Caldwell suggested the defense was emphasizing Love's mental health issues “as a shield in these proceedings," noting that Love does not actually take antidepressants. Love shot back that he had seen a doctor about his condition, and raised a laugh from his supporters in the public gallery by asking whether he should have taken medical advice from the prosecution counsel instead. Judge Tempia is expected to make a decision on whether or not to grant America's extradition request by September. Meanwhile, Love is waiting to get back equipment seized by the UK's National Crime Agency. ®