STE WILLIAMS

Apple has shut off Group FaceTime while it prepares a fix for a newly found security flaw found by a 14-year-old gamer.

The glaring security flaw in FaceTime that has rocked the Apple community since it went viral late yesterday was actually was first found on January 19 by a 14-year-old who stumbled upon it while setting up a group chat with friends playing Fortnite. 

Apple disabled the Group FaceTime service yesterday, January 28, at 10:16 p.m. PDT, after word of the bug and a video of how to abuse it spread like wildfire over social media and caught the attention of security experts. And the company — which late yesterday said it will issue a patch for the bug this week — was a little late to the party: Michele Thompson, the mother of the teenage gamer, Grant, who found the flaw, told media that she attempted to contact Apple about the bug but got nowhere. She even tweeted about it on January 20 after not getting a response from Apple Support:

My teen found a major security flaw in Apple’s new iOS. He can listen in to your iPhone/iPad without your approval. I have video. Submitted bug report to @AppleSupport…waiting to hear back to provide details. Scary stuff! #apple #bugreport @foxnews

The vulnerability allows a Group FaceTime caller to access your audio and video even if you don’t pick up the call. Grant found that after trying to call one friend via FaceTime who didn’t pick up and then adding a second friend to the call, he was able to hear the microphone of his first friend, even though the boy hadn’t picked up. He could hear the ringing sound on the first friend’s phone, he told NBC News.

Aside from an obvious failure of communication in Apple’s process for vulnerability reporting, the painfully simple bug also exposes a likely collapse in the final vetting phase of the vendor’s software development life cycle. With a company like Apple, known for advanced privacy and security features in its software and hardware architecture, the bug demonstrates how even the best development programs can miss security problems.

Chris Eng, vice president of research at Veracode, says the Group FaceTime vulnerability appears to be a design flaw that should have been detected during Apple’s threat modeling process, a step-by-step exercise where developers explore potential use and abuse cases in an application. The development team walks through a final flight-check of sorts, exploring usage possibilities such as: What if the user adds another contact’s number to the Group call? What if the user adds his own number?

“It seems like an obvious scenario you’d expect them to go through in workflow in handling [potential] abuse, or they didn’t account for that particular case,” Eng says. “It seems straightforward enough that a light whiteboard review of this thing” even would have caught it, he says.

This design flaw isn’t a deep architectural issue in Group FaceTime, Eng notes, but, rather, the result of a flawed new feature that wasn’t fully vetted for problems like this one. “I wonder if they were under time pressure, or they wanted to squeeze it into a release,” he says.

Apple had not yet responded as of this posting to a request for details on the flaw and what happened with the Thompsons’ reporting of it.

The good news about the bug, according to Eng, is that it appears to have a limited impact on FaceTime users. “It’s a bad bug, no question, but it’s not like you have an unlimited spying tool,” he says, given that the early tests show it provided a short window of audio and video access.

“Hopefully, they’ll [Apple] go back and do a root-cause analysis” to determine where the threat modeling fell apart for the flawed feature, he says.

Apple’s development process for the FaceTime code appears to have missed the mark, notes Chris Pierson, CEO of security firm BlackCloak. “Errors and problems in coding and implementation happen all the time in the software process. That is why static and dynamic security testing is critical as well as a robust QA [quality and assurance] process,” he says.

Pierson echoes Eng’s theory that there was likely an oversight in testing out any issues with the app before launching it. “In this case, it looks like the QA process failed to identify this risk in its preliminary or regression testing models. It could be a failure in the process itself, or a failure in imagination to test something like these steps. In any case, an enormous oversight,” Pierson says.

The Fix
While architectural design flaws in software are difficult to remedy, this type of feature flaw is not. “I don’t think this hard to fix,” Eng notes. Apple may have to remove the ability to add a user’s phone number to the Group FaceTime call, for example, he says.

“This doesn’t [appear to] affect the whole FaceTime architecture and product. I think it’s one use case where they didn’t think about how it was going to handle this particular group-calling feature,” Eng says.

