STE WILLIAMS

Police in the US state of New Mexico are crediting a smarthome device with saving the life of a woman and her daughter who were being held captive by a man who unintentionally told the device to call the sheriff.

According to ABC News, a crisis team – including a SWAT team – were sent to the house and managed to take the man into custody after an hours-long standoff.

That man was Eduardo Barros. He was house-sitting with his girlfriend and her daughter on July 2. The couple reportedly got into an argument that turned violent, according to the Bernalillo County Sheriff Department.

As ABC News tells it, Barros allegedly held up a firearm and threatened to kill the woman, asking her: “Did you call the sheriffs?”

The utterance triggered a smart speaker – we don’t know what type; the police had initially and erroneously said it was a Google Home device – that was hooked up to a surround sound system inside the home. The speaker recognized Barros’ utterance as a voice command and called emergency services.

Bernalillo County Sheriff Manuel Gonzales III said in a statement to ABC News that the device’s mistake possibly saved the woman and her child:

The unexpected use of this new technology to contact emergency services has possibly helped save a life. This amazing technology definitely helped save a mother and her child from a very violent situation.

Barros is facing charges of possession of a firearm or destructive device by a felon, aggravated battery against a household member, aggravated assault against a household member and false imprisonment. He’s being held without bond.

This isn’t the first time that voice assistants have been credited with life-saving calls.

In March, Apple’s Siri voice assistant was credited with saving a London woman’s life. When she fell to the floor, unconscious, her four-year-old son unlocked his mother’s mobile phone by pressing her thumb to it. Then, he asked Siri for help. Siri dialed 999: the British emergency number. With life-saving first aid, she survived and was taken to the hospital.

Also, in June 2016, an Australian mother, rushing to the nursery when a baby monitor showed her one-year-old had stopped breathing, dropped her phone while she was turning on the light. She still managed to tell Siri to call for help while she performed CPR. Both she and her husband credited the few precious seconds that Siri gave them for potentially making all the difference.

The outcome of that particular story is one of the upsides of the fact that recent iPhones can be set to always be listening for commands. That new feature came about in iOS 9, when Apple enabled activation of the built-in personal assistant at the sound of your voice, rather than waiting for you to hold down the Home button.

If that’s turned on, Siri can not only open music and send text messages, it can also make hands-free phone calls on its own while you drive, or, while you’re in critical situations. Note that Siri in hands-free mode only works on newer models when not plugged in to a power source. Older models – at least back to 5s – need to be plugged in to a power source to enable Siri to work in hands-free mode.

Other phone brands can also be set up for hands-free voice assistance, of course. These stories illustrate one good reason why people might want to activate the feature. Police have urged parents to teach children their home address, as well as how to unlock a phone and how to summon help, whether it’s through a voice assistant or by pressing an emergency services number like 999 in the UK or 911 in the US.

It’s worth noting that you can make an emergency call on a locked phone. The feature is available on the Lock screen of every iPhone: press the Home button to trigger the passcode screen, after which you can bypass the lock to either make an emergency call or access someone’s Medical ID information.

Ditto for Androids: Tap Phone (if your phone is locked, tap Emergency Call). If that doesn’t work, swipe to get to the login screen, which will offer an option of placing the emergency call. Android allows you to set up four emergency contacts, and it presents a number pad to call for emergency services and an icon for emergency medical information.

We’ve reported on the privacy implications of always-on listening technologies, but rarely do we get a chance to point to something as positive as lives being potentially saved due to the relatively recent emergence of this technology.

It’s a welcome departure from our always-on-listening-devices norm, which has otherwise been taken up with things like all the internet-connected, artificially intelligent and very scary toys that listen to your kids!

Follow @NakedSecurity
Follow @LisaVaas

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

India’s newest telecoms provider is investigating what could be the country’s biggest data breach, according to local reports, with the records of potentially more than 100m subscribers having been exposed online.

The data apparently belonging to Jio Reliance subscribers was posted on a website called magicapk, which has since gone offline, and included:

