Tech News - Cybersecurity

Yesterday, Mozilla announced that Firefox Nightly now supports encrypting the TLS Server Name Indication (SNI) extension. This prevents on-path observers from intercepting the TLS SNI extension and using it to determine which websites users are visiting. Why SNI is needed? SNI is required when multiple servers are sharing the same IP address. It is an extension to the TLS protocol using which clients are able to indicate which hostname they are attempting to connect to. This permits servers to present multiple certificates on the same IP address and TCP port number. To put this in simple words, SNI helps make large-scale TLS hosting work. How encrypted SNI (ESNI) works First, a public key is published by the server on a well-known DNS record, which is then fetched by the client before connecting. Next, the client replaces the SNI extension in the ClientHello with an encrypted SNI extension. The encrypted SNI is basically, the original SNI extension, but encrypted using a symmetric encryption key derived using the server’s public key. The server owns the private key and derives the symmetric encryption key as well. It can then decrypt the extension and therefore terminate the connection or forward it to a backend server). Since the encryption key can only be derived by the client and the server it is connecting to, encrypted SNI cannot be decrypted and accessed by third parties. How you can enable encrypted SNI (ESNI) Currently, ESNI is not supported for all the Firefox users. However, Firefox Nightly users can try out this feature by following these steps: First, ensure that you have DNS over HTPPS (DoH) enabled. To do that you can check out this article posted by Mozilla. Next, you need to set the network.security.esni.enabled preference in about:config to true. Head over to Mozilla Security Blog to read more about encrypted SNI. Is Mozilla the most progressive tech organization on the planet right now? Google Chrome, Mozilla Firefox, and others to disable TLS 1.0 and TLS 1.1 in favor of TLS 1.2 or later by 2020 Mozilla announces $3.5 million award for ‘Responsible Computer Science Challenge’ to encourage teaching ethical coding to CS graduates

An Amazon employee has spoken out against Amazon selling its facial recognition technology, named, Rekognition to the police departments across the world, over a letter. The news of Amazon selling its facial recognition technology to the police first came out in May this year. Earlier this week, Jeff Bezos spoke at the WIRED25 Summit regarding the use of technology to help the Department of Defense, "we are going to continue to support the DoD, and I think we should, The last thing we'd ever want to do is stop the progress of new technologies, If big tech companies are going to turn their back on US Department of Defense, this country is going to be in trouble”. Soon after a letter got published yesterday, on Medium, by an anonymous Amazon employee, whose identity was verified offline by the Medium editorial team. It read, “A couple weeks ago, my co-workers delivered a letter to this effect, signed by over 450 employees, to Jeff Bezos and other executives. We know Bezos is aware of these concerns... he acknowledged that big tech’s products might be misused, even exploited, by autocrats. But rather than meaningfully explain how Amazon will act to prevent the bad uses of its own technology, Bezos suggested we wait for society’s immune response”. The letter also laid out the employee’s demands to kick off Palantir, the software firm powering ICE’s deportation and tracking program, from Amazon Web Services along with the need to initiate employee oversight for ethical decisions within the company. It also clearly states that their concern is not regarding the harm that can be caused by some company in the future. Instead, it is about the fact that Amazon is “designing, marketing, and selling a system for mass surveillance right now”. In fact, Rekognition is already being used by law enforcement with zero debate or restrictions on its use from Amazon. For instance, Orlando, Florida, has currently put Rekognition to test with live video feeds from surveillance cameras around the city. Rekognition is a deep-learning based service which is capable of storing and searching tens of millions of faces at a time.  It allows detection of objects, scenes, activities and inappropriate content. Amazon had also received criticism from the ACLU regarding selling rekognition to cops as it said that, “People should be free to walk down the street without being watched by the government. By automating mass surveillance, facial recognition systems like Rekognition threaten this freedom, posing a particular threat to communities already unjustly targeted in the current political climate. Once powerful surveillance systems like these are built and deployed, the harm will be extremely difficult to undo.” Amazon had been quick to defend at that time and said in a statement emailed to various news organizations that, “Our quality of life would be much worse today if we outlawed new technology because some people could choose to abuse the technology. Imagine if customers couldn’t buy a computer because it was possible to use that computer for illegal purposes? Like any of our AWS services, we require our customers to comply with the law and be responsible when using Amazon Rekognition.” The protest by Amazon employees is over the same concern as ACLU’s. Giving Rekognition in the hands of the government puts the privacy of the people at stake as people won’t be able to go about their lives without being constantly monitored by the government. “Companies like ours should not be in the business of facilitating authoritarian surveillance. Not now, not ever. But Rekognition supports just that by pulling dozens of facial IDs from a single frame of video and storing them for later use or instantly comparing them with databases of millions of pictures. We cannot profit from a subset of powerful customers at the expense of our communities; we cannot avert our eyes from the human cost of our business”, mentions the letter. The letter also points out that Rekognition is not accurate in its ability to identify people and is a “flawed technology” that is more likely to “misidentify people” with darker skin tone. For instance, Rekognition was earlier this year put to test with pictures of Congress members compared against a collection of mugshots. The result was 28 false matches with incorrect results being higher for people of color. This makes it irresponsible, unreliable and unethical of the government to use Rekognition. “We will not silently build technology to oppress and kill people, whether in our country or in others. Amazon talks a lot about values of leadership. If we want to lead, we need to make a choice between people and profits. We can sell dangerous surveillance systems to police or we can stand up for what’s right. We can’t do both”, reads the letter. For more information, check out the official letter by Amazon employees. Jeff Bezos: Amazon will continue to support U.S. Defense Department Amazon increases the minimum wage of all employees in the US and UK Amazon is the next target on EU’s antitrust hitlist