It’s a chilling reminder that even major companies with mature secure development programs can miss things. “Even though Apple has gone through great strides to protect their users’ information, this latest bug is yet another reinforcement that privacy continues to remain a major concern regardless of your company’s size or security and privacy investments,” notes George Gerchow, CSO at SumoLogic. “It’s also another reminder that nobody’s data is 100% safe and that it’s all of our responsibility to be more diligent in protecting the privacy of our customers’ sensitive information against future vulnerabilities.”

Related Content:

• Turn Off FaceTime in Apple iOS Now, Experts Warn
• 7 Privacy Mistakes That Keep Security Pros on Their Toes
• Bug Bounty Awards Climb as Software Security Improves

 

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/vulnerabilities---threats/facetime-bug-an-appsec-fail/d/d-id/1333753?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Anyone with access to an Exchange mailbox can take control of domain, security researcher says.

Microsoft Exchange 2013 and newer versions are vulnerable to a privilege escalation attack that gives anyone with a mailbox a way to gain domain administrator rights at potentially 90% of organizations running Active Directory and Exchange, according to a security researcher.

The attack is possible because of the extensive privileges available by default in Exchange and therefore cannot be patched against, security researcher Dirk-jan Mollema of Netherlands-based Fox-IT wrote in a blog post describing the new exploit. Mollema also released a proof-of-concept tool dubbed “PrivExchange” demonstrating how the attack works.

Organizations can protect against the attack by removing privileges that Exchange has on the Domain object, by disabling certain features on it, enabling strong authentication and other mitigations, Mollema wrote.

“This is something for people to be afraid of,” says Will Dormann, senior vulnerability analyst at the CERT Division of the Software Engineering Institute at Carnegie Mellon University, which issued an advisory on the threat Monday.

“If you are a company that has 1,000 computers, all that the attacker needs to do is gain control of one that gives access to an Exchange mailbox,” he says.

An attacker with a foothold on a Windows network can use the publicly availability exploit to gain domain administration rights, he warns. “The domain controller is the key to the whole kingdom,” Dormann says. “Somebody that gains access to the domain controller owns the entire network.” 

The CERT advisory identified the problem as having to do with the failure of Microsoft Exchange 2013 and newer versions to set so-called signing and sealing flags on NTLM authentication traffic. This failure can allow a remote attacker to gain the privileges of the Exchange server, the advisory noted.

To pull off the attack, an adversary would take advantage of a function in the Exchange Web Services API called PushSubscriptionRequest in such a way as to cause the Exchange server to connect to an arbitrary attacker website over HTTP. “Connections made using the PushSubscriptionRequest function will attempt to negotiate with the arbitrary web server using NTLM authentication,” the CERT advisory said.

But because the authentication attempt over HTTP is not signed, it is vulnerable to what are known as NTLM relay attacks. With NTLM relay attacks, an adversary sits in the middle of an authentication session between a client and server, hijacks the session, grabs the authentication credentials, and uses it to access a different service.

With Mollema’s exploit, “what the attacker is doing basically is triggering the Exchange Server to authenticate with an attacker system and then relay that authentication back to the Domain Controller,” Dormann says.

The vulnerability does not affect Exchange 2010 because that version used NTLM signing. So it isn’t possible for an attacker to relay authentication credentials, as is possible with Exchange 2013 and later, he notes. “It appears, in my opinion, that this is a regression if you have an older version that is not affected by the attack but newer versions are.”

In a blog post, Mollema described his attack as combining previously known vulnerabilities and known protocol weaknesses. The attack leverages the fact that Exchange Servers have high privileges by default; that NTLM is vulnerable to relay attacks; and that Exchange has a feature that can be exploited to make it authenticate to an attacker with the account of the Exchange server, Mollema noted.

The attack takes advantage of a method that Trend Micro’s Zero Day Initiative (ZDI) described last December for getting Exchange to authenticate with an attacker system using NTLM over HTTP.

Brian Gorenc, director of vulnerability research at Trend Micro and lead of the Zero Day Initiative, says the December blog post described how the Exchange bug could be combined with an NTLM relay attack to escalate privileges.

“The exploitation process involved adding an inbound rule to the victim mailbox that forwards inbound mails to the attacker,” he says. “Exchange Server has become a central component of our business life.”

Microsoft has provided detailed instructions on how to mitigate the privilege escalation issue and organizations should follow them, Gorenc says.