• First, middle, and last names
• Mobile numbers
• Email addresses
• Aadhaar numbers
• Dates and times of SIM card activations

Jio is the newest player in India’s wireless telecommunications sector. A subsidiary of Reliance Industries, it launched its  4G cellular network and services in September 2016, and at the end of the first quarter of 2017, had just over 108m subscribers out of India’s total population of some 1.3bn.

The inclusion of Aadhaar numbers adds to the concern, as the scheme, set up by the Indian government in 2009 to register every citizen with a 12-digit number and their biometrics, has faced sharp criticism over its scope and reach, with critics calling it “Orwellian”. The scheme now covers pretty much the entire population, having registered 1.15bn people.

Critics have included the National Advisory Council, Citizens Forum for Civil Liberties, and the Indian Social Action Forum. Now that these details seem to have been part of the data leaked from Jio, those concerns are starting to look prophetic.

Jio moved to reassure subscribers, insisting that the data that had been exposed was “unauthentic”, adding:

Prima facie, the data appears to be unauthentic. We want to assure our subscribers that their data is safe and maintained with highest security. We want to assure our subscribers that their data is safe and maintained with highest security. Data is only shared with authorities as per their requirement.

However, many Indians on the /r/India forum on Reddit claimed that at least some of the details exposed were genuine, with one saying:

I used an unique email (address) which I have not used anywhere else and can confirm leaked data is from Jio’s database.

Another added:

I got my number activated yesterday only, and it’s in the leaked database which shows an email id which I haven’t given to anybody else. So no, it’s not three months old.

Another Reddit user shared a screenshot of a post on a forum hosted in the Onion network claiming to have the data for sale.

If the data has indeed come from Jio, it’s a big setback for the company, which has grand plans to conquer India’s mobile market.

Follow @NakedSecurity
Follow @kim_crawley

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

Drone hackers are busy at work exploiting the application security shortcomings of a major manufacturer to circumvent restrictions, including flight elevation limits. DJI says it has pushed out a firmware update to nip the problem in the bud, but one expert The Register spoke to maintains that hacking is still possible.

The potential for drone hacking can be traced back to a mistake made by DJI in leaving development debug code in its Assistant 2 application. Changes could be made by commenting out one line in a file and setting the debug flag from false to true. The shortcoming exposed a full range of parameters that enabled hackers to turn off safeguards.

“It’s looks like ‪#DJI‬’s ‪#Spark‬ was jailbroken due to poor app security? Leaving dev code passwords in the app was probably not a good idea,” UAVHive, a UK-based drone enthusiast community, said in a Twitter update.

Other DJI products – including the Phantom and Inspire 2 – have had the same jailbreak proven.

Youtube Video

DJI has been warned repeatedly since at least April, if not before, by Kevin Finisterre, a drone security expert, among others. Despite this, critics say DJI failed to act.

Concerns centre on the application security risks posed by the presence of DJI debug code in publicly released applications, something that creates a backdoor for hackers to meddle with the technology.

Recently numerous underground groups of drone users have sprung up and are collaborating on removing restrictions from their drones and even change performance parameters. For example, a Facebook group for drone enthusiasts included hackers in its ranks. A Slack group is even more active and seems to be where a lot of the actual effort is taking place, we’re told.

“The main focus of efforts is removing height restrictions with ongoing efforts to remove no-fly zones, there’s even secret groups of drone pilots now having height competitions to see who can push their drone’s performance the furthest,” a source told El Reg. “A lot of this extreme behaviour by DJI owners is a direct backlash at DJI for adding a range of restrictions including having to connect to their servers via the internet. Recently, for example, DJI’s infrastructure was down and users complained they were grounded as a result. The no-fly zone database has many false positives.”

Coding is steadily under way to simplify the removal of restrictions such as NFZs (no-fly zones) and turbo-charge performance of DJI drones.

A “no limit” drone app

