STE WILLIAMS

$950 million deal comes in the wake of Google sanctions on Symantec certs earlier this year.

Symantec will sell its SSL business to DigiCert for $950 million in a move that lets the security vendor avoid the need to entirely rebuild its digital certificate issuance infrastructure following a series of punitive actions by Google earlier this year.

Under terms of the sale announced this week, in addition to the upfront cash, Symantec will also receive a 30% stake in the common stock of DigiCert.

In a prepared statement, Symantec CEO Greg Clark said the proposed sale would sharpen the company’s focus on cloud security. Symantec customers meanwhile will benefit from having a company that offers a modern website PKI platform to handle their digital certificate requirements going forward, he said.

Symantec’s board has approved the transaction, which is expected to formally close in the third quarter of fiscal 2018.

The proposed sale makes sense for Symantec and is consistent with the general direction in which the company has been heading recently, says Garrett Bekker, principal security analyst at 451 Research.

“Symantec has spent about $7.5 billion on acquisitions since they got rid of Veritas,” and began to focus purely on the cybersecurity market, he says. “They are certainly trying to rationalize their portfolio and get rid of non-core assets.”

The plan especially makes sense for Symantec considering the pressure it has been under from Google in recent months, Bekker says.

He was referring to a Google decision from earlier this year to gradually deprecate all Symantec issued digital certificates over the next several months. Google described the decision as being driven by multiple failures on Symantec’s part to properly validate its digital certificates before issuance.

Google said that an investigation it conducted showed that Symantec had allowed at least four parties to access its infrastructure and issue certificates with none of the required checks and balances. Google claimed that an inquiry that began with a set of 127 Symantec issued certificates expanded to over 30,000 suspect certificates over multiple years.

Symantec’s failure to properly oversee the issuance of these certificates represented a failure by the company to adhere to the standards expected of a Certificate Authority and posed a threat to Google Chrome users, Google claimed. As a result, Chrome would, in a phased manner stop trusting all existing Symantec-issued certificates Google said. Going forward, Symantec would need to replace the certificates with new fully validated ones, Google had said.

Symantec itself characterized Google’s claims and misleading and grossly exaggerated. The company claimed that only 127 certificates were identified as mis-issued and not 30,000. Symantec said that Google was singling it out for blame though the mis-issuance involved multiple CAs.

Selling off the certificate business means that Symantec no longer will need to contend with the issue. But “questions about how the certificate infrastructure will evolve if the merger goes through should be uppermost in the minds of customers and partners,” says Michael Fowler, president of DigiCert rival Comodo CA. What still remains to be determined for Symantec customers is how the sale will impact Google’s decision to deprecate all existing Symantec SSL certificates starting October 2018, he says.

Given the problems that Google has identified with Symantec’s infrastructure it is unlikely that DigiCert will use it going forward, Fowler speculates. But DigiCert, as a smaller vendor in this space, does not have the same infrastructure as Symantec, which could be problematic for Symantec’s enterprise customers and channel partners, he claims.

Bekker though sees little to no complication for Symantec’s customers. “I don’t think [the proposed sale] will have much of an impact at all,” he says.

Symantec’s certificate business will immediately increase DigiCert’s market share and make the company one of the biggest players in the PKI and SSL markets, Bekker says. “This will make DigiCert pretty much one of the leaders in terms of revenues,” in the digital certificate business.

Related content

• Symantec to Buy ‘Browser Isolation’ Firm Fireglass
• CAs Need To Force Rules Around Trust
• Digital Certificate Security Fail
• 8 Alternatives to Selfie Authentication

 

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Article source: https://www.darkreading.com/endpoint/symantec-sells-digital-certificate-business-to-digicert/d/d-id/1329555?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Federal authorities indicted and nabbed Marcus Hutchins, aka MalwareTech, for allegedly creating and distributing the Kronos banking Trojan.

In a stunning move, federal authorities have arrested Marcus Hutchins, a researcher who earlier this year was credited with stopping the rapidly expanding WannaCry ransomware attack that spanned 150 countries in a matter of days.