Aside from the big ugly notch on the Pixel XL 3, both the XL 3 and the Pixel 3 will sport a new security chip called the Titan M. This dedicated chip raises the security game in these new Pixel devices. The M is... well a good guess—mobile. The Titan chip was previously used internally at Google. This is another move towards making better security available at the hands of everyday consumers after Google made the Titan security key for available for purchase. What does the Titan M do? The Titan M is an individual low-power security chip designed and manufactured by Google. This is not a part of Snapdragon 845 powering the new Pixel devices. It performs a couple of security functions at the hardware level. Store and enforce the locks and rollback counters used by Android Verified Boot to prevent attackers from unlocking the bootloader. Securely locks and encrypts your phone and further limits invalid attempts of unlocking the device. Apps can use the Android Strongbox Keymaster module to generate and store keys on the Titan M. The Titan M chip has direct electrical connections to the Pixel's side buttons that prevent an attacker from faking button presses. Factory-reset policies that enforce rules with which lost or stolen devices can be restored only by the owner. Ensures that even Google themselves can't unlock a phone or install firmware updates without the passcode set by the owner with Insider Attack Resistance. An overview of the Titan M chip Since the Titan M is a separate chip, it protects against hardware-level attacks such as Rowhammer, Spectre, and Meltdown. Google has complete control and supervision over building this chip, right from the silicon stages. They have taken care to incorporate features like low power usage, low-latency, hardware cryptographic acceleration, tamper detection, and secure, timely firmware updates to the chip. On the left is the first generation Titan chip and on the right is the new Titan M chip. Source: Google Blog Titan M CPU The CPU used is an ARM Cortex-M3 microprocessor which is specially hardened against side-channel attacks. It has been augmented with defensive features to detect and act upon abnormal conditions. The CPU core also exposes several control registers to join access with chip configuration settings and peripherals. The Titan M verifies the signature of its firmware using a public key built into the chip. On signature verification, the flash is locked to prevent any modification. It also has a large programmable coprocessor for public key algorithms. Encryption in the chip This new chip also features hardware accelerators like AES and SHA. The accelerators are flexible meaning they can either be initialized with firmware provided keys or via chip-specific and hardware-bound keys generated by the Key Manager module. The chip-specific keys are generated internally with the True Random Number Generator (TRNG). Hence such keys are limited entirely to the chip internally and are not available outside the chip. Google tried to pack maximum security features into Titan M's 64 KB RAM. The RAM contents of the chip can be preserved even during battery saving mode when most hardware modules are turned off. Here’s a diagram showing the chip components. Source: Google Blog Google is aware of what goes into each chip from logic gates to the boot code. The chip allows higher security in areas like two-factor authentication, medical device control, and P2P payments among other potential future uses. The Titan M firmware source code will be publicly available soon. For more details, visit the Google Blog. Google Titan Security key with secure FIDO two factor authentication is now available for purchase Google introduces Cloud HSM beta hardware security module for crypto key security Google’s Protect your Election program: Security policies to defend against state-sponsored phishing attacks, and influence campaigns

Yesterday, Apple started allowing U.S. users to download a copy of all their data the company stores as a part of their privacy data portal expansion. The company had announced this feature expansion earlier this year. Per Bloomberg, prior to making this functionality available to U.S users, Apple rolled out the same functionality in Europe earlier this year as part of the European Union’s General Data Protection Regulation (GDPR) rules. With this effort, U.S. users will be able to download data such as all of their address book contacts, calendar appointments, music streaming preferences and details about past Apple product repairs. Previously, customers could not get their data without contacting Apple directly. Apple launched its online privacy portal in May during which U.S users were allowed only to correct their data or delete their Apple accounts. Apple has also added messages across its apps that tell users how their data is being handled. The company is also rolling out an updated privacy page on its website today detailing what data it does and does not store. Apple says that it does not store much of user’s data, which was confirmed by Zack Whittaker, a security editor at TechCrunch, when he asked Apple for his own data and the company turned over only a few megabytes of spreadsheets, including his order and purchase histories, and marketing information. In his article on ZDNet, Zack says, “The zip file contained mostly Excel spreadsheets, packed with information that Apple stores about me. None of the files contained content information -- like text messages and photos -- but they do contain metadata, like when and who I messaged or called on FaceTime.” He further added, “Any other data that Apple stores is either encrypted — so it can’t turn over — or was only held for a short amount of time and was deleted.” About Apple’s privacy policy updates, it refreshes its privacy pages once a year, a month after its product launches. It first launched its dedicated privacy pages in 2014. A year later, the company blew up the traditional privacy policy in 2015 by going more full-disclosure. Zack says that, since then, Apple’s pages have expanded and continued to be transparent on how the company encrypts user data on its devices. To know more about how Apple encrypts user data in detail, visit Zack’s post on ZDNet. Apple bans Facebook’s VPN app from the App Store for violating its data collection rules Apple has introduced Shortcuts for iOS 12 to automate your everyday tasks Apple buys Shazam, and will soon make the app ad-free  

The Electronic Frontier Foundation is introducing a new Coder’s Rights project to allow programmers and developers to research and develop freely without worrying about facing serious legal challenges that may inhibit their work. With Coder’s Rights project, EFF will protect researchers through education, legal defense, amicus briefs, and involvement in the community. They will also provide policy advice to decision-making officials who are considering new computer crime legislation and treaties. The project seeks to support the right of free expression that lies at the heart of researchers' creations and use of computer code to examine computer systems, and relay their discoveries among their peers and to the wider public. To kick-start this project, EFF has published a whitepaper yesterday, Protecting Security Researchers' Rights in America. This paper aims to provide “legal and policy basis for the Coder’s Rights project, outlining human rights standards that lawmakers, judges, and most particularly the Inter-American Commission on Human Rights, should use to protect the fundamental rights of security researchers.” According to the paper, “present security researchers work in an environment of legal uncertainty, even as their job becomes more vital to the orderly functioning of society.” Their research paper is based on the rights recognized by the American Convention on Human Rights, and examples from North and South American jurisprudence. It analyzes “what rights security researchers have; how those rights are expressed in the Americas’ unique arrangement of human rights instruments, and how the EFF might best interpret the requirements of human rights law when applied to the domain of computer security research and its practitioners.” Here are the main highlights from the paper: Courts and the law should guarantee that the creation, possession or distribution of tools related to cybersecurity are protected by Article 13 of the American Convention of Human Rights, as legitimate acts of free expression. Lawmakers and judges should discourage the use of criminal law as a response to socially beneficial behavior by security researchers. Cybercrime law should include malicious intent and actual damage in its definition of criminal liability. Criminal liability must be based on laws which describe in a precise manner which conduct is forbidden and which is punishable. Penalties for computer crimes should be proportionate to the harm caused by crimes conducted without the use of a computer. Proactive actions should be taken to secure the free flow of information in the security research community. The white paper is available for download. Read more about the Coder’s Rights project on EFF. Privacy experts urge the Senate Commerce Committee for a strong federal privacy bill “that sets a floor, not a ceiling”. Consumer protection organizations submit a new data protection framework to the Senate Commerce Committee. What the EU Copyright Directive means for developers – and what you can do