“Users have been able to increase radio range, which breaches EU laws,” one expert, who did not wish to be named, told El Reg. “This allows the drones to fly further (keeping in mind the UK legal limit is 500m distance from the pilot) but owners are flying miles.”

UK laws for recreational flights are summarised here. Height limits are explained here.

Height limits have been removed, allowing users to circumvent safety restrictions that ought to apply to their kit. Thanks to various hacks, users have been posting online photos/video at heights well above the 120m limit.

The process is not complicated and has even gone mainstream, as illustrated by a YouTube video on how to ‪modify DJI drone flight parameters to remove altitude restrictions (below).‬

Youtube Video

El Reg ran the app security aspects of this by security consultant Ken Munro, who told us it looks like DJI failed to follow industry best practice.

“It’s a bit silly to leave debug code in production apps,” Munro said. “Particularly so because DJI were informed of this and could easily have pushed a new app version with the offending code removed. Note they released Assistant 2 v1.1.2 on June 16. I’m not clear if it’s this version that has the problem, or if they’ve just fixed it.”

DJI told The Register that it had issued software updates in response to reports of unauthorised firmware modifications.

A recent firmware update for Phantom 4 Pro, Phantom 4 Advanced, Phantom 3 Standard, Phantom 3 SE, Mavic Pro, Spark, and Inspire 2, among others, fixes reported issues and ensures DJI’s products continue to provide information and features supporting safe flight. DJI will continue to investigate additional reports of unauthorised firmware modifications and issue software updates to address them without further announcement.

Victor Wang, DJI Technology security director, reiterated that DJI’s geofencing features (which provide “no-fly zone” data) are designed specifically to provide information to DJI customers about airspace where drone flight raises serious safety or security concerns. He also said that DJI continually monitors modifications to its drones that might make their operations “non-compliant with best safety practices”.

“Modifying the firmware of a DJI drone is not recommended, as it can cause unstable flight behaviour that could make operating the drone unsafe. DJI is not responsible for the performance of a modified drone and we strongly condemn any user who attempts to modify their drone for illegal or unsafe use.”

Users authorised to fly in restricted areas can either unlock these zones using DJI’s GEO system or by submitting a request to the company by email. DJI added that it offers a software development kit (SDK) for creating customised software using its platforms.

Finisterre, whose previous exploits include extracting DJI’s NFZ database from an application, was unimpressed with the drone maker’s latest statement. “The bugs that I disclosed that were circulating in the underground have NOT been fixed for what it is worth,” he told The Reg.

The drone security expert went on to criticise DJI’s procedures for allowing authorised parties to remove restrictions, saying that they have proved ineffective. Unable to successfully apply to remove restrictions, a growing body of enthusiasts have resorted to hacking the software on their UAVs, it seems.

Finisterre added: “You’ll find plenty of users that claim they are unable to unlock… I live in an NFZ, for example, and have permission, the app built-in functionality never ever worked for me, either the phone call, or credit card unlock.” ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/07/11/dji_drones_app_sec/

A row over data security is gripping India, with Reliance telco brand Jio denying claims it has leaked the details of 120 million customers.

The FoneArena blog was first to spot data purporting to be LTE-only network Jio customer information on the now-suspended magicapk.com.

While FoneArena asserts the information was genuine, Jio told The Register what it also told other outlets – that it’s not.

Here’s the company’s statement in full:

We have come across the unverified and unsubstantiated claims of the website and are investigating it. Prima facie, the data appears to be unauthentic. We want to assure our subscribers that their data is safe and maintained with highest security. Data is only shared with authorities as per their requirement. We have informed law enforcement agencies about the claims of the website and will follow through to ensure strict action is taken.

The magicapk.com site (on one Indian-hosted IP address and one US-hosted IP according to Robtex) only landed in the Archive.org Wayback index on July 9. What was captured then seems to offer a phone-number-to-SIM lookup:

The now-disabled magicapk.com

The Register can’t verify whether this was genuine, but notes that the site is specific to Jio numbers.