Hutchins, a UK resident who also goes by the alias “MalwareTech,” was indicted by a US federal grand jury on six counts relating to the creation and distribution of Kronos malware, according to a review of the complaint filed in the US District Court in the Eastern District of Wisconsin.

The indictment centers on his alleged creation of the Kronos malware and the alleged subsequent advertising and sale of the malware on Internet forums, such as the now defunct AlphaBay market forum, from July 2014 to July 2015.

A second defendant is listed in the indictment, but the name is blacked out. This defendant allegedly showed the functionality of the Kronos banking Trojan via a video posted on a publicly available Internet site in July 2014. He or she then allegedly offered to sell the banking Trojan for $3,000 on an Internet forum in the following month, according to the indictment.

Around February 2015, Hutchins and the second defendant allegedly updated Kronos’ malware, and in April of that year aadvertised its availability on the now defunct AlphaBay Dark Web market forum, the indictment states. Then in June 2015, the other defendant allegedly sold the Kronos malware for approximately $2,000 in digital currency and then offered Kronos crypting services.

In late 2016, the Kelihos botnet was seen loading Kronos on computers via a phishing attack. Earlier this year, DOJ officials announced that the Kelihos botnet had been dismantled.

Federal authorities were deep into their two-year investigation into Kronos when the WannaCry ransomware attack emerged in May of this year and swept through a large footprint of countries.

Hutchins, who managed to stop the spread of the WannaCry attack shortly after it started with his kill switch, ironically, may have already been the target of the grand jury investigation when he became the accidental hero of the WannaCry outbreak.

The grand jury, nonetheless, delivered a six-count indictment against Hutchins on July 11, roughly two weeks before the start of Black Hat USA and DEF CON in Las Vegas, where Hutchins was scheduled to attend. Authorities arrested Hutchins in Las Vegas on Wednesday.

The indictment against Hutchins includes one count of conspiracy to commit computer fraud and abuse, three counts of distributing and advertising an electronic communication interception device, one count of trying to intercept electronic communications, and one count of attempting to access a computer without authorization, the DOJ stated in its announcement.

Some industry watchers, however, remain skeptical about the grounds for Hutchins’ arrest. On Twitter, Alan Woodward (@ProfWoodward) tweeted: “Bearing in mind he tracks botnets and Kronos is a botnet, potential for this being a big misunderstanding. FBI enforcing a DoJ indictment.”

Other skeptics include Swati Khandelwal, who via Twitter noted that on July 13, 2014, Hutchins posted a tweet that read: “Anyone got a kronos sample?”

Khandelwal then tweeted: “Creator asking for his own malware sample…doesn’t this sound strange to the FBI?”

Other skeptics include Swati Khandelwal (@Swati_THN), who noted that on July 13, 2014, Hutchins posted a tweet via his @MalwareTechBlog Twitter handle that said: “Anyone got a kronos sample?”

Khandelwal tweeted today: “Creator asking for his own malware sample…doesn’t this sound strange to the FBI?”

Meantime, DoJ officials were not immediately available to comment on the identity of the second defendant.

Related Content:

• Here Are 4 Vulnerabilities Ransomware Attacks Are Exploiting Now
• Researcher Creates Tool to Unlock WannaCry-Infected Windows XP Files
• NSA Reportedly Confident North Korea Was Behind WannaCry
• Best of Black Hat: 20 Epic Talks in 20 Years

Dawn Kawamoto is an Associate Editor for Dark Reading, where she covers cybersecurity news and trends. She is an award-winning journalist who has written and edited technology, management, leadership, career, finance, and innovation stories for such publications as CNET’s … View Full Bio

Article source: https://www.darkreading.com/threat-intelligence/wannacry-kill-switch-creator-arrested-in-vegas/d/d-id/1329556?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Raytheon Cyber Services’ CEO Paul Perkinson and Chief Strategy Officer Joshua Douglas discusses how a layered approach of assessment, threat hunting, and training can pave the way for more secure enterprise data.

Article source: https://www.darkreading.com/three-steps-to-strong-enterprise-security/v/d-id/1329557?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Google on Monday quietly released an Android version of a native adblocker (or ad filter, as they’d rather call it) for Chrome.