Yesterday, Google, Mozilla, and Apple announced that by 2020, they will disable TLS 1.0 and 1.1 by default in their respective browsers. Kyle Pflug, Senior Program Manager for Microsoft Edge said, "January 19th of next year marks the 20th anniversary of TLS 1.0, the inaugural version of the protocol that encrypts and authenticates secure connections across the web." Chrome, Edge, Internet Explorer, Firefox, and Safari already support TLS 1.2 and will soon support recently-approved final version of the TLS 1.3 standard. On the other hand, Chrome and Firefox already support TLS 1.3, while Apple and Microsoft are still working towards supporting TLS 1.3. Why disable TLS 1.0 and 1.1? The Internet Engineering Task Force (IETF), an organization that develops and promotes Internet standards is hosting discussions to formally deprecated both TLS 1.0 and 1.1. TLS provides confidentiality and integrity of data in transit between clients and servers while exchanging information. In order to keep this data safe, it is essential to use modern and highly secures versions of this protocol. The Apple’s Secure Transports team has listed down some benefits of moving away from TLS 1.0 and 1.1 including: Modern cryptographic cipher suites and algorithms with desirable performance and security properties, e.g., perfect forward secrecy and authenticated encryption, that are not vulnerable to attacks such as BEAST. Removal of mandatory and insecure SHA-1 and MD5 hash functions as part of peer authentication. Resistance to downgrade-related attacks such as LogJam and FREAK. For Google Chrome users, Enterprise deployments can preview the TLS 1.0 and 1.1 removal today by setting the SSLVersionMin policy to ‘tls1.2’. For enterprise deployments that need more time, this same policy can be used to re-enable TLS 1.0 or TLS 1.1 until January 2021. Post depreciation here is what each browser maker has promised: TLS 1.0 and 1.1 will be disabled altogether in Chrome 81, which will start rolling out “on early release channels starting January 2020.” Edge and Internet Explorer 11 will disable TLS 1.0 and TLS 1.1 by default “in the first half of 2020.” Firefox will drop support for TLS 1.0 and TLS 1.1 in March 2020. TLS 1.0 and 1.1. will be removed from Safari in updates to Apple iOS and macOS beginning in March 2020. Read more about this news in detail on Internet Engineering Task Force (IETF) blog post. Introducing TLS 1.3, the first major overhaul of the TLS protocol with improved security and speed Let’s Encrypt SSL/TLS certificates gain the trust of all Major Root Programs Java 11 is here with TLS 1.3, Unicode 11, and more updates

After Google just got saved from GDPR’s huge fine last month, Twitter is next on the EU’s GDPR investigation checklist. This appears to be the first GDPR investigation to be opened against Twitter. Last week, the data privacy regulators in Ireland opened up an investigation against Twitter’s data collection practices. This is to analyze the amount of data Twitter receives from its URL-shortening system, t.co. Twitter says the URL shortening allows the platform to measure the number of clicks per link, and helps it to fight the spread of malware through suspicious links. Why did Irish data regulators choose to investigate Twitter? This news was first reported by Fortune stating, “Michael Veale, who works at University College London, suspects that Twitter gets more information when people click on t.co links, and that it might use them to track those people as they surf the web, by leaving cookies in their browsers.” Veale asked Twitter to provide him with all the personal data it holds on him. To which, Twitter refused claiming that providing this information would take a disproportionate effort. Following this, Veale filed a complaint to the Irish Data Protection Commission (DPC), and the authorities opened an investigation last week. In a letter to Veale, the Irish Data Privacy Commissioner wrote, “The DPC has initiated a formal statutory inquiry in respect of your complaint. The inquiry will examine whether or not Twitter has discharged its obligations in connection with the subject matter of your complaint and determine whether or not any provisions of the GDPR or the [Irish Data Protection] Act have been contravened by Twitter in this respect.” The Irish authorities said that Veale’s complaint will be handled by the new European Data Protection Board as Veale’s complaint involves cross-border processing. The EU Data protection body helps national data protection authorities coordinate their GDPR enforcement efforts. Veale also prompted a similar investigation probe into Facebook, which also refused to hand over data held on users’ web-browsing activities. However, Fortune says, “ Facebook was already the subject of multiple GDPR investigations.” Veale says, "Data which looks a bit creepy, generally data which looks like web-browsing history, [is something] companies are very keen to keep out of data access requests. The user has a right to understand." Twitter, however, refused to comment, saying only that it was ‘actively engaged’ with the DPC. If Twitter is found to be in GDPR’s breach list, it could face a fine of up to €20m or up to 4 percent of its global annual revenue. To know more about this news in detail, head over to Fortune’s full coverage. How Twitter is defending against the Silhouette attack that discovers user identity GDPR is good for everyone: businesses, developers, customers The much loved reverse chronological Twitter timeline is back as Twitter attempts to break the ‘filter bubble’