FoneArena’s editor Varun Krish reckons the leak was genuine, telling the New Indian Express his own personal details, and those of some of his staff, were present if they searched their own Jio numbers.

Jio has reported the allegations to CERT-In and Navi Mumbai Police, and India’s Economic Times (not linked, because you don’t need that many ads – El Reg) quoted consultancy Ernst and Young as attributing the breach to an unnamed third party. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/07/11/indian_telco_reliance_jio_denies_alleged_customer_data_breach/

Acquisition fills gap in Symantec’s Apple iOS mobile security strategy – and addresses the future of ‘mobile first,’ Symantec CEO says.

Symantec today announced its second acquisition in less than a week, with plans to purchase mobile security vendor Skycure.

The move comes on the heels of the security giant’s announcement last week that it will buy browser isolation technology firm Fireglass. Symantec has made it clear that it plans to invest in emerging technologies in order to expand its endpoint security architecture: in March, the company formed the Symantec Ventures cybersecurity venture capital arm, an incubator for new startups that also will give Symantec access to potential acquisition prospects.

With Skycure, Symantec gets a full suite of Apple iOS mobile security offerings as well as a machine-learning based reputation engine for spotting unknown mobile threats.

“Skycure brings a set of capabilities that help bolster our current” offerings, Greg Clark, CEO of Symantec said in an exclusive interview with Dark Reading. “Now we can take care of your users on all platforms … We’ve got a good product on Android, but this product becomes much better [now] and Skycure’s iOS is great, immediate closure to the gap around iOS” mobile security, he says.

Symantec will incorporate Skycure’s products and technology into its Integrated Cyber Defense Platform, as well as its Symantec Enterprise Protection Cloud and Norton Mobile product families. 

Clark says the key to enterprise endpoint security is to protect all devices that users bring to the office. The workforce of the future will be all-mobile, he says, and that requires organizations to have strong mobile security to protect their data in this “mobile-first” future.

“History has proven that even when you have closed OSes like iOS, you still have substantial security vulnerabilities,” Clark notes.

With the purchase of Skycure, Symantec also hopes to partner with telecommunications companies looking to provide mobile security to their end users: “We see big outreach from the telecom sector” here, Clark says.

Symantec is no stranger to Skycure: the two vendors have multiple joint customer relationships, according to Clark. The acquisition won’t eliminate any positions at Skycure, either, he notes. “We’re bringing over the entire [Skycure] team,” he says.

Symantec did not disclose financial details of the deal.

Black Hat USA returns to the fabulous Mandalay Bay in Las Vegas, Nevada, July 22-27, 2017. Click for information on the conference schedule and to register.

 Related Content:

• Black Hat Survey: Security Pros Expect Major Breaches in Next Two Years
• Symantec to Buy LifeLock at $2.3 Billion
• 9 Ways to Protect Your Cloud Environment from Ransomware
• How To (And Not To) Make the Online Trust Honor Roll

 

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise … View Full Bio

Article source: https://www.darkreading.com/mobile/symantec-snaps-up-skycure-in-mobile-security-move/d/d-id/1329322?_mc=RSS_DR_EDT

HPE NonStop users running Samba need to get busy applying workarounds to a pair of remotely exploitable vulnerabilities.

The first, SambaCry, has been present in Samba since 2010 but was named and outed in late May 2017. Assigned CVE-2017-7494, it allowed a malicious Samba client with write access could execute code as root.

F5 Networks explained that all the attacker need do is upload a shared library to a writable share, because the server will execute it with the privileges of the Samba daemon.

In June, SecureList spotted the vulnerability in the wild, being exploited to mine the Monero cryptocurrency.

The second, CVE-2017-2619, is a symlink race condition that lets a remote attacker bypass access restrictions and access files outside their share.

As the Samba maintainers explain: “Samba uses the realpath() system call to ensure when a client requests access to a pathname that it is under the exported share path on the server file system.”

If an attacker renames the realpath() checked path and create a symlink, the race condition can let the client point a new symlink to “anywhere on the server file system”.