As we reported when Google’s top ad guy – Sridhar Ramaswamy, senior VP of ads and commerce – blogged about “building a better web for everyone” in June, the new feature isn’t designed to block all ads so much as control those that are particularly annoying.

Also in June, the Wall Street Journal reported that Google hadn’t talked about the new ad filter with anybody save publishers, agencies and advertisers. When it briefed publishers, it gave them six months to prepare. Part of that preparation was a self-service tool called “Ad Experience Reports” that alerts them to offending ads on their sites and explains how to fix the issues.

Issues that will get an ad filtered include videos that autoplay with sound; prestitial ads that block home pages, often while a timer ticks down; repeated pop-ups (which Chrome already has the option to block); and sticky ads that persist in spite of scrolling. In other words, it will only block those ads that don’t adhere to guidelines from the industry’s Coalition for Better Ads.

To try out the new ad-blocking version of Chrome, you’ll have to download a version of Chrome named Canary, as first spotted by Carsten Knobloch on Monday and confirmed by TechCrunch.

Knobloch says that users have already been finding the blocker in the Chrome version for Android, if they’re based on the Canary or Developer version. It’s set to filter ads by default.

Google warns that Chrome Canary is “not for the faint of heart.” Designed for developers and early adopters, it’s unstable. If you’re up for a browser prone to breakage, you can get the Android version on Google Play.

There’s also a page for a desktop version, though it doesn’t yet have the ad filter. The Wall Street Journal’s report did mention that the feature is due to go live, presumably including on the desktop version of Chrome, sometime in 2018, which jibes with the six-month window Google gave publishers to prepare.

The stable version of Chrome can run concurrently with Android Canary. It offers the option of blocking all ads on websites that have a reputation for rule-breaking advertising.

Another important piece of Google’s “better web for everyone” is a tool that was in limited beta as of June. It’s called Funding Choices, which is Googlese for “making money off people who refuse to turn off their adblockers.”

The revenue, which will be stored in a Google digital wallet, will be split between publishers and Google. That, of course, is just one of a few spins on the ongoing dilemma of how to solve the adblocker/adblocker-blocker wars.

It’s a knotty problem: publishers need to buy groceries just like any of us, and ads are, for better or worse, the mechanism that the web evolved to recompense them for their content. Being starved of ad revenue by adblockers has caused many sites to turn off the spigot when it comes to free content. Wired was one such: 18 months ago, its polite request that visitors support the site by turning off their adblocker or whitelisting the site developed fangs when it announced that it would be launching an ad-free, subscription-based version of the site.

For its part, Facebook started bypassing adblockers on its desktop site a year ago.

Oh no you DON’T, Adblock Plus (ABP) fumed.

Drawing on help from the open source community, within one day, ABP announced that it had reblocked Facebook ads, foiling what Facebook’s wishful thinking had dubbed its “adblocker-proof format.” Within hours of Adblock Plus having claimed victory, Facebook’s advertising crew started rolling out new code that pulled the rug out from under Adblock Plus’s workaround.

Arguably the most galling of the skirmishes in the adblocking/adblocker-blocker/anti-adblocker-blocking/oh-no-you-DON’T adblocker blocker blocking wars was in January 2016, when Forbes offered users who disabled their adblockers an “ad-light” version of the site.

At least Wired had acknowledged the good that adblockers do when it told people to pay up or get lost. Not so Forbes. With impeccably bad timing the publisher immediately fell victim to an attack that served up malvertising to users who had turned off their adblockers.

Malvertising, as in, one of the main reasons that people use adblockers in the first place: to ward off malicious online advertising wherein booby-trapped ads either try to inflict our computers with malware or potentially unwanted content, or silently steal passwords, personal data and banking information.

Besides protecting user security, adblockers protect privacy by keeping users from being tracked across sites. They also preserve performance, battery life and data usage on mobile phones.

Obviously, the adblocker wars are a muddle of competing needs. It doesn’t help matters when industry scaremongers push out confections that seem suspiciously frothy, such as the 2015 report by Adobe and PageFair that accused adblockers of costing businesses $22 billion over the course of the year.