"Having a mobile facility that allows us to bring realistic cyberattack preparation and rehearsal to a larger, global audience will be a game changer in our mission to improve incident response efforts for organizations around the world." -Caleb Barlow, vice president of Threat Intelligence at IBM Security   Yesterday (On 15th October), IBM Security announced the industry's first mobile Security Operations Center- ‘The IBM X-Force Command Cyber Tactical Operations Center’ (C-TOC). This mobile command center hosted at the back of a semi truck will travel around the U.S and Europe for cybersecurity training, preparedness, and response operations. The aim of this project is to provide an on-demand cybersecurity support, while building cybersecurity awareness and skills with professionals, students and consumers. Cybercriminals are getting smarter by the day and cyber crimes are becoming sophisticated by the hour. It is necessary for organizations to plan and rehearse their response to potential security breaches in advance. According to the 2018 Cost of a Data Breach Study, companies that respond to incidents effectively and remediate the event within 30 days can save over $1 million on the total cost of a data breach. Taking this into consideration, the C-TOC has the potential to provide immediate onsite support for clients at times when their cybersecurity needs may arise. The mobile vehicle is modeled after Tactical Operations Centers used by the military and incident command posts used by first responders. It comes with a gesture-controlled cybersecurity "watch floor," data center and conference facilities. It has self-sustaining power, satellite and cellular communications, which will provide a sterile and resilient network for investigation, response and serve as a platform for cybersecurity training. Source: IBM Source: IBM Here are some of the key takeaways that individuals can benefit from, from this mobile Security Operations center: #1 Focus on Response Training and Preparedness The C-TOC will simulate real world scenarios to depict how hackers operate- to help companies train their teams to respond to attacks. The training will cover key strategies to protect business and its resources from cyberattacks. #2 Onsite Cybersecurity Support The C-TOC is mobile and can be deployed as an on-demand Security Operation Center. It aims to provide a realistic cybersecurity experience in the industry while visiting local universities and industries to build interest in cybersecurity careers and to address other cybersecurity concerns. #3 Cyber Best Practices Laboratory The C-TOC training includes real world examples based on experiences with customers in the Cambridge Cyber Range. Attack scenarios will be designed for teams to participate in. The challenges are designed keeping in mind various pointers like: working as a team to mitigate attacks, thinking as a hacker, hands- on experience with a malicious toolset and much more #4 Supplementary Cybersecurity Operations The IBM team also aims to spread awareness on the cybersecurity workforce shortage that is anticipated soon. With an expected shortfall of nearly 2 million cybersecurity professionals by 2022, it is necessary to educate the masses about careers in security as well as help upskill current professionals in cybersecurity. This is one of the many initiatives taken by IBM to bring about awareness about the importance of mitigating cyber attacks in time. Back in 2016, IBM invested $200 million in new incident response facilities, services and software, which included the industry's first Cyber Range for the commercial sector. By real world simulation of cyber attacks and training individuals to come up with advanced defense strategies, the SOC aims to get a realistic cyberattack preparation and rehearsal to a larger, global audience. To know more about this news as well as the dates that the C-TOC will tour the U.S. and Europe, head over to IBM’s official blog. Mozilla announces $3.5 million award for ‘Responsible Computer Science Challenge’ to encourage teaching ethical coding to CS graduates The Intercept says Google’s Dragonfly is closer to launch than Google would like us to believe U.S Government Accountability Office (GAO) reports U.S weapons can be easily hacked  

Mitchell Baker, chairwoman, and co-founder of Mozilla talked about the need for the tech industry to expand beyond the technical skills, last week following the announcement of the Responsible computer Science Challenge. She spoke about how hiring employees only from the STEM (science, technology, engineering, and maths) stream leads the way for technologists who face the same “blind spots” in tech as the current ones.   “STEM is a necessity and educating more people in STEM topics clearly critical. But one thing that’s happened in 2018 is that we’ve looked at the platforms, and the thinking behind the platforms, and the lack of focus on impact or result,” said Baker in a statement to the Guardian. She also mentioned that hiring employees solely from the STEM disciplines is a move that will “come back to bite us”. Baker also tweeted about the reason to move beyond the precise technical jobs and skills: https://twitter.com/MitchellBaker/status/1050842658724184065 Mozilla wants to broaden the horizon of the tech industry by incorporating education grounded in humanities such as psychology and philosophy into undergraduate computer science degrees. The inclusion of ethics in the coursework will focus on not being purely philosophical. Rather, it will make use of hypothesis and logic to present the ideas. Also, these ethics ideas should make sense in a computer science coursework. “We need to be adding not just social sciences of the past, but something related to humanity and how to think about the effects of technology on humanity – which is partly sociology, partly anthropology, partly psychology, partly philosophy, partly ethics … it’s some new formulation of all of those things, as part of a Stem education. Otherwise, we’ll have ourselves to blame, for generations of technologists who don’t even have the toolsets to add these things in”, mentioned Baker. Mozilla Foundation, along with Omidyar Network, Schmidt Futures, and Craig Newmark Philanthropies, launched a competition, named Responsible Computer Science Challenge, last week for professors and educators. This aims to produce “a new wave of engineers” who’d implement a holistic approach to the design of all types of tech products.   “The hope is that the Challenge will unearth and spark innovative coursework that will not only be implemented at the participating home institutions but also be scaled to additional colleges and universities across the country — and beyond”, reads the challenge overview. The challenge stems from the ongoing problem of misinformation online and wants to empower graduating engineers to drive a “culture shift in the tech industry and build a healthier internet”. This initiative by Mozilla to promote ethics and humanities in computer science coursework reflects on the values that the company stands by. It was only last week when the company dropped the word “meritocracy” from its revised governance statement and leadership structure to actively promote diversity and inclusion. “In a world where software is entwined with much of our lives, it is not enough to simply know what software can do. We must also know what software should and shouldn’t do, and train ourselves to think critically about how our code can be used. Students of computer science...must understand how code intersects with human behavior, privacy, safety, vulnerability, equality, and many other factors”, says Kathy Pham, a computer scientist at Mozilla who’s also co-leading the challenge. For more information, check out the official Mozilla blog. Mozilla, Internet Society, and web foundation wants G20 to address “techlash” fuelled by security and privacy concerns Mozilla’s new Firefox DNS security updates spark privacy hue and cry Firefox Nightly browser: Debugging your app is now fun with Mozilla’s new ‘time travel’ feature