HPE hasn’t shipped a patch yet, but described its workarounds here, and on Monday filed a Security Bulletin on BugTraq.

The various vulnerability notes that have surfaced since May flesh out what was originally a much less detailed description. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/07/11/hpe_stops_nonstop_server_samba_bugs/

Open source devops platform Cloud Foundry has disclosed a potentially nasty bug in its User Account and Authentication server software.

UUA is the Cloud Foundry ID management service, using OAuth2 to issue tokens for client applications that act on behalf of users.

CVE-2017-8032 was patched in an update last week, and the detailed advisory landed June 12 here.

The short version: “Zone administrators are allowed to escalate their privileges when mapping permissions for an external provider.”

The vulnerability note doesn’t detail the extent of the elevated privileges, but the organisation rates it as high-severity.

The issue affects nine versions of UAA and cf-release versions prior to v264.

Fortunately, the vulnerability depends on a number of requirements, as Cloud Foundry explains:

Revising any of these settings serves as a mitigation ahead of implementing a patch, Cloud Foundry says.

The disclosure provides upgrade links for both Cloud Foundry users (upgrade to version 264 or later) and standalone UAA users (UAA 2.x.x users have to move to fixed versions in the 3.x.x series). ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/07/11/cloud_foundry_had_a_privilege_escalation_bug/

Insurers whose policies could give rise to claims for damage as a result of cyber attacks may have to adjust their policies or premiums to better reflect these risks, the Prudential Regulation Authority (PRA) has warned.

Firms should also carry out regular ‘stress tests’ to ensure that they are properly resourced to respond to a large number of claims at one time in the event of a major global cyber attack, according to the regulator.

The PRA has set out its expectations of insurers that underwrite cyber-related losses, whether as a result of cyber attacks or of accidental or non-malicious acts, such as loss of data. It has published a supervisory statement on the topic, which it has now finalised following a consultation exercise last year.

Dedicated cyber insurance is currently offered by only a limited number of UK insurers. However, a recent report by PwC estimated that the global cyber market would double to $5 billion in annual premiums by 2018 and treble to at least $7.5 billion by 2020. In March, the UK’s Institute of Directors warned that a “worrying” number of UK businesses had no plan in place to respond to a cyber attack, with just 56% of respondents to a survey confirming that they had a formal cybersecurity strategy in place.

In its supervisory statement, the PRA said that it expected insurers to be able to “identify, quantify and manage” their exposure to cyber security risk. This should include their explicit, ‘affirmative’ exposure through dedicated cyber insurance policies; and their implicit, ‘non-affirmative’ or ‘silent’ exposure, through property and casualty policies that do not explicitly include or exclude coverage for cyber risk.

Insurers should take particular care in relation to this ‘silent’ exposure, and “introduce measures that reduce the unintended exposure to this risk”, the PRA said. These measures could include adjusting the premium to reflect cyber risks and offering explicit cover; introducing “robust” exclusions; or attaching specific limits of cover, it said. Insurers should also make “adequate capital provisions that clearly link with this risk”, in the same way as they would for any other risk type, the PRA said.

Insurers could choose to extend specific products or lines of business to include cyber cover at no extra premium, the PRA said. However, before making this decision, the insurer’s board would be expected to carry out a “comprehensive assessment of the potential resulting losses” to ensure that the insurer’s exposure to cyber risk fell within its stated risk appetite, the PRA said.

“The short-to-medium term aim is to enhance the ability of firms to monitor, manage and mitigate non-affirmative cyber risk and to increase contract certainty for policyholders as to the level and type of coverage they hold,” the PRA said in the statement.

“The PRA expects firms to adopt a proportionate approach when assessing their non-affirmative exposures. The firm’s underwriting and risk management functions should play a key role in leading this effort,” it said.

Elsewhere in the statement, the PRA said that it expected firms underwriting cyber risk to have “clear strategies” on the management of these risks, owned and reviewed on a periodic basis by the board. Firms should also ensure that their knowledge and understanding of cyber insurance and associated risk was “fully aligned to the level of risk and any growth targets in this field”, it said.