Organizations should remove any privileges that Exchange has on the domain object, says Dormann. Or they can disable the PushSubscriptionRequest feature to mitigate the threat, he says.

Mollema listed several recommendations as well including enabling LDAP signing and blocking Exchange servers from making connections to workstations on arbitrary ports.

Related Content:

• Simulating Lateral Attacks Through Email
• Exploring, Exploiting Active Directory Admin Flaws
• Controlling Privileged Access To Prevent Rogue Users In Active Directory
• Credential Compromises By the Numbers 

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/microsoft-exchange-vuln-enables-attackers-to-gain-domain-admin-privileges/d/d-id/1333758?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

A US court has nixed Yahoo!‘s attempt to settle a class-action lawsuit over the 2013 megahack, saying it’s fatally flawed.

Judge Lucy Koh of the California Northern District in San Jose ruled [PDF] that a settlement proposed in October of 2018 was not acceptable, particularly in regards to the share of attorney fees and the opaque nature of the proposed payout for victims.

Koh pointed out that the settlement appears to earmark a whopping $35m in payments for attorney fees that include a number of law firms and attorneys who weren’t even authorized to work on the case.

“By the Court’s count, Plaintiffs’ lodestar [fee calculation] covers 143 attorneys from 32 firms,” Koh noted.

“This Court only authorized five law firms to work on the instant MDL case. On February 1, 2018, the Court ordered “[o]ther that the Plaintiffs’ Executive Committee, no other law firms shall work on this MDL without prior approval of the Court.”

Additionally, the deal calls for the fees to be held separate from the fund, meaning any unclaimed cash would be handed back to Yahoo! instead of the customers. This, again, reeks of a deal that has the interests of Yahoo! and the lawyers in mind, rather than the actual plaintiffs.

Oath-my-God: THREE! BILLION! Yahoo! accounts! hacked! in! 2013! – not! ‘just!’ 1bn!

READ MORE

To really rub it in, the settlement would have prevented others from being able to continue the suit based on separate but related claims about prior data breaches, even if Yahoo! paid off the individuals named in the lawsuit.

Among the holes the Judge shot in the proposed deal was a lack of accounting for exactly how much money would go into the settlement and how the various costs were adding up. She notes that no total figure was presented for the settlement, and that the deal doesn’t explain how the costs for credit monitoring service, administration of the settlement payouts, or service of notices would be calculated. Without that information, Koh says, it is impossible to decide if the customers are getting a fair deal.

Judge Koh summarised an expert report into Yahoo!‘s security practices, commissioned by the claimants, as saying:

The report shows repeated failures to follow industry-standard security practices, extensive knowledge of ongoing security breaches beginning in 2008 with failure to adequately respond, failure to provide adequate staffing and training, and failure to comply with industry standard regulations.

The expert, Mary Frantz, also reportedly found “several incidents prior to 2013” that “involved several million accounts”.

“The proposed notice does not disclose the costs of credit monitoring services or costs for class notice and settlement administration, and does not disclose the total size of the settlement fund. Without knowing the total size of the settlement fund, class members cannot assess the reasonableness of the settlement,” wrote the judge in her ruling. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/01/29/yahoo_megahack_class_action_payoff_attempt_nixed/

A US judge has given the go-ahead for a set of consolidated lawsuits against credit agency Equifax regarding its 2017 mega-hack.

In a series of orders handed down in a Georgia federal district court on Monday, the evocatively named Judge Thomas Thrash Jr said that legal challenges from payment card issuers and ordinary citizens can proceed against Equifax. A class-action lawsuit brought by ten “small businesses” – which included corporations and limited liability companies – was denied, though. The small biz owners can join in with the consumers.

In effect, payment card issuers are going ahead as one set of lawsuits, and normal folk are bunched into another set, against Equifax. The credit agency had sought to dismiss the claims against it.

The lawsuits were all filed after the credit reference agency admitted in 2017 that some 148 million personal records – including a mix of names, social security numbers, taxpayer ID numbers, and credit card numbers and expiry dates – were stolen by database hackers.

In court documents, Thrash highlighted the “unprecedented” scale of the breach, the fact Equifax is responsible for information on more than 820 million individuals and 91 million businesses, and that it had bragged about its security credentials while having demonstrably poor basic maintenance techniques.