Google’s Funding Choices is only the latest approach to sparing users from the multi-headed beast of advertising while getting some recompense to publishers. It’s not the first such attempt, though: a browser called Brave launched in April 2016 with the idea of paying Bitcoin to users who agree to view “clean” ads or paying sites in exchange for having their ads blocked.

Brave launched its first payments to sites in September, but payment to users seems to have slipped out of the conversation.

…which matches Google’s Funding Choices. Payments to users who agree to view ads likely won’t ever be part of the “better new web for everyone” that Google’s creating or that browser competitors such as Brave have mulled. Instead, Google is looking to squeeze micropayments from users if they insist on clinging to their adblockers.

Which is fine. There are other, free options out there in the world of adblocking if you don’t feel like supporting sites with micropayments.

The only payment required for most adblockers, after all, is a potential pang of conscience for starving publishers of revenue.

Follow @NakedSecurity
Follow @LisaVaas

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/txvc7435FY4/

Add one more to the lengthening list of ways your connected car can get hacked.

The NCCIC/ICS-CERT (National Cybersecurity and Communications Integration Center/Industrial Control Systems Cyber Emergency Readiness Team) issued an “alert” late last week following the release of a research paper on, “a vulnerability in the Controller Area Network (CAN) Bus standard with proof-of-concept (PoC) exploit code affecting CAN Bus.”

That, according to researchers Andrea Palanca, Eric Evenchick, Federico Maggi, and Stefano Zanero, can allow an attacker, “to perform a denial-of-service (DoS) attack (on) automotive networks.”

Which, in the case of vehicles, is more of a “denial of control” attack.

In their paper, “A Stealth, Selective Link-Layer Denial-of-Service Attack Against Automotive Networks,” presented at the DIMVA 2017 in Bonn, Germany, the researchers said it could allow an attacker to control, “even safety-critical inputs such as throttle, steering or brakes.”

Even if physical danger was not the goal, they said attackers could use it to demand a ransom for the owner to be able to start the car, or could prevent the doors from being locked.

And this type of attack, they said, would be more stealthy than previous types and, because the attack is based on CAN protocol weaknesses,“all CAN bus implementations by all manufacturers are vulnerable,” they wrote.

Beyond that, they conclude that the, “barrier to entry is extremely low.”

Perhaps. But, according to ICS-CERT, it would require:

…physical access and extensive knowledge of CAN to reverse engineer network traffic to perform a DoS attack disrupting the availability of arbitrary functions of the targeted device.

So while the potential damage from such an attack could be catastrophic, it appears to be less likely than those that can be done remotely – the 2015 hack of a Jeep Cherokee by Charlie Miller and Chris Valasek is perhaps the most famous example, but there have been plenty of others.

Still, this is yet another example of the multiple vulnerabilities of the CAN Bus standard – a pervasive problem that the auto industry in general doesn’t seem to be in a great hurry to address.

The CAN is essentially the car’s internal communication system of electronic control units (ECUs) that the researchers note, “is driven by as much as 100,000,000 lines of code.”

Earlier this year, Miller and Valasek released a collection of research notes, profiled in some detail by Naked Security’s Danny Bradbury, who wrote that, “ECUs handle things like adaptive cruise control, electronic brakes, parking assist and control of the steering column, so if you can interfere with these systems, you can at the very least monitor what the car is doing, if not control it.”

Bradbury also noted that Evenchick, one of the four authors of the research paper, is among several who have been providing “automotive hackery” to the world. Evenchick’s open source automotive toolset is called CANtact.

The researchers offered a detection strategy based on differential internal resistance (Rdiff), in which they said a detection mechanism could “find out when a (new) node is connected by measuring the amount of current necessary for a dominant condition at each vehicle startup and comparing this value with the previously registered ones.”

They also listed a number of mitigation strategies, including network segmentation (separate CAN network protected by firewalls), “encryption of the ID and Data Field of CAN frames,” and limiting access to input ports.

But ICS-CERT said the port access limits are, “the only current recommendation for protecting against this exploit. The agency’s announcement said it is “currently coordinating with vendors and security researchers,” to identify more of them.