Copyright © 2016, Out-Law.com

Out-Law.com is part of international law firm Pinsent Masons.

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/07/11/pra_insurers_may_have_to_adjust_policies_to_reflect_silent_cyber_risks/

A blunder during a handover of the .io registry allowed a security researcher to potentially take control of more than 270,000 .io domains.

Late Friday, Matthew Bryant noticed an unusual response to some test code he was using to map top-level domains: several of the .io authoritative name servers were available to register.

Out of interest, he tried to buy them and was amazed to find the registration went through – leaving him potentially in control of hundreds of thousands of websites.

These crucial name servers – specifically, a0.nic.io, b0.nic.io, c0.nic.io, ns-a1.io, ns-a2.io, ns-a3.io, and ns-a4.io – are like the telephone directories of the .io space. If your web browser wants to connect to, say, github.io, it may have to go out to one of these authoritative name servers to convert github.io into a public IP address to connect to.

Those nic.io and ns-aX.io addresses should be owned and maintained by .io’s operators. But Bryant was able to purchase and register ns-a1.io, ns-a2.io, ns-a3.io, and ns-a4.io, and point them at his own DNS servers, allowing him to, if he wanted, potentially redirect connections to any .io domain to a server of his choosing.

He immediately tried to contact the operators of the .io registry, but its official administration email bounced and he ended up calling the registry’s support line to report his control over their top-level domain. They asked him to send an email to their abuse@ email address.

Despite firing off an email immediately, Bryant remained in control of ns‑a1.io, ns‑a2.io, ns‑a3.io and ns‑a4.io for about 24 hours – during which time he could have potentially directed hundreds of thousands of requests for .io websites to his own servers – until the registry finally acted and revoked his registration of the domains.

Bryant told The Register via email that the registry has yet to contact him or inquire what he did with the vast number of DNS queries for .io websites his domains handled. He told us he deleted the logs and forced the name servers he was in control of not to respond.

The potential for criminal activity such as redirecting people to phishing websites or installing malware on people’s systems was enormous. And it is unclear that the hijacking would have been noticed if he hadn’t reported it.

As such, the slip-up will be a significant embarrassment to the .io registry, which promotes itself as a home for startups and internet companies and boasts 272,000 active addresses.

How this works

Every top-level domain – like dot‑com – lists a number of name servers that the rest of the internet uses to query and find out on what server specific websites exist. It’s a registry’s address book and is critical to the functioning of the domain name system.

The .io registry lists seven such name servers – and Bryant managed to take control of four of them for $95.99 apiece.

Even more extraordinarily, the name servers had likely been available to register for several weeks: .io was lucky that the first person to discover the fact was an internet security researcher rather than a hacker or cybercriminal.

It’s worth pointing out that owning four of the seven authoritative name servers doesn’t grant full control over .io. These name servers are often selected at random to spread the load, meaning some look-ups would have gone to the .io operator and some to Bryant. For example, we just queried github.io from the B root server and was offered ns-a4.io as the authority on github.io:

dig github.io @b.root-servers.net

;; AUTHORITY SECTION:
io.                     172800  IN      NS      ns-a4.io.
io.                     172800  IN      NS      c0.nic.io.
io.                     172800  IN      NS      ns-a1.io.
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      ns-a3.io.
io.                     172800  IN      NS      b0.nic.io.
io.                     172800  IN      NS      ns-a2.io.

Also, it’s doubly worth pointing out that DNS lookups are often cached, so the chances that a lookup will go all the way to the authoritative servers, and hit one of the hijacked ones, is low. And software tends to go straight to a domain’s A record, bypassing the authoritative name servers, thus limiting the damage of hijacked systems.

Still, it’s a rather embarrassing blunder. Bryant told us he received “gigabytes” in DNS queries from clients.

So what happened? At the root of the problem was a transition last month of the top-level domain from the operators of the registry, .IO TLD, to third party Afilias, which runs the backend for over 25 other top-level domains, including .org, .info and .eco.