The small businesses claimed they had been harmed due to their owners’ personal data (rather than that of the businesses) being compromised, arguing that this “jeopardized” the creditworthiness of the owners and thus the firms. But the judge said they failed to show injury other than to the owners as individuals, that the alleged injuries “are too speculative,” and that a chain of events would need to occur for the small businesses to suffer actual damage.

Card floggers and consumers good to go

The financial institutions said that the data breach caused them harm because it impacted both their organisations and the mechanisms they use to authenticate customers. They argued they have spent extra time and money in the aftermath of the hack: responding to the compromise of the credit reporting system, and the leak of personal information they rely on for their business; on assessing the impact of the breach; and on mitigating what they say is a substantial risk of future fraudulent activity.

Equifax how-it-was-mega-hacked damning dossier lands, in all of its infuriating glory

READ MORE

Some 23 financial houses also alleged they had issued payment cards that were compromised in the breach, and had spent time and money reissuing these payment cards and reimbursing customers.

The judge ruled that the card issuers can go ahead with their case on the grounds that the banks have incurred concrete costs as a result of the breach and in refunding fraudulent charges. But other financial associations cannot proceed, because they have alleged only “generic and abstract” injuries.

The consumer group, made up of 96 people and seeking to represent more, said they were suffering a “present, immediate, imminent, and continuing increased risk of harm” after their personal information was exposed.

The court ruled that Equifax did owe those plaintiffs a duty of care to safeguard personal information, and that the plaintiffs’ argument that the the biz knew of “severe deficiencies” in their systems but didn’t act was sufficient to allege bad faith on the part of Equifax. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2019/01/29/equifax_lawsuits_approved/

Today’s releases include more advanced EDR tools, a new managed EDR service, and protection and hardening for Symantec’s endpoint portfolio.

Symantec is ramping up its endpoint defense offerings with myriad updates to its endpoint security portfolio and a new Managed Endpoint Detection and Response (MEDR) service that leverages its new EDR 4.0 to improve on incident response, threat hunting, and forensics.

MEDR is made up of Symantec EDR 4.0, the SOC technology platform, and the Global Intelligence Network. Its capabilities, which include industry- and region-specific analysts across six global SOCs and managed threat hunting, are intended to help decrease the burden on security teams as endpoint threats grow in size, number, and complexity. EDR 4.0 pulls threat research from Symantec’s telemetry to detect new attack patterns and zero-day threats.

“With a critical shortage of skilled investigators available, security teams need smart tools and services that can help them deal with the scale and speed of the modern threat environment, making it easier to identify and fix impacted endpoints,” said ESG senior principal analyst Jon Oltsik, in a statement on today’s releases.

Both Symantec MEDR and EDR 4.0 are now available on any device before or after an attack, for detection and response. Also available today are multiple endpoint security updates to its Integrated Cyber Defense Platform, which address application, cloud, and Active Directory.

Security portfolio updates include endpoint application control, which only allows known and good applications to run; endpoint application isolation, which ensures applications are limited to authorized behavior; endpoint cloud connect defense, which uses a policy-based smart VPN to defend against risky networks; and endpoint threat defense for Active Directory, which helps ensure attackers on domain-connected endpoints can’t exploit AD to view critical assets.

Read more details here and here.

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

Article source: https://www.darkreading.com/endpoint/symantec-rolls-out-new-endpoint-security-tools-updates/d/d-id/1333750?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Where security really matters, the enterprise is only as secure as the endpoints it allows to access its sensitive core systems.

Long gone are the days of the physical perimeter, where a company’s IT infrastructure was entirely on-site. Today’s increasingly decentralized enterprises depend on a workforce that operates both at home and on mobile devices, working together with the help of cloud-based services. Yet the death of the traditional perimeter does not mean the end of security architecture. Instead, we need to recognize that it is all about trust.

As little as a decade ago, most organizations assumed that their security protection was robust, and few had deployed security operations centers or other cyber monitoring solutions. The concept of “zero trust” was a useful spur to action: work on the assumption that any of your resources might be compromised and put monitoring solutions in place so that you can take remedial action if you find something is amiss.