Palanca, another of the authors, added that since their attack was, “based on the transmission of single dominant bits, not frames,” he expects it to, “become extremely relevant in the near future, when cars will start shipping with onboard security appliances and will become more and more autonomous, with safety-critical operations depending on the reliability of transmissions happening on their CAN buses.”

Eddie Habibi, founder and CEO of PAS, a vendor in the ICS industry, agreed. “Just because we cannot simulate a remote cyber breach today, it doesn’t mean that it won’t happen in the future,” he said.

The issue, he said, is that, “manufacturers continue to release products – in this case a three-ton product that can hurtle down a highway at 60 miles per hour carrying our most valuable possessions in the world (family members) – that are built without security as a fundamental design principle.”

Finally, the CAN weaknesses are a potential threat that will have to be addressed by more than the auto industry. ICS-CERT noted that, “CAN is widely used throughout the critical manufacturing, healthcare and public health, and transportation system sectors.”

Follow @NakedSecurity
Follow @tarmerding2

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/3MP0agXzTMM/

Your daily round-up of some of the other stories in the news

WannaCry ‘kill switch’ man detained

When the WannaCry virus hit back in May, 2017, a young man from the UK reported that the malware contained what became known as a kill switch.

Simply put, WannaCry tried to contact a weirdly-named website just before infecting your computer; if a reply came back, then the malware went no further.

The weirdly-named website didn’t exist when the worm first appeared, so Marcus Hutchins, 23, quickly registered the “immunisation domain” himself and set up a webserver on it, thus limiting WannaCry’s virulence.

He was soon hailed as a hero – rapidly becoming something of a security celebrity around the world.

But now there’s a new twist to the story: it seems that Hutchins was recently arrested by the FBI in Nevada, USA, where he had travelled to attend the annual DEF CON hacking conference.

Right now [2017-08-03T18:00Z], we don’t know why he was arrested, or what he has been charged with, if anything.

We now [2017-08-03T19:44Z] know that Hutchins has been accused of writing, advertising and selling commercial malware called Kronos, three years ago.

Firefox Launches “Send” Test Pilot

Firefox has announced a new Test Pilot feature allowing you to send large files over the internet easily and quickly.

The project, called, “Send,” encrypts files during transmission, then self-destructs the files after download. The files are encrypted client-side, so even Mozilla can’t access the files when they’re sent.

The file is uploaded and a link is created for the user to share with the recipient. The download expires after 24 hours.

Additionally, Mozilla is working on Speech to Text (STT) functionality for Firefox called “Voice Fill,” and a note-taking option – called, unsurprisingly, “Notes” – that creates a simple, convenient place to take notes as well as store them.

Firefox invites users to try out its Test Pilot programs and offer feedback. More information can be found here.

Death-threat DDoSer arrested

The FBI recently arrested a man who allegedly made and carried out various criminal threats against websites in the USA, Australia and Canada.

The threats included distributed denial of service attacks (DDoSes), where a criminal commands a large number of computers in a botnet to generate simultaneous network traffic aimed at victims’ networks.

For example, if the usual web load you can handle is, 10,000 simultaneous visitors, and a crook manages to summon up DDoS traffic from 9999 time-wasting pseudovisitors, you’ll be down to 0.01% of your usual business capacity.

The man, Kamyar Jahanrakhshan, 32, had been convicted of theft in the USA in 2005, and for fraud in Canada in 2011. After serving a prison sentence in Canada, he was deported back to the USA in 2014.

It seems that he wanted his name removed from numerous websites in the USA, Australia and Canada, where it was mentioned in connection with his legal troubles, and that he turned nasty when his requests were refused.

Jahanrakhshan not only threatened and carried out DDoSes, but also claimed that he would “send bomb threats to [a media company’s] offices across Canada”, and told the Canadian Broadcasting Corporation that he would “threat [sic] the lives of families of CBC employees”.

Even though he’s not yet been convicted, his name is now more widespread than ever online.

Catch up with all of today’s stories on Naked Security

Follow @NakedSecurity

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/kXqzDIIAWmo/

An email has gone out from IBM about its Bluemix cloud: after next Tuesday, the SoftLayer APIs will no longer accept connections encrypted with the ancient TLS 1.0.