Last month, Facebook witnessed its largest security breach which compromised 50 million user accounts, which was later fixed by its investigation team to avoid further misuse. On Friday, 12th October, Guy Rosen, VP of Product Management in Facebook, shared details of the attack for the users to know the actual reason behind the attack. A snapshot of the attack Facebook discovered the issue on September 25th where the attackers exploited a vulnerability in Facebook’s code that existed between July 2017 and September 2018. The attackers exploited a series of interactions of three distinct software bugs, which affected the ‘View As’ feature that lets people see what their own profile looks like to someone else. Attackers stole FB access tokens to take over people’s accounts. These tokens allow an attacker to take full control of the victim’s account, including logging into third-party applications that use Facebook Login. Read Also : Facebook’s largest security breach in its history leaves 50M user accounts compromised Deciphering the attack : 29 million users were affected, not 50 million Guy Rosen, in his update stated, “We now know that fewer people were impacted than we originally thought. Of the 50 million people whose access tokens we believed were affected, about 30 million actually had their tokens stolen.” Here’s what happened The attackers already had control over a set of accounts connected to Facebook users. They further used an automatic technique to move from one account to the other in order to steal the access tokens of those friends, friends of friends, and so on. This allowed them to reach about 400,000 users. Guy writes, “this technique automatically loaded those accounts’ Facebook profiles, mirroring what these 400,000 people would have seen when looking at their own profiles. That includes posts on their timelines, their lists of friends, Groups they are members of, and the names of recent Messenger conversations”. The attackers used these 400,000 people’s lists of friends to further steal access tokens for about 30 million people. They broke down these 30 million into three batches; namely 15, 14 and 1 million, and carried out different accessing techniques for the first two batches. For the 1 million people, the attackers did not access any information. For 15 million people, attackers accessed just the name and contact details (phone number, email, or both, depending on what people had on their profiles). For 14 million people, the attackers not only accessed name and contact details, but also other details people had on their profiles. This included username, gender, locale/language, relationship status, religion, hometown, self-reported current city, birthdate, device types used to access Facebook, education, work, the last 10 places they checked into or were tagged in, website, people or Pages they follow, and the 15 most recent searches. Facebook will be sending customized messages to the 30 million affected people to explain to them the information the attacker might have accessed and how they can protect themselves from the after effects (getting suspicious calls, mails and messages). Guy also clarified, “This attack did not include Messenger, Messenger Kids, Instagram, WhatsApp, Oculus, Workplace, Pages, payments, third-party apps, or advertising or developer accounts.” Meanwhile, Facebook is co-operating with FBI, the US Federal Trade Commission, Irish Data Protection Commission, and other authorities to look for ways  attackers used Facebook and other possibilities of smaller-scale attacks. To know more about this in detail, visit Guy Rosen official blog post. Facebook introduces two new AI-powered video calling devices “built with Privacy + Security in mind” Facebook finds ‘no evidence that hackers accessed third party Apps via user logins’, from last week’s security breach “Facebook is the new Cigarettes”, says Marc Benioff, Salesforce Co-CEO

Yesterday, ICANN (Internet Corporation for Assigned Names and Numbers) announced that the root KSK roll has occurred at 1600 UTC. ICANN is an organization that ensures a stable, secure and unified global Internet by coordinating the maintenance and procedures of several databases related to the namespaces and numerical spaces of the Internet. What is a Root KSK (Key Sign Key) Rollover? The KSK is used to cryptographically sign the Zone Signing Key (ZSK), which is used by the Root Zone Maintainer to DNSSEC-sign the root zone of the Internet's DNS. Rolling the KSK means generating a new cryptographic public and private key pair and distributing the new public component to parties who operate validating resolvers including, Internet Service Providers Enterprise network administrators and other Domain Name System (DNS) resolver operators DNS resolver software developers System integrators, and Hardware and software distributors who install or ship the root's ‘trust anchor’ Maintaining an up-to-date KSK is important to ensure that DNSSEC-validating DNS resolvers continue to function following the rollover. Failure to have the current root zone KSK will mean that DNSSEC-validating DNS resolvers will be unable to resolve any DNS queries. Failure to have the current root zone KSK will mean that DNSSEC-validating DNS resolvers will be unable to resolve any DNS queries. Details of the KSK Rollover KSK Rollover operations started in October 2016 and were scheduled for October 2017. However, ICANN announced that the rollover has been postponed stating, “a significant number of resolvers used by Internet Service Providers (ISPs) and Network Operators are not yet ready for the Key Rollover.” Later, a draft plan was announced on February 1, 2018, after receiving input from the community. The date put forward to initiate the procedure was October 11, 2018. Per ICANN, the rollover is necessary to curb the rising number of cyber attacks. In an official statement, Communications Regulatory Authority said, “To further clarify, some internet users might be affected if their network operators or Internet Service Providers (ISPs) have not prepared for this change. However, this impact can be avoided by enabling the appropriate system security extensions.”. To know more about this news in detail, visit the main rollover page on ICANN’s website. RedHat shares what to expect from next week’s first-ever DNSSEC root key rollover Baidu Security Lab’s MesaLink, a cryptographic memory safe library alternative to OpenSSL Google Titan Security key with secure FIDO two factor authentication is now available for purchase