But when designing underlying cyber protections, too many architects are taking zero trust to be the primary objective. This is a misinterpretation. In the first instance, we should look to protect our resources from attack. What zero trust reminds us is that we are fallible, and that we should put in place backup plans in the form of monitoring and incident response for the (hopefully rare) cases where our protection plans fail.

Zero Trust at the Endpoint
Where we see this misinterpretation most frequently is in the context of the user endpoint, where many enterprises are making plans that can be summarized as “Don’t worry about the endpoint: We’ll just assume zero trust.” There are cases where this is a reasonable decision, made in the full understanding of the risk. But in too many cases, the risks are poorly understood.

In many ways, this is a legacy of decades of remote access solutions built around the traditional security perimeter. In the threat environment of years past, the critical risk for remote access was that an unauthorized individual would seek to connect to the remote access portal. The critical controls were passwords and two-factor authentication. But in the future threat landscape, this risk is joined by another: a legitimate user connects but the machine they are using to do so is not fully under their control.

This is not hypothetical. It is a risk that has played out in the real world, albeit in a different context — Internet banking. Here is a real-world case study where high-value systems are accessed from endpoints that have few, if any, controls, and which must indeed be treated as zero trust.

Man-in-the-Browser: A Cautionary Tale
In the early days of Internet banking, the risk was unauthorized access, and banks developed varying levels of protection ranging from passwords, of which only some characters are used for each logon, to two-factor authentication. But the more sophisticated attackers then turned to a far more pernicious mode of attack: man-in-the-browser.

With a man-in-the-browser attack, a user connects using his or her valid authentication methods. But the web browser has been compromised, and what the user subsequently sees is not what the website says, but rather what the attacker displays. What the website sees is not the user’s input, but the attacker’s input.

Even two-factor authentication (2FA) techniques can be subverted in a man-in-the-browser attack. We have seen real-world instances where users have entered their 2FA details to approve a valid transfer, but what is actually approved instead is a malicious transfer set up by the attacker.

Furthermore, 2FA works best when used sparingly. If 2FA is used too frequently, two things happen. First, users get frustrated and efficiency suffers. And second, users become too accustomed to entering their 2FA details and are more easily convinced to enter them by an attacker (such as the man-in-the-browser) — making it easier for an attacker to bypass the control.

Benefits Risks
Clearly, banks have decided to persist with Internet banking despite these risks; the business benefits are worth the risk. But despite heavy investments in cyber and fraud monitoring, there are significant losses suffered every year. The calculus is that (given transfer limits) any individual loss will be manageable and that the aggregate costs can be passed on to customers.

In other contexts, however, that calculus may be different. Individual cyber incidents that affect an enterprise’s core systems may have far higher impact than the loss of funds from any single bank account. In these cases, man-in-the-browser (or equivalent attacks) could be catastrophic — anything that the valid user can do, the attacker can, too.

Where this is the case, we must see zero trust as a backup in case of failure rather than the primary plan. In today’s enterprise architecture, user endpoints are probably the hardest elements to secure. But regardless of how frustrating it may be, where security really matters, the enterprise is only ever as secure as the endpoints it allows to access its sensitive core systems.

Related Content:

• 8 Attack Vectors Puncturing Cloud Environments
• The Security Perimeter Is Dead; Long Live the New Endpoint Perimeter
• 8 Tips for Monitoring Cloud Security
• Taming the Digital Wild West

Henry Harrison is co-founder and CTO at Garrison, and a seasoned IT industry executive, serial entrepreneur and the brain behind Garrison’s core technologies. Henry has a background in leading the development of innovation in cyber security and Garrison was founded to create … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/remote-access-and-the-diminishing-security-perimeter/a/d-id/1333715?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Video-sharing website Dailymotion is resetting the account passwords of an unknown number of users after being hit by a “large-scale” credential-stuffing attack.

As is often the case with password reset announcements, the technical detail of what happened and how many users were affected remains sketchy.

According to an email circulating on Twitter that was sent to some users, and a brief announcement on the company’s US website, Dailymotion’s security team detected the attack on user credentials on 19 January:

The attack consists in ‘guessing’ the passwords of some dailymotion accounts by automatically trying a large number of combinations, or by using passwords that have been previously stolen from web sites unrelated to dailymotion.