It’s not quite a surprise that the 1990s-era protocol was still accepted: a great many services are still midway through their deprecation plans.

To give just one example, Salesforce began its phase-out of TLS 1.0 in production instances on July 22, 2017.

And the PCI Council, which had originally wanted TLS 1.0 gone last year, had to extend its deprecation date to 30 June, 2018 (and it’s still blogging early warnings for members, in case they’re still failing to catch up).

In the Bluemix email, IBM notes: “There should be no impact to customers using a modern web client. This notification is intended to be informative only.”

The two services affected by the deprecation are api.softlayer.com and api.service.softlayer.com – so there’s another community that’s got to pay attention, namely developers who wrote to the APIs and used TLS 1.0 to secure their API access.

TLS 1.0 has long been known as insecure, as far back as 2011 when it was bitten by the BEAST exploit. ®

Sponsored:
The Joy and Pain of Buying IT – Have Your Say

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/08/03/wait_what_the_ibm_clouds_apis_use_tsl1/

Updated Marcus Hutchins, the unassuming Brit who found and activated the kill switch in the WannaCry ransomware, has been arrested by the FBI in America.

Hutchins had been invited over to the States for the DEF CON hacking conference, held last week in Las Vegas, Nevada, and stayed on a few extra days to do the usual touristy things in the area. He attended various parties at the event, went shooting, as is somewhat traditional, and had been planning to return home yesterday.

I’m actually pretty excited to get back to work soon. Haven’t touched a debugger in over a month now.

— MalwareTech (@MalwareTechBlog) August 2, 2017

The UK’s National Crime Agency confirmed to The Register tonight that a UK national was arrested in Nevada, but couldn’t comment on why nor on what charges or suspicions. A spokesperson for the FBI field office in Sin City was not available for immediate comment.

It’s understood Hutchins, aka MalwareTechBlog on Twitter, was just about to board a flight back to the UK on Wednesday when the Feds swooped and took him away to an undisclosed location. His worried friends say they still have no idea where he is being held nor why.

His pal Andrew Mabbitt, founder of Fidus Information Security, today confirmed that 23-year-old Hutchins had been cuffed by the Feds on August 2. “I’m working on getting a lawyer for @MalwareTechBlog as he has no legal representation and no visitors. I’ll be crowdfunding legal fees soon,” Mabbitt added.

Hutchins, who works for a US infosec biz from his home in Blighty, was well-liked at the conference, and won praise from such luminaries as car hacker Charlie Miller. The Brit narrowly missed out on winning a Pwnie Award for his work on reverse engineering the WannaCry nasty.

Last time @MalwareTechBlog went missing, he lost his wallet and slept in a hotel lobby. Sadly I don’t think it’s the same story this time.

— Timothy Davies (@0xtadavie) August 3, 2017

We can only hope Hutchins, while waiting to fly back from his summer break, didn’t make an unfortunate joke or three to the US Transportation Security Administration, who lack any modicum of a sense of humor about such things. ®

Updated to add

Hutchins is being held at the Las Vegas FBI field office, according to Andrew Mabbitt. Also, hat tip to journo Joseph Cox for breaking the news. We’ll update this story with more information as it comes in.

Final update

Hutchins was arrested on suspicion of creating bank-account-raiding malware Kronos.

Sponsored:
The Joy and Pain of Buying IT – Have Your Say

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/08/03/wannacry_killer_hutchins_arrested/

Marcus Hutchins, the British malware researcher who killed off the WannaCry ransomware outbreak, was arrested in Las Vegas on Wednesday on suspicion of being a malware writer himself.

Hutchins, aka MalwareTechBlog on Twitter, was collared after attending the DEF CON hacking conference in Nevada, US, last week. FBI agents nabbed the 23-year-old at Sin City’s airport yesterday as he was preparing to fly back home to Blighty after a summer break of fast cars, gun ranges, and hacker parties.

According to a grand jury indictment distributed today by US prosecutors, Hutchins is accused of crafting, sharing, and masterminding the Kronos bank-account-raiding Trojan between July 2014 and July 2015.