Juniper Networks saw a host of severe vulnerabilities in its hardware today. These vulnerabilities threaten to severely affect a network, including threats like Denial of Service, daemon crashes, insecure configurations, kernel crashes and many more. There were a total of 22 vulnerabilities reported on its Knowledge Center. Here is a list of some of them in Juniper's Junos OS that you need to watch out for. #1 Receiving a specifically crafted malicious MPLS packet leads to a Junos kernel crash In Juniper Networks Junos OS, a NULL Pointer Dereference vulnerability allows an attacker to cause the Junos OS kernel to crash. Target victims can be affected by Denial of Service attack just by a single malicious MPLS packet. Continued receipt of this packet will cause a sustained Denial of Service condition. This issue was encountered during production usage and multiple software have been released to resolve the issue. Many software have also been re-released, while software patches and updates have been made available to sort out the issue. Users are advised to remove MLPS configuration stanza from the interfaces at risk. #2 Memory exhaustion DOS vulnerability in Routing Protocols Daemon with Juniper Extension Toolkit support An unauthenticated network based attacker can cause a device to have severe memory exhaustion due to a vulnerability in the Routing Protocols Daemon (RPD) with Juniper Extension Toolkit (JET) support. This degrades system performance as well as impacts system availability. The issue that was found during internal, product testing, only affects devices with JET support running Junos OS 17.2R1 and subsequent releases. As of today, there are no viable workarounds for this issue. #3 Multiple vulnerabilities discovered in NTP daemon This issues discovered in NTP daemon affects all products and platforms running Junos OS. NTP.org has published security advisories for vulnerabilities resolved in ntpd (NTP daemon). The team has released software patches to resolve the above issues. Users are advised to adopt Standard security best practices (control plane firewall filters, edge filtering, access lists, etc.) to protect against any remote malicious attacks against NTP. Customers who have already applied the workaround described by the team are already protected against any remote exploitation of these vulnerabilities. #4 Invalid IP/mask learned from DHCP server might cause the device control daemon process crash The device control daemon process (dcd) of Juniper Networks Junos OS has an improper input validation weakness. This allows an attacker to cause a Denial of Service to the dcd process and interfaces and connected clients when the Junos device is requesting an IP address for itself. The good news is that Junos devices not configured to use DHCP are not vulnerable to this issue. The issue was discovered in the production stage and multiple softwares have been released to resolve the issue. #5 Stateless IP firewall filter rules stop working after reboot or upgrade Once the Junos OS device reboots or upgrades, the stateless firewall filter configuration does not work as expected. This vulnerability affects firewall filters for every address family. The affected releases of the Junos OS includes 15.1R4, 15.1R5, 15.1R6 and SRs based on these MRs as well as 15.1X8 versions prior to 15.1X8.3. The issue was encountered during production stage and doesn’t have any known workarounds. However, once the issue has occurred, it can be restored by performing "commit full". The  team has released certain softwares to resolve this specific issue. #6 Credentials exposed when using HTTP and HTTPS Firewall Pass-through User Authentication When an SRX Series device is configured to use HTTP/HTTPS pass-through authentication services, it can be affected by a man-in-the-middle attack or by authentic servers that have been subverted by malicious actors. In the initial HTTP/HTTPS session, a client sending authentication credentials is at risk that these credentials may be captured by a malicious hacker during follow-on HTTP/HTTPS requests.This vulnerability does not affect the FTP, and Telnet pass-through authentication services. The team has updated some software releases to resolve this specific issue. The workaround suggested for this vulnerability is to discontinue the use of HTTP/HTTPS Pass-through Firewall User Authentication. Users are also suggested to use web-redirect when using Pass-through Firewall User Authentication. #7 jdhcpd process crash during processing of specially crafted DHCPv6 message A jdhcpd daemon crash can occur after receiving a specially crafted DHCPv6 message destined to a Junos OS device configured as a DHCP server in a Broadband Edge (BBE) environment.  A continuous stream of DHCPv6 packets could lead to an extended denial of service condition. Junos OS 15.1 and later are only affected by this issue. Only if a device has a DHCP service configured, will the devices be vulnerable to the DHCPv6 message. The team has released software to resolve this specific issue. A workaround to this vulnerability would be to disable DHCP services if they are not needed. #8 A local authentication vulnerability may lead to full control of a vSRX instance while the system is booting. Junos OS on vSRX Series has a authentication bypass vulnerability in the initial boot sequence. This may allow an attacker to gain full control of the system without authentication when the system initially boots up. The following software releases have been updated to resolve this specific issue: Junos OS 15.1X49-D30, and all subsequent releases. As such, there are no viable workarounds for this issue. Methods which may reduce, but not eliminate, the risk of exploitation of this problem, include: Restricting  access to the hypervisor to only trusted administrators and disallowing all access to the "physical instance" of the vSRX instance while it is initially booting. This can be done  by disabling connectivity to devices hosting the instance. #9 Unauthenticated remote root access possible when RSH service is enabled A remote unauthenticated attacker can obtain root access to the device if RSH service is enabled on Junos OS and if the PAM authentication is disabled. By default, the RSH service is disabled on Junos. An undocumented CLI command allows a privileged Junos user to enable RSH service and disable PAM, and hence expose the system to unauthenticated root access. This issue is not exploitable on platforms where Junos release is based on FreeBSD 10+. This issue only affects configurations where RSH service is enabled and the PAM authentication is disabled. The team suggests that users should ensure  there is no RSH service listening on port 514.  They also suggest Utilizing common security BCPs to limit the exploitable surface by limiting access to network and device to trusted systems, administrators, networks and hosts. #10 Receiving a malformed MPLS RSVP packet leads to a Routing Protocols Daemon crash A attacker can easily cause the RPD to crash because of an error handling vulnerability in Routing Protocols Daemon (RPD) of Juniper Networks Junos OS. Continuously receiving this malformed MPLS RSVP packet will cause a sustained Denial of Service condition. This issue does not affect versions of Junos OS before 14.1R1. The team has updated the following software releases to resolve this specific issue: 14.1R8-S5, 14.1R9, 14.1X53-D130, 14.1X53-D48, 14.2R4, 15.1R1, and all subsequent releases. The team suggests removing the  MPLS configuration stanzas from interface configurations that are at risk. These are just some of the vulnerabilities that can affect the Junos OS. To know more about the other vulnerabilities reported, head over to Juniper Networks official site. Juniper networks comes up with 5G – IoT-ready routing platform, MX Series 5G ‘Peekaboo’ Zero-Day Vulnerability allows hackers to access CCTV cameras, says Tenable Research Upgrade to Git 2.19.1 to avoid a Git submodule vulnerability that causes arbitrary code execution