Somewhat unusually, .IO TLD decided it wanted to continue to run the .IO name servers, but outsourced the rest of the registry operations to Afilias. Afilias locked down the three main name server addresses – A0.nic.io, B0.nic.io and C0.nic.io – but failed to do the same for the other four, leaving them available for registration.

“Ordinarily, when a TLD transitions to the Afilias system, 100 per cent of the DNS is also moved to Afilias nameservers,” the company told The Register in a statement.

“Last week, Afilias discovered that some of the nameservers associated with the .IO TLD were not blocked when the TLD was transitioned to Afilias’ systems in June … Upon discovery, Afilias promptly reassigned and blocked the domains associated with ICBs nameservers, and the DNS for .IO is now working as expected.”

As Bryant noted in a blog post, the fact that .io has DNSSEC enabled would probably have limited the worst dangers in having a malicious actor in charge of a piece of the core internet infrastructure. But the security risks were enormous nonetheless.

Afilias told The Reg that its transition procedures had been updated and that it was “unaware of any issues arising from this brief exposure.” ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/07/10/io_hijacking_in_transition_cockup/

A software developer says a thief siphoned cash from his PayPal account – after a dumbass ATT rep handed control of his cellphone account to a hacker, thus defeating his two-factor authentication.

Justin Williams, an iOS code jockey based in Denver, Colorado, said someone was able to dupe an ATT support tech into assigning his account to a new SIM card and phone – despite the miscreant not knowing the security code connected to the account. In other words, the criminal was able to persuade the US cell network’s rep into making substantial changes to his account without the code, we’re told.

Williams said the breach occurred last Thursday, when the hacker made multiple calls to ATT support asking to transfer his account to a new phone. Initially, Williams said, ATT staffers blocked the attempts when the caller could not give the phone account’s correct passcode.

Eventually, however, someone at ATT relented and, breaking protocol, agreed to reassign the phone to the new SIM card, it is claimed. At that point, the attacker was able to receive text messages to Williams’ number on the new phone.

This allowed the attacker to go to PayPal and use the service’s two-factor authentication (which sends a one-time code via SMS) to reset the password on his account and take control of that. By Thursday evening, Williams tells it, he became aware of what was going on:

“I restarted the phone. No help. Reset network settings in iOS Settings. Still no success. I checked my iPad because I carry it with me and keep a SIM in it. The iPad still has service, which seemed interesting. At this point I was still blaming iOS 11 because I’m a software developer and we always blame the software.”

‘Someone has been dialing the ATT call center all day’

By now, the hacker had already used their access to the PayPal account to begin siphoning money. A $200 AUD payment had been made that showed up on Williams’ bank account and alerted him to what was going on.

“I instantly called ATT’s customer service line to explain what is happening. I give them my name, my phone number, and my security passcode (this is key),” Williams explains.

“The man on the phone reads through the notes and explains that yes, someone has been dialing the ATT call center all day trying to get into my phone but was repeatedly rejected because they didn’t know my passcode, until someone broke protocol and didn’t require the passcode.”

The developer said he was able to get ATT to deactivate the phone that evening and he has since gotten a new SIM card. He has also put in a payment dispute with PayPal to get that transaction overturned, but admits he is “not optimistic because PayPal is terrible.”

The lesson, says Williams, is that even with two-factor authentication enabled, accounts can still be hijacked when one link of the chain (in this case ATT’s account recovery) is broken. He says he is keeping a close eye on his bank account and credit cards.

ATT declined to comment.

While SMS two-factor authentication is extremely handy, and blocks the vast majority of account takeovers, it is not infallible – to social engineering and SS7 attacks. Time and time again, we’ve heard of crooks tricking wireless support staff into handing over control of devices. If you can, now’s the time to consider a hardware token or app-based two-factor authentication method.

Please, feel free to post your recommendations in the comments. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/07/10/att_falls_for_hacker_tricks/