The heavily redacted court document alleges Hutchins is the creator of Kronos, and updated the code in February 2015 with a co-conspirator, who made a helpful video on how to use the malware. Soon after this article was published, the YouTube vid was removed.

The partner is also accused of advertising the Kronos nasty on hacker forums, selling at least one copy for around $2,000, and offering to sell another to a third party for $3,000. The US government also claims that on June 11, 2015, Hutchins himself intentionally sold attack code in America.

The six-count indictment was filed in the Eastern District of Wisconsin on July 12 of this year. Hutchins’ accused conspirator has had his or her name redacted. This will either be because the Feds have yet to collar the suspect, or that the person has turned informer and the agents are looking to protect their sources.

Kronos was an evolution of the infamous Zeus malware, which silently infected PCs and pillaged victims’ online bank accounts around the world. Crooks would buy copies of Kronos, spread it across the internet via spam or booby-trapped downloads, and then pocket the cash siphoned from infected victims. It was reportedly selling for $7,000 apiece and advertised itself as being able to:

• Rip people’s online banking credentials from Internet Explorer, Firefox and Chrome on Windows machines.
• Fend off rival Trojans and avoid detection using a 32- or 64-bit rootkit.
• Bypass antivirus and unspecified sandboxing.
• Establish encrypted command and control communications.

The way the malware was packaged was also quite advanced. For a $1,000 deposit, criminals could try a version of it out before buying, and its operators offered a host of add-on modules and support services.

Strangely, Hutchins tweeted the following on July 13, 2014 – the same day the above video was posted, adding a further twist to the plot. Why would he ask for samples of Kronos, malware he is now accused of developing?

Anyone got a kronos sample?

— MalwareTech (@MalwareTechBlog) July 13, 2014

The long arm of the law

Hutchins is – of course – presumed innocent until proven guilty. And don’t forget that grand juries are indictment-issuing machines. However, if these allegations are true then it’s a stunning fall from grace. Just months ago, he was hailed as a hero for discovering and activating a kill switch in a ransomware outbreak that crippled the UK’s NHS and numerous companies around the world.

The manner of his arrest is also interesting. While Britain has an extremely favorable extradition treaty with the US – thanks to Tony Blair bending over backwards to accommodate his buddy George Bush – it appears the Feds decided not to go that route.

Instead they let him come to them, and chose to arrest him at the end of his stay, when his electronic equipment would have been packed full of information he had gleaned during his visit. Arresting a suspect at the airport also gives a controlled environment in which to do the job.

It’s speculated Hutchins, a reverse engineer who worked remotely for California-based Kryptos Logic, was nabbed after the Feds shut down the dark-web souk Alphabay, where Kronos was once sold, in early July. That operation may have helped investigators unmask the Trojan’s masters, alleged to be the Brit resident and citizen.

Hutchins now faces an extended break in the US, and he is right now being held at the FBI field office in Las Vegas. He is due to be arraigned in the next couple of hours. ®

Sponsored:
The Joy and Pain of Buying IT – Have Your Say

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/08/03/wannacrykiller_cuffed_over_kronos_banking_trojan/

What’s This?

Token-based authorization that lets users prove their identity through Facebook, Google, or Microsoft credentials can dramatically reduce your attack surface and give enterprises a single point of control.

The year 2016 has been called “the year of stolen credentials,” and with good reason. Between the massive breaches at Yahoo, LinkedIn, Tumblr, Twitter, and Dropbox, it’s estimated that over 2 billion records were stolen. Although attackers steal all kinds of data, a vast majority of what’s stolen are user credentials, and they’re being put to bad use. The 2017 Verizon Data Breach Investigation Report found that 81% of hacking-related breaches leveraged stolen and/or weak passwords. What’s more, these stolen credentials are readily available for sale on the dark Web to anyone willing to pay the price.

What Is Credential Stuffing?
With this glut of stolen credentials, we’re seeing a rise in what are known as “credential stuffing” attacks. Attackers use automated tools to test stolen credentials in the login fields of other, targeted websites (hence, the name credential “stuffing”). When a username/password pair grants the attackers access, they take over that account for fraudulent purposes. By some estimates, as many as 90% of all login attempts on web-based applications at Fortune 100 firms are actually credential stuffing attempts rather than legitimate logins. 