“While we are saying it’s going to be six and nine months [to launch], the world is a very dynamic place” - Ben Gomes, Google’s search engine chief The past two months have been filled with controversies for Google after The Intercept revealed details about a censored search engine for China, code-named Dragonfly. The project was severely criticized by human rights groups, U.S. senators and Google employees- some of whom have resigned. Even Vice President Mike Pence last week, called on Google to "immediately end development of the Dragonfly app"  while accusing China to be "applying its power in more proactive ways than ever before, to exert influence and interfere in the domestic policy and politics of our country." Now, fresh reposts have emerged that according to a leaked transcript to The Intercept, Google is all set to launch the search engine in the coming months. This came as a stark contrast to the public comments released by many of its senior executives. On September 23, at an event celebrating Google’s 20th anniversary, Ben Gomes, Google’s search engine chief, was confronted by a BBC reporter on the controversial search engine. Gomes told the reporter that all the work done so far is "some exploration," "but since we don’t have any plans to launch something, there’s nothing much I can say about it." Following this incident, on Sept. 26, Keith Enright, Google’s chief privacy officer faced public questions on the censorship plan. He confirmed that Project Dragonfly did exist, but affirmed: "we are not close to launching a product in China." Looks like the plan was way over an "exploration," as highlighted by Google’s own employees in a memo posted on an internal messaging list set up for Google employees to raise ethical concerns. Google had desperately tried to suppress this information by scrubbing the memo from the list. Individuals who had opened or saved the document were contacted by Google’s human resources department to discuss the matter. The employees were also instructed against sharing the memo. The leaked transcript of Ben Gomes private meeting with employees working on Dragonfly (dated July 18, 2018) is not in sync with these publicly released comments. The transcript records Gomes saying that the project was "the biggest opportunity to serve more people that we have. And if you take our mission seriously, that’s where our key focus should be". He goes on to add that China is one of the "most interesting markets". He prepares them to look for the window of opportunity where the search engine could be launched given the uncertain political climate in the US, supposedly six-nine months down the line. It wouldn’t come as a surprise if the engine launches earlier than the said deadline, as Gomes himself states that "This is a world none of us have ever lived in before, so I feel like we shouldn’t put too much definite into the timeline." This search engine was specifically designed to block terms considered to be sensitive by the Chinese communist party regimen such as 'peaceful protest'. With citizens phone numbers, IP address and location tracking attached to their search queries, it would be very easy for the government to track their internet footprint. The fear is that Google could be directly contributing to, or becoming complicit in, human rights violations. You can head over to The Intercept for the complete transcript of this private meeting. Skepticism welcomes Germany’s DARPA-like cybersecurity agency – The federal agency tasked with creating cutting-edge defense technology Google’s ‘mistakenly deployed experiment’ covertly activated battery saving mode on multiple phones today Ex-googler who quit Google on moral grounds writes to Senate about company’s “Unethical” China censorship plan  

The U.S Government Accountability Office (GAO) published a report on Tuesday, which highlights that the U.S. Department of Defense (DOD) can be easily hacked by adversaries. The report states that military weapon systems developed from 2012 to 2017 are vulnerable to cyber attacks. The GAO also said that the Pentagon was unaware of how easy it could be for an adversary to gain access to the computer brains and software of the weapons systems and operate inside them undetected. What were GAO’s findings? The GAO investigators assessed the Pentagon’s cybersecurity findings over a five-year period. The testers were asked to find vulnerabilities by hacking into the military weapon systems. To this, GAO reported, “testers were able to take control of systems and largely operate undetected, due in part, to basic issues such as poor password management and unencrypted communications.” The testers could shut down a system simply by scanning it. This is a typical first step in trying to carry out a digital attack. The testers could also manipulate what the soldiers operating the weapon were seeing on their computer screens. As described in the report, “weapons testers caused a pop-up message to appear on users’ terminals instructing them to insert two quarters to continue operating.” One of the reasons DOD systems are susceptible to the cyber attack could be their connectivity to various other systems, which can introduce vulnerabilities and make systems more difficult to defend. DOD systems are also more connected than ever before, which can introduce vulnerabilities and make systems more difficult to defend. The report further mentions, "These connections help facilitate information exchanges that benefit weapon systems and their operators in many ways—such as command and control of the weapons, communications, and battlespace awareness. If attackers can access one of those systems, they may be able to reach any of the others through the connecting networks." Pentagon spokesperson Maj. Audricia Harris told CNN, “We are continuously strengthening our defensive posture through network hardening, improved cybersecurity, and working with our international allies and partners and our defense Industrial Base and defense Critical Infrastructure partners to secure critical information." The fact that Pentagon weapon systems are vulnerable to cyber-attack raises brings in a lot of questions about the huge chunk of investments the US has done in its programs. Following the revelation of this vulnerability, the Department of Defense recently released its cyber strategy stating that the Pentagon is seeking to incorporate cyber-security awareness throughout the institutional culture of the department. The report claims that the DOD documented many of these "mission-critical cyber vulnerabilities," but Pentagon officials who met with GAO testers claimed their systems were secure, and "discounted some test results as unrealistic." GAO said, “all tests were performed on computerized weapons systems that are still under development. GAO officials also highlighted that hackers can't yet take control over current weapons systems and turn them against the U.S. But if these new weapons systems go live, the threat is more than real.” To know more about this in detail, head over to GAO’s report. Upgrade to Git 2.19.1 to avoid a Git submodule vulnerability that causes arbitrary code execution Implementing Web application vulnerability scanners with Kali Linux [Tutorial] Bitcoin Core escapes a collapse from a Denial-of-Service vulnerability  

Yesterday, Google reported a bug discovery in one of the Google+ People APIs, which exposed user’s Google+ profile information such as name, email address, occupation, gender, and age. As per Google’s analysis, the profiles of up to 500,000 Google+ accounts were potentially affected. According to the Wall Street Journal report, “Google opted not to disclose the issue this past spring, in part because of fears that doing so would draw regulatory scrutiny and cause reputational damage.” Google discovered this bug as a part of its Project Strobe, which began in early 2018. Strobe was started with an aim to analyze third-party developer access in Google’s various services and Android. The company says it immediately patched this bug in March 2018 post learning of its existence. The bug provided outside developers potential access to private Google+ profile data between 2015 and March 2018, say internal investigators who discovered and fixed it. Using the API, users can grant access to their profile data, and the public profile information of their friends, to Google+ apps. However, with the bug, the apps also had an access to profile fields even when that data was listed as private and not public. Why were users kept in the dark? Any security breach pertaining to user data exposure should quickly be informed. However, as per the Wall Street Journal report, “A memo reviewed by the Journal prepared by Google’s legal and policy staff and shared with senior executives warned that disclosing the incident would likely trigger ‘immediate regulatory interest’ and invite comparisons to Facebook’s leak of user information to data firm Cambridge Analytica.” In response to the allegations raised on Google, Ben Smith, Vice President of Google’s Engineering team, in his recent blog post mentioned, “Every year, we send millions of notifications to users about privacy and security bugs and issues. Whenever user data may have been affected, we go beyond our legal requirements and apply several criteria focused on our users in determining whether to provide notice.” He also assured that Google’s Privacy & Data Protection Office reviewed the issue. He further added, “looking at the type of data involved, whether we could accurately identify the users to inform, whether there was any evidence of misuse, and whether there were any actions a developer or user could take in response. None of these thresholds were met in this instance.” Ben said that Google found no evidence that any developer was aware of this bug or abusing the API. He also assured that no profile data was misused. Will this delayed bug discovery announcement subject Google to GDPR? The European GDPR (General Data Protection Regulation), which was enforced on 25 May 2018 requires companies to notify regulators of breaches within 72 hours, else the companies would be charged a maximum fine of 2% of world-wide revenue. Al Saikali, a lawyer with Shook, Hardy & Bacon LLP, said, “The information potentially leaked via Google’s API would constitute personal information under GDPR, but because the problem was discovered in March, it wouldn’t have been covered under the European regulation.” He further added, “Google could also face class-action lawsuits over its decision not to disclose the incident. The story here that the plaintiffs will tell is that Google knew something here and hid it. That by itself is enough to make the lawyers salivate.” The Aftermath: Google plans to discontinue Google+ for consumers Ben’s post mentions that over the years, Google+ has not achieved broad consumer or developer adoption, and has seen limited user interaction with apps. Talking about its consumer version, Google+ currently has low usage and engagement--90 percent of Google+ user sessions are less than five seconds. One of the priorities of Project Strobe was to closely review all the APIs associated with Google+ during which it also discovered the bug. Ben mentions, “The review did highlight the significant challenges in creating and maintaining a successful Google+ that meets consumers’ expectations.” Following these challenges and the very low usage of the consumer version of Google+, Google has decided to discontinue Google+ consumer version. This shutdown will take place over the course of the next 10 months, and will conclude in August, next year. However, Google plans to make Google+ available as an enterprise product for companies. Ben states, “We’ve decided to focus on our enterprise efforts and will be launching new features purpose-built for businesses. We will share more information in the coming days.” Other findings of Project Strobe and the actions taken Project Strobe provides a ‘root and branch’ review of third-party developer access to Google account and Android device data and of Google’s philosophy around apps’ data access. The main key finding of this project is the discovery of an exploitable bug built into a core API of Google+ for three years. The other key findings and the actions taken include: The need for having fine-grained control over the data shared with apps For this finding, Google plans to launch more granular Google Account permissions that will show up in individual dialog boxes. Here, instead of seeing all requested permissions in a single screen, apps will have to show the user each requested permission, one at a time, within its own dialog box. Know more about this on Google Developer Blog. Here’s a sample of how this process will look like: Source: Google blog Granting access to user’s Gmail via apps is done with certain use cases in mind For this, Google plans to limit the types of use cases that are permitted. The company is updating their User Data Policy for the consumer Gmail API to limit the apps that may seek permission to access consumer’s Gmail data. Only apps directly enhancing email functionality such as email clients, email backup services and productivity services (e.g., CRM and mail merge services), will be authorized to access this data. Also, these apps will need to agree to new rules for handling Gmail data and will be subject to security assessments. To know more about this action, read the Gmail Developer Blog. Granting SMS, Contacts and Phone permissions to Android apps are done with certain use cases in mind As an action to this finding, Google will limit the apps’ ability to receive call log and SMS permissions on Android devices. Hence, the contact interaction data will no longer be available via the Android Contacts API. Additionally, Google has also provided basic interaction data, for example, a messaging app could show you your most recent contacts. They also plan to remove access to contact interaction data from the Android Contacts API within the next few months. To read more about Project Strobe and the closing down of Google+ in detail, visit Ben Smith Google post. Facebook’s largest security breach in its history leaves 50M user accounts compromised Bloomberg’s Big Hack Exposé says China had microchips on servers for covert surveillance of Big Tech and Big Brother; Big Tech deny supply chain compromise Timehop suffers data breach; 21 million users’ data compromised