What marks the Dailymotion incident out as unusual is that more than a week later the company is still battling the same attack.

Underlining this, Dailymotion said it had informed the French information commissioner, CNIL (Commission nationale de l’informatique et des libertés), which implies that the attack might have had some success.

Repelling credential stuffing is not easy. Attackers use botnets to distribute the attacks across large numbers of computers that can be hard to distinguish from legitimate traffic and even harder to block.

It’s now a big enough headache that internet content delivery company Akamai recently estimated that between November 2017 and June 2018 its customers fielded 30 billion credential-stuffing attempts.

Where might the attackers be getting the credentials to stuff?

As the company says, the simplest explanation is that they get them from the sea of credentials stolen from other websites that float around on criminal forums.

On that front, Dailymotion suffered a major breach of its own in late 2016 in which a reported 85 million email addresses and usernames and 18 million passwords were stolen.

Superficially, it was good news that the company is believed to have protected the passwords using the secure Bcrypt hashing algorithm.

Except, of course, if the same password has been used elsewhere on a site not using the same level of security (or even exposed or phished in plaintext) that account will still be vulnerable.

The problem is password re-use – if users set strong unique passwords for each website they use, credential stuffing would no longer work.

Dailymotion isn’t alone. Earlier this month some Reddit users were asked to reset their passwords in response to what appears to have been a credential-stuffing attack. In September, the popular adblocker AdGuard also suffered a similar fate.

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

When people find unsecured Elasticsearch databases online, they often contain sensitive customer information.

Not so with UK-based DIY giant BQ, which reportedly suffered its own breach this week. Instead of customer data, an exposed Elasticsearch instance gave up information on around 70,000 shoplifters, according to Australian security researcher Lee Johnstone.

The exposed data included the names of thieves, along with the product codes of the things they had attempted to steal, the total price of the losses, and location data for the stores. Also included were detailed descriptions of people and their vehicles.

According to Johnstone’s report, the instance was operated by TradePoint, the arm of BQ that focuses on trade-only sales.

He said that it was operating an internal program to track incidents of theft across its stores, along with information about the offenders. The retailer stored all this information in an Elasticsearch database that was connected to the public internet, and without any form of authentication.

Johnstone reports on just one juicy record from the exposed database, reporting an offender that got away. It reads:

Offender ran out of the fire exit with nest thermostats. The male on this occasion got away. There is no CCTV footage covering this area. No CCTV coverage of the theft or witnesses.

There apparently wasn’t any identifying information about the retailer involved; the security researchers had to figure out the connection to BQ from the store geodata and the kinds of products that the light-fingered contractors had pilfered.

By his account, Johnstone made a solid effort to contact Tradepoint and BQ, but complains that it took too much time for the security team to take down the rogue database. He initially contacted them on 12 January 2018, but in spite of assurances that they were looking into the matter, the Elasticsearch instance only became inaccessible on 23 January 2018.

The BBC reports that BQ refutes some of the details in the incident, questioning the numbers of records involved. It also claimed other inaccuracies without detailing what they were.

All it takes is one violation with enough personal data to warrant interest from the UK Information Commissioner, though. Under GDPR, a data breach must be reported to the regulator with full details on what happened, within 72 hours.

Not the first insecure Elasticsearch

This isn’t the first insecure Elasticsearch instance to give up sensitive data and we’re sure it won’t be the last.

Voice over IP provider VOIPo.com served up nearly 15 million documents via an insecure server earlier this month, exposing sensitive internal credentials, while researchers found exposed records for over 100m bets processed by online gambling sites this month. Those records also included associated personal information on the customers involved.

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

Facebook plans to take all of its chat apps – Messenger, WhatsApp and Instagram – and smoosh them into one interconnected chat blob, in spite of having promised to retain the independence of WhatsApp and Instagram when it bought them.

The New York Times reported on Friday that the plans come directly from CEO Mark Zuckerberg. It cited four anonymous sources involved in the effort, which will reportedly entail keeping the three as standalone apps but stitching their technical infrastructure together so that users of each app can talk to each other more easily.

The plan also includes slathering the end-to-end encryption of WhatsApp – which keeps anyone, including Facebook itself, from reading the content of messages – onto Messenger and Instagram. At this point, Facebook Messenger supports end-to-end encryption in “secure connections” mode: a mode that’s off by default and has to be enabled for every chat. Instagram has no end-to-end encryption on its chats at all.

The move will tie together the world’s biggest message networks: the resulting chat blob will encompass more than 2.6 billion users.

The NYT’s sources said that the plan is in the early stages at this point and that Facebook’s goal is to wrap up the integration by early 2020. Tying together the apps will be involved: the reconfiguration will require thousands of Facebook employees to rework how the three apps function “at their most basic levels,” said the sources.

Zuckerberg’s goal is to keep people’s attention focused on Facebook. The more time they spend on the platform, the better for its advertising revenue, the sources said. As it is, WhatsApp sees heavy use in South America, while Facebook’s Marketplace – similar to the free Craigslist marketplace – is popular in Southeast Asia and other markets outside the US.

Zuckerberg reportedly hasn’t yet ironed out the details of how integrating the chat apps will be monetized, but last month, he told employees of WhatsApp and Instagram that the mandate will be a priority in 2019. The NYT’s sources said that multiple WhatsApp employees have already left, or plan to, in response to the mandate.

How will users’ privacy be affected?

WhatsApp users were understandably concerned when Facebook acquired the privacy-minded app in 2014. At the time, co-founder and then-CEO Jan Koum promised that respect for privacy was coded into WhatsApp’s DNA and that the Facebook deal would never have happened if it meant changing the company’s existing policy of collecting as little personal information about users as possible.

Much changed in the years since he said that. In August 2016, WhatsApp announced that it was going to start sharing users’ phone numbers and other personal information with Facebook, in spite of years of promises that it would never, ever do such a thing. In March 2018, Facebook signed a public commitment not to do so… yet… At least, not until it figured out how to do so without breaking the General Data Protection Regulation (GDPR).

The past few years have also seen Facebook’s growth and reputation get dinged by scandals over allowing election meddling and fake news on its platform, as well as playing fast and loose with users’ data.

Over the past year, #DeleteFacebook became an oft-heard cry from people whose trust in the platform hit rock-bottom, and that included some big names.

WhatsApp’s Koum and his co-founder, Brian Acton, bolted from Facebook in September. Acton said at the time that he realized that he’d sold his users’ privacy. The straw that broke the camel’s back: a disagreement over how to monetize WhatsApp, whose co-founders were known for despising ads. Instagram’s founders, Kevin Systrom and Mike Krieger, likewise left the company in September, over what many suspected was increased meddling from Zuckerberg.

WhatsApp now requires only a phone number when new users sign up. By contrast, Facebook and Facebook Messenger both ask users to provide their “true identities.” As the NYT suggests, the integration of the three chat apps could give pause to WhatsApp users if it means that their handles could be linked across all the apps, each with its disparate approach to how much personal data it demands.

Facebook responded to the news with this statement:

We want to build the best messaging experiences we can; and people want messaging to be fast, simple, reliable and private.

We’re working on making more of our messaging products end-to-end encrypted and considering ways to make it easier to reach friends and family across networks. As you would expect, there is a lot of discussion and debate as we begin the long process of figuring out all the details of how this will work.

Encryption everywhere vs. creeping Facebookism

Matthew Green, a cryptography professor at Johns Hopkins University, said that Facebook’s move could be good for security and privacy… or then again, given Facebook’s track record, maybe not so much:

Anyway, the summary is: this move could be potentially be good or bad for security/privacy. But given recent histor… twitter.com/i/web/status/1…

—
Matthew Green (@matthew_d_green) January 25, 2019

At first blush, it might seem like end-to-end encryption everywhere will be better for privacy, and that it will flummox law enforcement agencies that already spend gobs of time demanding backdoors into the encryption we already have.

But some privacy experts are saying that Facebook’s moves to tie our bits and pieces ever more tightly together will be a boon for those whose business it is to track us and our social ties. Sarah Jamie Lewis, executive director of the Canadian non-profit Open Privacy:

Facebook are going to monetize encrypted messaging by consolidating metadata analysis of 3 key platforms (Messenger… twitter.com/i/web/status/1…

—
Sarah Jamie Lewis (@SarahJamieLewis) January 25, 2019

Marc Rotenberg, president and executive director of the Electronic Privacy Information Center (EPIC), told the NYT that the change would be “a terrible outcome for internet users.” He urged the Federal Trade Commission (FTC) to “act now to protect privacy and to preserve competition.”

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/IOUdh4cN3-A/

Starting next month, the Japanese government is going to try its hand at credential stuffing the country’s Internet of Things (IoT), including gizmos at both the enterprise network level down to citizens’ “oops, never changed the default password!” webcams and everything in between.

Credential stuffing is when attackers grab login credentials that have been breached, then e-wander around plugging them into other places, trying to find out where else those same credentials have been used. Because a lot of users have the bad habit of reusing the same passwords across several websites, the tactic is successful far too often.

According to NHK, Japan’s national public broadcasting organization, the government approved of the first-of-its-kind venture on Friday.

The plan: in mid-February, staff at the National Institute of Information and Communications Technology (NICT) will generate user IDs and passwords and use them to try to break into a randomly selected batch of about 200 million IoT devices, such as routers and webcams.

Then, the owners of the breached devices will be told to bolster their cybersecurity.

The aim is to shrink the surface area available to attackers in the run-up to the Tokyo Olympics and Paralympics in 2020. That’s not a bad idea: after all, some systems went down around the time of the opening ceremony for the Winter Olympics in Pyeongchang, South Korea, last year.

We never did hear exactly what happened with the Winter Olympics 2018 incident, though some US intelligence operators reportedly blamed Russia, which, they said, tried to make it look like North Korea did it.

While the goal is to clean up for the Olympics, the collateral will be, hopefully, far greater security in general. The NICT has reported that IoT devices are at the heart of a large number – 54% – of the cyber attacks it detected in 2017.

Little devices add up to brawny botnets

IoT devices might seem like small potatoes, computing-wise, but they can be corralled into swarms that can do a lot of damage.

The FBI believes that Russia was behind a giant-sized IoT botnet known as VPNFilter that sprung up in May 2018. The bureau believes that VPNFilter was created by the Russian Fancy Bear group, also known as Sofacy Group or apt28, among other names.

At the time, more than 500,000 devices around the world were believed to have been infected with the malware, most of them consumer internet routers from a range of different vendors.

More recently, a Bay Area family was terrorized when their IoT Nest security camera got hijacked by an attacker who used it to broadcast a fake warning about three incoming intercontinental ballistic missiles (ICBM) launched from North Korea.

Unfortunately, just as it’s far too common for people to reuse passwords or fail to change their IoT devices’ default passwords, so too is it common, and easy as pie for researchers and creeps alike, to use a search engine like Shodan, which roams the web looking for the unsecured devices.

By wandering the internet to find vulnerable devices, the Japanese government isn’t doing anything particularly novel. It well might feel like Big Brother is prying into its citizens’ webcams or other IoT devices, because, well, it is. But it’s not doing anything that security researchers or ne’er-do-wells aren’t also doing.

How to keep everyone out of your IoT

Whether or not a government should take such things upon itself is a discussion worth having. But in the short term, the news should be a call to arms for us all, be we Japanese or citizens from any other nation, to lock down our devices.

After all, the NICT researchers could well stumble upon citizens’ webcam images or stored data, as pointed out by Institute of Information Security professor Harumichi Yuasa.

Yuasa said that if device owners’ identities are revealed in the survey, it would be a violation of their constitutional right to privacy. The institute says any data it finds will be kept private, and that the institute will ensure that no data is leaked.

There’s no reason to doubt those promises, but let’s face it, data leaks. Why take the chance? Nobody should wait until the NICT, or hackers, or security researchers, come knocking on their IoT devices. Instead, we should all think about taking these steps to lock them down:

• Learn how to secure a baby monitor or other IP cameras.
• Don’t reuse passwords. Instead, use unique, hard-to-guess passwords for every online service and site.
• If you can only remember one strong password, try a password manager.
• Use (2SV), also known as multiple- or two-factor authentication (MFA or multi-factor authentication (MFA) whenever possible. It ain’t perfect, but it ain’t too shabby, particularly if you can opt for the most secure option: a FIDO U2F (or the more recent FIDO2) hardware token such as the YubiKey.

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