Often organizations think that they’re “safe” if their own data has not been stolen, but that’s simply not true. One of the reasons credential stuffing is so wildly successful is that many people (73%, by a 2015 estimate) reuse their passwords for multiple applications—both personal and work-related. This significantly increases the attack surface and the risk to everyone, because if attackers can gain access to one application with stolen user credentials, there’s a good chance those credentials will work with another application, and another, and another…

This is why credential stuffing is such a critical threat to organizations. Many enterprises have multiple web-based applications exposed on the Internet that are protected by nothing more than—you guessed it—login credentials. So, even if your own internal systems have not been breached, it’s conceivable that your external applications—whether you have 5 or 500 of them—will be targeted by attackers using stolen credentials. Breach or not, your applications are potentially at risk. This problem is compounded by the fact that few applications (yet) support multi-factor authentication (MFA). Without it, applications are especially vulnerable because they have only one layer of protection and are therefore easily compromised using stolen credentials alone.

For many organizations, the attack surface is even broader still because their application programming interfaces (APIs) are also vulnerable. Typically, APIs are the set of clearly defined methods of communication between various software components. Although there are several methods for authenticating APIs, it’s surprising how many are still authenticated using only login credentials.

Consider, too, that the authentication and authorization process is typically separate for each application or API, so organizations must monitor and protect each application independently. It’s kind of like trying to manage a border wall built in 50 separate sections by 50 different contractors, each section with its own gate, varying levels of staff and monitoring, and unique admittance policies. Without any coordination or consistency across those 50 sections, each gate is a penetrable target. The potential exists for thousands of people using stolen credentials to pass through those 50 gates. Now consider the nightmare scenario in which millions of people’s passports have been stolen and handed out indiscriminately to a bunch of bad guys trying to enter through those gates. That’s fundamentally what credential stuffing is like—only it’s automated, so it’s far more dangerous. This kind of approach to border control—which is essentially the same function that authorization solutions provide to web-based applications—can quickly become a security and management nightmare.  

Methods for Dealing with Credential Stuffing
There’s no shortage of advice online about how you can help mitigate credential stuffing attacks. Of course, it makes sense to train users not to use duplicate passwords, implement multi-factor authentication wherever possible, and strengthen your access policies, for example, by forcing password resets after significant breaches occur. It’s all good advice, but it’s not sufficient. It bypasses the heart of the problem, which is that our approach to authorization is quickly becoming outdated.

It’s time we considered the feasibility of a token-based authorization model. What is token-based authorization? In simplest terms, it’s a framework that enables a user to access an application without having to provide their credentials to that application itself. Instead, the user is granted access using managed access tokens. As a user, you’ve already proven your identity (authentication) using your Facebook, Google, or Microsoft credentials, so whatever application you are trying to access isn’t looking for you to supply your credentials again. Instead, as an OAuth-enabled application, it’s only looking for a token to authorize your access. If it receives a valid one, the user is granted access; if it doesn’t, the user is denied access; It’s that simple. Because token-enabled applications don’t even use credentials to authorize users, they can reduce the incidence of credential stuffing attacks by drastically reducing the attack surface area.

A more practical evolution of this token-enabled model would be to avoid rewriting applications altogether. Instead, implement an authorization gateway that supports OAuth and can translate OAuth authorization back to the application. In doing so, you essentially move all authorization away from being handled at the application/API level and centralize this service for all applications. In our border wall analogy, it would be like closing 49 of the border wall gates in favor of one, centralized gate through which all visitors would pass. This would dramatically reduce the credential stuffing attack surface and gives you a single point of control for all authorization.

Get the latest application threat intelligence from F5 Labs.

Michael Koyfman is a Sr. Global Security Solution Architect with F5 Networks with a 12 year tenure with the company.  He is focused on the entire portfolio of F5 Security products, and over the last 7 years has been a key contributor to implementation, strategy, and … View Full Bio

Article source: https://www.darkreading.com/partner-perspectives/f5/fight-credential-stuffing-with-a-new-approach-to-authorization/a/d-id/1329493?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple