Tech News - Cybersecurity

Last week, a developer Tute Costa notified Ruby users that the strong_password v0.0.7 rubygem has been hijacked. The malicious actor published v0.0.7 containing the malicious code, which enabled the attacker to execute remote code in production. As of now, the thread has been tweaked and the attacker’s RubyGems account has been locked. A strong_password is an entropy-based password strength used for checking Ruby and ActiveModel. How was the strong_password v0.0.7 hijack identified? While linking line by line to each library’s changeset, Costa noticed that the strong_password has changed from 0.0.6 to 0.0.7. Although the last changes in any branch in GitHub was from 6 months ago, Costa recalled that everything was up to date. Costa then downloaded the gem from RubyGems and compared its contents with its latest copy in GitHub. He found that at the end of the lib/strong_password/strength_checker.rb version 0.0.7 there was the following message: Image Source: With a Twist Dev Costa found that a malicious actor has used an empty account, with a different name than the maintainer’s. The malicious actor has published the gem, after receiving access to the particular gem. Later, Costa forwarded this thread to the strong_password maintainer’s email in GitHub. Brian McManus, the strong_password maintainer replied, “The gem seems to have been pulled out from under me. When I login to rubygems.org I don’t seem to have ownership now. Bogus 0.0.7 release was created 6/25/2019.” How does the malicious code work? If the malicious code didn’t run before checking for the existence of the Z1 dummy constant, it injects a middleware that eval’s cookies named with an ___id suffix, only in production. It is surrounded by the empty exception handler _! function that’s defined in the hijacked gem. This opens the door to the attacker to silently execute remote codes in production. The malicious code also sends a request to a controlled domain with an HTTP header informing the infected host URLs. What is the current status of strong_password v0.0.7? Rafael França, the Ruby on Rails’ security coordinator has added asecurity@rubygems.org to the thread. Later André Arko, the founder of Ruby Together, tweaked the thread and locked the RubyGems account. McManus was later added back to the gem. Costa also notified users that he asked for a CVE identifier (Common Vulnerabilities and Exposures) to cve-request@mitre.org and received CVE-2019-13354. He used this CVE “to announce the potential issue in production installations to the rubysec/ruby-advisory-db project and the ruby-security-ann Google Group.” The community has been praising Tute Costa for his efforts in finding out about the hijack. https://twitter.com/mjos_crypto/status/1148153570631589889 A user on Hacker News states that “In light of vulnerabilities like these, I’m glad there are developers that spend time to make their apps more secure. Thus, making us all aware that issues like these are out there. Security is almost always just put off in exchange for features and security is most of the time taken for granted. It’s about time that we start taking it seriously. Kudos to you!” Many users are also skeptical about RubyGem’s security vulnerabilities. A user on Hacker News says, “There's still a lot to learn about this incident, but most likely the RubyGems account was compromised, allowing the attacker to upload whatever they wanted. Signed releases with a web of trust would be ideal, but I doubt we'll ever see that world. A simple and pragmatic solution would be to have the next version of bundler support the ability to only install packages published with 2 factor enabled, then the next major rails version default it to on, with plenty of advanced warning in 6.x/bundler. This still has plenty of gaps, such as an attacker being able to take over even with 2 factor, and then re-enabling it with their own keys, or RubyGems.org itself being compromised. It still represents a major upgrade in security for the entire Ruby ecosystem without causing much pain to authors and users.” Another comment reads, “Rubygem should contract an external auditor (security firm), this could go way deeper. Until they perform a thorough audit I will personally stay away from this project.” Why Ruby developers like Elixir Ruby ends support for its 2.3 series How Deliveroo migrated from Ruby to Rust without breaking production

"Technology, in general, and computer science in particular, have been hyped up to such an extreme level that we've ignored the importance of not only security but broader notions of ethical computing." -James Mickens We like to think that things are going to get better. That, after all, is why we get up in the morning and go to work, in the hope that we might just be making a difference, that we’re working towards something. That’s certainly true across the technology landscape. And in cybersecurity in particular, the belief that you’re building a more secure world - even if it’s on a small scale - is an energizing and motivating thought. However, at this year’s USENIX Conference back in August, Harvard Professor James Mickens attempted to put that belief to rest. His talk - titled ‘Why Do Keynote Speakers Keep Suggesting That Improving Security Is Possible?’ - was an argument for scepticism in a field that is by nature optimistic (not least when it has a solution to sell). So, what exactly does Mickens have against keynote speakers? Quite a lot, actually: he jokingly calls them people who have made bad life decisions aand poorrole models. Although his tongue is firmly in his cheek, he does have a number of serious points. Fundamentally, he suggests developers do not invest time in questioning anything since any degree ofintrospection would “reduce the frequency of git commits”. Mickens argument is essentially thatsoftware developers are deploying new systems without a robust understanding of those systems. Why machine learning highlights the problem with computer science today Mickens stresses that such is the hype and optimism around modern technology and computer science  that the field has largely forgotten the value of scepticism. In turn, this can be dangerous for issues such as security and ethics. Take Machine Learning for instance. Machine learning is, Mickens sayss  “the oxygen that Silicon Valley is trying to force into our lungs.” It’s everywhere, we seem to need it - but it’s also being forced on us, almost blindly, Using the example of machine learning he illustrates his point about domain knowledge: Computer scientists do not have a deep understanding of the mathematics used in machine learning systems. There is no reason or incentive for computer scientists to even invest their time in learning those things. This lack of knowledge means ethical issues and security issues that may be hidden at a conceptual level - not a technical one - are simply ignored. Mickens compares machine learning to the standard experiment used in America since 8th grade: the egg drop experiment. This is where students desperately search for a solution to prevent the egg from breaking when dropped from 20 feet in the air. When they finally come up with a technique that is successful, Mickens explains, they don’t really care to understand the logic/math behind it. This is exactly the same as developers in the context of machine learning. Machine learning is complex, yes, but often, Mickens argues, developers will have no understanding as to why models generate a particular output on being provided with a specific input. When this inscrutable AI used in models connected with real life mission critical systems (financial markets, healthcare systems, news systems etc) and the internet, security issues arise. Indeed, it begins to raise even more questions than provide answers. Now that AI is practically used everywhere - even to detect anomalies in cybersecurity, it is somewhat scary that a technology which is so unpredictable can be used to protect our systems. Examples of poor machine learning design Some of the examples James presented that caught our attention were: Microsoft chatbot Tay- Tay was originally intended to learn language by interacting with humans on Twitter. That sounds all good and very noble - until you realise that given the level of toxic discourse on Twitter, your chatbot will quickly turn into a raving Nazi with zero awareness it is doing so.  Machine learning used for risk assessment and criminal justice systems have incorrectly labelled Black defendants as “high risk” -  at twice the rate of white defendants. It’s time for a more holistic approach to cybersecurity Mickens further adds that we need a more holistic perspective when it comes to security. To do this,, developers should ask themselves not only if a malicious actor can perform illicit actions on a system,  but also should a particular action on a system be possible and how can the action achieve societally-beneficial outcomes. He says developers have 3 major assumptions  while deploying a new technology: #1 Technology is Value-Neutral, and will therefore automatically lead to good outcomes for everyone #2 New kinds of technology should be deployed as quickly as possible, even if we lack a general idea of how the technology works, or what the societal impact will be #3 History is generally uninteresting, because the past has nothing to teach us According to Mickens developers assume way too much.  In his assessment, those of us working in the industry take it for granted that technology will always lead to good outcomes for everyone. This optimism goes hand in hand with a need for speed - in turn, this can lead us to miss important risk assessments, security testing, and a broader view on the impact of technology not just on individual users but wider society too. Most importantly, for Mickens, is that we are failing to learn from mistakes. In particular, he focuses on IoT security. Here, Mickens points out, security experts are failing to learn lessons from traditional network security issues. The Harvard Professor has written extensively on this topic - you can go through his paperon IoT security here. Perhaps Mickens talk was intentionally provocative, but there are certainly lessons - if 2018 has taught us anything, it’s that a dose of scepticism is healthy where tech is concerned. And maybe it’s time to take a critical eye to the software we build. If the work we do is to actually matter and make a difference, maybe a little negative is a good thing. What do you think? Was Mickens assessment of the tech world correct? You can watch James Mickens whole talk at Youtube UN on Web Summit 2018: How we can create a safe and beneficial digital future for all 5 ways artificial intelligence is upgrading software engineering “ChromeOS is ready for web development” – A talk by Dan Dascalescu at the Chrome Web Summit 2018

Salesforce informed its customers that it was facing a major issue with its service, early Friday morning, and mentioned that it was working towards resolving the issue soon. The popular cloud-based software company experienced an outage due to its faulty database script after the company made changes to its production environment. Due to this, users got access to a broad amount of data than intended where they could see all the company’s data irrespective of the permissions. Salesforce said that the outage, which began on Friday and lasted just over 15 hours, is over - although some may experience a few issues as the platform gets back up to speed. Salesforce’s chief technology officer and a co-founder, Parker Harris, acknowledged the issue at 12:40 p.m. Eastern time the same day, and tweeted that Salesforce employees were working on the problem. https://twitter.com/parkerharris/status/1129426438325587969 According to reports on Reddit, users not only received read access but also received write permissions, thus, making it easy for malicious employees to steal or tamper with a company's data. Salesforce said the script only impacted customers of Salesforce Pardot or have used Pardot in the past. According to The Register, “To deal with the mess, Salesforce's IT team has denied all access to more than 100 cloud instances that host Pardot users, shutting out everyone else using those same systems, whether or not they were using Pardot.” Customers who were not affected may have also experienced certain service disruptions including customers using Marketing Cloud integrations. https://twitter.com/sfdcmitch/status/1129403764513787905 Salesforce customers in Europe and North America were the most impacted by the company shutting down access to its own service. Salesforce said, “We have started unblocking customers who were not affected by the permission issues.” https://twitter.com/sfdcmitch/status/1129403764513787905 https://twitter.com/RealSalesAdvice/status/1129421822007566336 On the 18th, at 5.40 a.m. Eastern time, Salesforce, on its status page, announced that access had been restored for administrators of all organizations that had been affected by the permission issues. “We are preparing a set of instructions for admins that may need guidance on how to manually restore those permissions. As soon as the instructions are final, we will inform admins via an email that will contain a link to the instructions,” the company said. The company further updated: “We have restored administrators' access to all affected orgs as of 08:04 UTC. We have prepared a set of instructions for admins that may need guidance on how to manually restore those user permissions. We notified admins via an email that contained a link to the instructions. A subset of admins may still be experiencing issues such as logging in to their orgs, modifying perms that are uneditable, or timeouts.” To know more about this in detail, visit Salesforce’s status page. DockerHub database breach exposes 190K customer data including tokens for GitHub and Bitbucket repositories Facebook confessed another data breach; says it “unintentionally uploaded” 1.5 million email contacts without consent Justice Department’s indictment report claims Chinese hackers breached business  and government network

This Monday, the community behind OnionShare has released its next major version, OnionShare 2. This release comes with macOS sandbox enabled by default, support for next-generation onion services, several new translations, and more. OnionShare is a free, open-source tool which allows users to share and receive files securely and anonymously using Tor onion services. Following are some of the updates introduced in OnionShare 2: The macOS sandbox enabled by default The macOS sandbox is enabled by default in OnionShare 2. This will prevent hackers from accessing data or running programs on user computers, even if they manage to exploit a vulnerability in OnionShare. Next generation Tor onion addresses OnionShare 2 improves security by using next-generation Tor onion service also known as v3 onion services. These next-generation Tor onion services provide onion addresses, which are unguessable address to share. These addresses look like this lldan5gahapx5k7iafb3s4ikijc4ni7gx5iywdflkba5y2ezyg6sjgyd.onion. Users can use v2 onion addresses if they want, by navigating to Setting and selecting “Use legacy addresses”. OnionShare addresses are ephemeral by default As soon as the sharing is complete, OnionShare address will completely disappear from the internet as these addresses are intended for one-time use. This behavior is enabled by default that you may want to change in case you want to share the files with a group of people. You can do that by going to the Settings menu and unchecking the "Stop sharing after files have been sent" option. Public OnionShare addresses By default, OnionShare addresses look like this http://[tor-address].onion/[slug]. In this format, the slug represents random words out of a list of 7,776 words. Even if the attacker figures out the tor-address part, they still won’t be able to download the files you are sharing or run programs on your computer. They need to know the slug, which works here as a password. But since this slug is only of two words, and the wordlist OnionShare uses is public, attackers can guess it. With this Public mode enabled, the OnionShare address will look like http://[tor-address].onion/, and the server will remain up no matter how many 404 errors it gets. OnionShare 2 comes with a Public mode that allows you to publicly share an OnionShare address. To enable this mode, just go to the Settings menu and check the box next to “Public mode”. OnionShare 2 is translated to 12 languages OnioShare 2 is translated into twelve new languages. These languages are Bengali, Catalan, Danish, French, Greek, Italian, Japanese, Persian, Portuguese Brazil, Russian, Spanish, and Swedish. You can select these languages from a dropdown. Read the complete list of updates in OnionShare 2 shared by Micah Lee, a computer security engineer. Understand how to access the Dark Web with Tor Browser [Tutorial] Brave Privacy Browser has a ‘backdoor’ to remotely inject headers in HTTP requests: HackerNews Signal introduces optional link previews to enable users understand what’s behind a URL

This Thursday a California federal judge granted warrants to the FBI to take down several websites providing DDoS attack services. The domains have been seized by the FBI just before Christmas Holidays. This is a season where hackers have done DDoS attacks in the past. The attacks are mainly targeted towards gaming services like PlayStation Network, Xbox, Steam, EA Online, etc. According to the document, these 15 ‘booter’ websites were taken down: anonsecurityteam.com critical-boot.com defianceprotocol.com ragebooter.come. str3ssed.me bullstresser.net quantumstress.net booter.ninja downthem.org netstress.org Torsecurityteam.org Vbooter.org defcon.pro request.rip layer7-stresser.xyz According to the filed affidavits, three men were charged, Matthew Gatrel, 30 and Juan Martinez, 25 from California; and David Bukoski, 23 from Alaska, for operating the websites. U.K.’s National Crime Agency, Netherlands Police, and the Department of Justice, USA along with companies like Cloudflare, Flashpoint, and Google have made joint efforts for the takedown. This takedown will most likely soon follow with arrests. As per the affidavit, some of these sites were capable of attacks exceeding 40 Gigabits per second (Gbit/s), enough to render some websites dead for a long time. Hackers have stated previously to the Telegraph that the rationale behind attacks on gaming websites on Christmas season is about the holiday spirit. They say that Christmas is not about “children sitting in their rooms and playing games, it is about spending time with their families.” What is a DDoS attack? DDoS attacks have long been a problem dating back to the 70’s. An attacker infects and uses multiple machines to target a network service and flood it with packets of useless data so that legitimate users are denied service. The goal of these attacks is to temporarily make the target services unavailable to its users. This story was initially reported by TechCrunch. Twitter memes are being used to hide malware An SQLite “Magellan” RCE vulnerability exposes billions of apps, including all Chromium-based browsers Hackers are our society’s immune system – Keren Elazari on the future of Cybersecurity

A research done by China's Netlab 360 revealed thousands of routers manufactured by the Latvian company MikroTik to be compromised by a malware attacking the Winbox, a Windows GUI application. This vulnerability allows gaining access to an unsecured router. The Winbox vulnerability was revealed in April this year and MicroTik had also posted a software update for the same. However, researchers found that more than 370,000 MikroTik devices they identified on the Internet were still vulnerable. According to a report by Netlab 360's Genshen Ye, “More than 7,500 of them are actively being spied on by attackers, who are actively forwarding full captures of their network traffic to a number of remote servers. Additionally, 239,000 of the devices have been turned into SOCKS 4 proxies accessible from a single, small Internet address block.” Prior to the MicroTik attack, WikiLeaks revealed a vulnerability from the CIA's ‘Vault7’ toolkit. According to WikiLeaks, the CIA Vault7 hacking tool Chimay Red involves 2 exploits, including Winbox Any Directory File Read (CVE-2018-14847) and Webfig Remote Code Execution Vulnerability. Attacks discovered on the MicroTik routers Previously, researchers at Trustwave also had discovered two malware campaigns against MikroTik routers based on an exploit reverse-engineered from a tool in the Vault7 leak. #1 Attack targeting routers with CoinHive Malware The first attack targeted routers in Brazil with CoinHive malware. The attack injected the CoinHive JavaScript into an error page presented by the routers' Web proxy server. It further redirected all Web requests from the network to that error page. However, in routers affected by this type of malware found by the Netlab 360 team, all the external web resources, including those from coinhive.com necessary for web mining, are blocked by the proxy ACLs (access control lists) set by attackers themselves. #2 Attack that turns affected routers into a malicious proxy network The other attack, discovered by the Netlab 360 team, has turned affected routers into a malicious proxy network. This was done by using the SOCKS4 protocol over a very non-standard TCP port (4153).  Ye said that “Very interestingly, the Socks4 proxy config only allows access from one single net-block, 95.154.216.128/25.” Most of the traffic is said to be going to 95.154.216.167, an address associated with a hosting service in the United Kingdom. This attack includes the addition of a scheduled task to report the router's IP address back to the attacker to help maintain the persistence of the SOCKS proxy if the router is rebooted. Eavesdropping on routers NetLab 360 researchers also discovered that more than 7,500+ victims are being actively eavesdropped and were largely streaming network traffic. This includes FTP and emails focused traffic, as well as some traffic associated with network management. Majority of the streams, almost 5,164 of them, were being sent to an address associated with an ISP in Belize. Attackers have leveraged MikroTik's built-in packet-sniffing capabilities for eavesdropping over the network. Here, the sniffer, which uses the TZSP protocol, can send a stream of packets to a remote system using Wireshark or other packet capture tools. To know more about this news in detail, visit the Netlab 360 blog. Google’s Protect your Election program: Security policies to defend against state-sponsored phishing attacks, and influence campaigns Homebrew’s Github repo got hacked in 30 mins. How can open source projects fight supply chain attacks? Apache Struts faces code execution flaw risking enterprises to attacks

ACME (Automated Certificate Management Environment) is no longer just a Let's Encrypt effort as it is now standardized by the Internet Engineering Task Force (IETF). The ACME protocol can be used by a Certificate Authority (CA) to automate the process of verification and certificate issuance. The open-source Let's Encrypt project has been an innovating force on the security landscape over the last several years. It provides millions of free SSL/TLS certificates to help secure web traffic. Aside from the disruptive model of providing certificates for free, Let's Encrypt has also helped to pioneer new technology to help manage and deliver certificates as well, including the Automated Certificate Management Environment (ACME). Let's Encrypt is a non-profit effort that was announced in November 2014 and became a Linux Foundation Collaborative Project in April 2015. Let's Encrypt exited its beta period in April 2016 and currently is helping to secure over 43 million websites."The protocol also provides facilities for other certificate management functions, such as certificate revocation," as per the IETF draft of the ACME standard states. The ACME protocol being standardized at the IETF is version 2 of the protocol and benefits from the wider participation of other internet organizations' viewpoint on certificate management, beyond Let's Encrypt. Though the IETF standardization process is a multi-stakeholder effort, Josh Aas, Executive Director and Co-Founder of Internet Security Research Group (ISRG) and Let's Encrypt, noted that the process has gone as expected with no real surprises. "We expect the standardization process to conclude in the next few months," Josh mentioned on the blog. Josh said that the ACME v1 protocol is what Let's Encrypt uses today, and version 2 will be standardized by the IETF and supported by Let's Encrypt as of January 2018. The main difference between the two versions is the order of operations. "In v1, clients authorize a set of domains and then request a certificate," Aas said. "In v2 clients request a certificate and then authorize domains for the certificate. The latter ordering offers more flexibility to us and other CAs who might be interested in using ACME." As a Certificate Authority (CA), to date Let's Encrypt has only provided Domain Validated (DV) certificates. DV certificates do not specifically identify or validate the organization using the certificate, but rather validate a request against a domain registry. In contrast, an Organization Validated (OV) certificate identifies the organization and validates the identity against a business registry. An Extended Validation (EV) provides the highest level of validation for an organization and involves a comprehensive vetting process. "ACME v1 was designed primarily with DV issuance in mind," Aas said. "ACME v2 can probably not be used to issued OV or EV certificates on its own, but it can play a role in issuing OV or EV certificates." Aas added that ACME V2 could potentially be used in OV and EV certificate issuance by automating the parts of the validation process that can be automated. While Let's Encrypt will be making use of the IETF ACME v2 protocol, other Certificate Authorities are taking a cautious approach. "Symantec offers an automation agent, SSL Assistant Plus, which implements a proprietary certificate lifecycle protocol," Rick Andrews, Symantec Distinguished Engineer told, "We follow the ACME development discussions in the IETF, and are considering adding support for the ACME protocol." Google’s Adiantum, a new encryption standard for lower-end phones and other smart devices Microsoft open sources (SEAL) Simple Encrypted Arithmetic Library 3.1.0, with aims to standardize homomorphic encryption 4 Encryption options for your SQL Server  

On 13th February, the OpenSSL team released a blog post outlining the changes that users can expect in the OpenSSL 3.0 architecture and plans for including a new FIPS module. Architecture changes in OpenSSL 3.0 ‘Providers’ will be introduced in this release which will be a possible replacement for the existing ENGINE interface to enable more flexibility for implementers. There will be three types of Providers: the “default” Provider will implement all of the most commonly used algorithms available in OpenSSL. The “legacy” Provider will implement legacy cryptographic algorithms and the “FIPS” Provider will implement FIPS validated algorithms. Existing engines will have to be recompiled to work normally and will be made available via both the old ENGINE APIs as well as a Provider compatibility layer. The architecture will include Core Services that will form the building blocks usable by applications and providers. Providers in the new architecture will implement cryptographic algorithms and supporting services. It will have implementations of one or more of the following: The cryptographic primitives (encrypt/decrypt/sign/hash etc)  for an algorithm Serialisation for an algorithm Store loader back ends   A Provider may be entirely self-contained or it may use services provided by different providers or the Core Services.     Protocol implementations, for instance TLS, DTLS.  New EVP APIs will be provided in order to find the implementation of an algorithm in the   Core to be used for any given EVP call.  Implementation agnostic way will be used to pass information between the core library and the providers.  Legacy APIs that do not go via the EVP layer will be deprecated. The OpenSSL FIPS Cryptographic Module will be self-contained and implemented as a dynamically loaded provider. Other interfaces may also be transitioned to use the Core over time  A majority of existing well-behaved applications will just need to be recompiled. No deprecated APIs will be removed in this release You can head over to the draft documentation to know more about the features in the upgraded architecture. FIPS module in OpenSSL 3.0 The updated architecture incorporates the FIPS module into main line OpenSSL. The module is dynamically loadable and will no longer be a separate download and support periods will also be aligned. He module is a FIPS 140-2 validated cryptographic module that contains FIPS validated/approved cryptographic algorithms only. The FIPS module version number will be aligned with the main OpenSSL version number. New APIs will give applications greater flexibility in the selection of algorithm implementations. The FIPS Provider will implement a set of services that are FIPS validated and made available to the Core. This includes: POST: Power On Self Test KAT: Known Answer Tests Integrity Check Low Level Implementations Conceptual Component View of OpenSSL 3.0 Read the draft documentation to know more about the FIPS module in the upgraded architecture. Baidu Security Lab’s MesaLink, a cryptographic memory safe library alternative to OpenSSL OpenSSL 1.1.1 released with support for TLS 1.3, improved side channel security Transformer-XL: A Google architecture with 80% longer dependency than RNNs    

The State bank of India, the largest bank of the nation leaked data of millions of its account holders. In the SBI data leak, Information like bank balances and recent transactions were visible online due to the leak. As per a TechCrunch report, two months of data was stored on a Mumbai based data center. An SMS and call based system was used by customers to query information about their bank accounts. The SBI server was not password protected allowing anyone with an internet connection to access such data if they knew where to find the data. It is unclear as to how long the server was unprotected but a security researcher found about this and reported it to TechCrunch. SBI Quick is a service that enables SBI customers to perform various actions with their bank account via SMS, miss calls etc. Customers can then get information like balance, recent transactions on their phone. For people not using a smartphone, this is very useful. The report says that the back-end SMS system was exposed leading to the SBI data leak. Since the server was not password protected, information like phone number, bank balance, recent transactions, and even partial account numbers were exposed. Speaking to TechCrunch, security researcher Karan Saini said: “The data available could potentially be used to profile and target individuals that are known to have high account balances.” He added that knowing a phone number “could be used to aid social engineering attacks — which is one the most common attack vector here with regard to financial fraud.” The report also says that the server has been secured now. GDPR complaint claims Google and IAB leaked ‘highly intimate data’ of web users for behavioral advertising How to protect your VPN from Data Leaks A WordPress plugin vulnerability is leaking Twitter account information of users making them vulnerable to compromise

Yesterday, the founder of QubesOS and Invisible Things, Joanna Rutkowska announced her resignation from the organization. She shared on the QubesOS’ blog, that she has joined Golem Project as a Chief Strategy Officer, also doubling as the Chief Security Officer. Joanna Rutkowska has been working on several fields of computer security engineering over the past 10 years. Her projects include desktop systems security, Qubes OS, virtualization security, and other hardware-enforced security mechanisms, such as Intel vPro technologies, their vulnerabilities, as well as how they could be used to build more secure systems. Prior to these, her primary focus was on kernel-mode rootkits and stealth malware (e.g. Blue Pill), including both offensive as well as defensive research. In her post on QubesOS, she said, “Earlier this year, I decided to take a sabbatical. I wanted to reflect on my infosec work and decide what I would like to focus on in the coming years. As you probably know, I’ve spent the last nine years mostly fighting the battle to secure the endpoint, more specifically creating, developing, architecting, and promoting Qubes OS, as well as the more general concept of ‘Security through Distrusting’.” QubesOS: A security-oriented FOSS Qubes is a free and open-source software (FOSS), which means that everyone is free to use, copy, and change the software in any way. It also means that the source code is openly available so others can contribute to and audit it. Joanna says, “Over these past nine years, Qubes OS has grown from a research-inspired proof-of-concept into a reasonably mature, large open-source project with dozens of contributors and tens of thousands of users, including some high-profile security experts.” She highlighted two challenges for Qubes, firstly, improving hardware compatibility and UX and secondly, the trustworthiness of the x86 platform. From QubesOS to the Golem Project Despite the challenges in QubesOS, Joanna decided to switch to Golem as she believes endpoint device security has reasonably matured and the QubesOS project is in good hands. She sees cloud security as the next big challenge on this decade. She wrote, “While I still believe that the security of our digital lives starts and ends with the trustworthiness of the client devices we use”. “I recognize that the state of endpoint device security has significantly improved over the past decade. At the same time, most of our data and activities have migrated from local devices to the cloud.”, she added. She highlighted some fundamental problems with cloud trustworthiness, which include: The service providers who own our data (e.g. the vendor of your fitness tracking app), The hosting infrastructure owners, who can both access our data as well as deny us use of the service at their discretion (e.g. AWS, Azure, GCP), and The networking infrastructure operators, who can also selectively cut us off from the services (e.g. to implement some form of censorship). She added, “These are very important problems, in my opinion, and I’d like to work now on making the cloud more trustworthy, specifically by limiting the amount of trust we have to place in it.” Following this, she mentioned that Golem is a very unique project for her. Golem has been on a mission to build a ‘decentralized computer’ out of a heterogeneous network of third-party provided computers. Golem was founded two years ago through a successful crowdfunding campaign that allowed it to build a strong development team. Golem’s funding model has eliminated two common obstacles--lack of money to hire enough people and the need to implement investors’ agenda-- faced by most of the budding tech startups. She said, “Most importantly, we (ITL), have already been working with Golem over the past year. During that time I’ve had enough time to get to know some of the key people in the project, understand their personal agendas, and conclude they might be very much inline with my own.” Talking about QubesOS’ future, Joanna said that not much will change. Also that Marek Marczykowski-Górecki, QubesOS’ Lead engineer has been effectively leading most of the day-to-day efforts with Qubes OS development since recent years. “Marek will continue to lead Qubes now, so I’m reassured about the future of the project. I will also remain as an advisor to the Qubes OS Project, as well as… its user, though I’ve recently also been embracing other systems, including – of course – the cloud”, she added. To know more about this news in detail, head over to Joanna Rutkowska’s post ‘The Next Chapter’ on QubesOS. Sir Tim Berners-Lee on digital ethics and socio-technical systems at ICDPPC 2018 Mozilla shares plans to bring desktop applications, games to WebAssembly and make deeper inroads for the future web Why does the C programming language refuse to die?

Identifying and authenticating users on the web is a cakewalk, thanks to the use of HTTP cookies. They allow website developers to store user’s website preferences or authentication tokens in the browsers. On the other hand, users can remain logged into a website without the need to re-enter their credentials again and again. Win-Win situation for everybody, right? Hold your horses. Due to the ever-evolving web, the way these cookies are implemented leave some space for hackers to perform intrusive attacks. Exploiting this domain, researchers at Belgium's Catholic University in Leuven bagged the Distinguished Paper prize this year at the Usenix Security Conference for their award-winning presentation on, “Who Left Open the Cookie Jar? A Comprehensive Evaluation of Third-Party Cookie Policies”. How did the team discover these web security loopholes? The authors managed to reveal an array of surprisingly devastating and never-seen-before tracking techniques. These techniques were to identify web-users who were using privacy tools that were supplied by browser-vendors and also third-party tracking-blocking tools. They tested a total of 7 browsers and 46 browser extensions. The tracking techniques used  Appcache API; "lesser-known HTML tags"; the Location response-header; various <meta> redirects; Javascript in PDF tables, Javascript's location.href property; and various service workers to track users across various sites. These techniques managed to bypass the privacy protection settings of the stock browser privacy protections. Apart from that, they also managed to fiddle with the latest privacy settings of Firefox. The techniques were advanced enough to work against popular cookie-blocking/ad-blocking/script-blocking browser extensions. Thankfully, there are no real-world concerns about these techniques being exploited. The researchers tipped off the browser vendors before they went public. This should stand as a lesson for browsers to be better equipped to defend against these tactics.  But until then, we're all vulnerable to websites using these tactics to track virtually everywhere! Here is a snapshot of the results that the team came across: Source: wholeftopenthecookiejar.eu Exploits and their Countermeasures as explored by the Researchers The team has not only come up with a list of 10 exploits but also have suggested measures to combat them. Here is the list, in brief, to give you a short gist- #1 Bypasses for the Opera AdBlocker discovered While the built-in ad blocker is enabled, the team discovered that requests to cross-site blacklisted domains can still be sent using various mechanisms in Opera. #2 Various bypasses discovered for the same-site cookie policy in Edge The same-site cookie policy implemented by Edge can be bypassed in multiple ways. #3 The option to block third-party cookies in Safari 10 does not exclude cookies set in the first-party context from future cross-site requests In Safari 10 when users enable "allow cookies from the current website only", cookies that are set in a first-party context are still included in cross-site requests. Safari blocks only the setting of cookies and not the sending of cookies. #4 Enabling the option to block third-party cookies in Edge has no effect Even when users enable the option to block third-party cookies in Edge, they are still included in all requests. #5 The option to block third-party cookies can be bypassed in Chromium through PDF files JavaScript embedded in PDF files can be used to send GET or POST requests to a cross-site domain. In Chromium, this bypasses the option to block third-party cookies. Affected Browsers are Chrome and Opera. #6 Cross-site requests initiated by PDF files bypass the WebExtentension API provided by Chromium Researchers found that extensions such as ad blockers or privacy extensions cannot intercept requests initiated by PDF files that are opened in Chrome or Opera through the WebExtension API. #7 Bypasses for the Firefox Tracking Protection discovered Firefox Tracking Protection can be bypassed easily by various mechanisms. Cross-site requests directed at blacklisted domains can be sent while this counter measurement is enabled. #8 Requests initiated by the AppCache API are not easily distinguished from requests initiated by browser background processes. Once again, in the Firefox browser, It is posing to be a difficult task for extension developers to distinguish requests initiated by the browsers background processes from requests initiated by websites. #9 Requests to fetch the favicon are not interceptable by Firefox extensions Looks like Firefox had a lot to fix in its extensions, as they were not able to intercept (cross-site) requests to fetch the favicon through the WebExtension API. But this stands fixed right on time. #10 Same-site cookie policy bypass discovered in Chromium Prerender functionality can be leveraged to initiate cross-site requests. This can be done including same-site cookies assigned the value strict. This bug was not detected anymore for multiple versions starting from Chrome 62, however, the bug returned in Chrome 66, 67 and 68. You can read the entire catalog to understand how your cookies are at stake (pun intended). The browser vendors have been made aware of these bugs and solutions have been proposed to rectify browser API’s and tools to deal with these exploits. Along with the aforementioned reports, wholeftopenthecookiejar.eu includes a breakdown of every test that researchers carried out against each of the 7 browsers, 46 extensions, and what version. You can read the paper presented by Gertjan Franken, Tom Van Goethem and Wouter Joosen for an inside view of why they won the award and we are sure you will agree with the same! 10 great tools to stay completely anonymous online Mozilla’s new Firefox DNS security updates spark privacy hue and cry Top 5 cybersecurity trends you should be aware of in 2018

OpenStreetMap Foundation (OSMF), the world’s largest collaborative mapping community, saw some unusual rise in signups for their memberships, in November 2018. Guillaume Rischard, an MWG(Members of the Working Group) member (and then-board candidate), detected that a large group of OSMF membership applications arrived under suspicious circumstances just when the window for eligibility for voting in the 2018 board election was closing. He later reported this issue to the board on 20th November 2018. Rischard along with another  OSMF MWG member, Steve Friedl released an investigation report on this issue, on 26th December 2018. The report was released to other OSMF members exactly a month later, on 26th Jan 2019. The OpenStreetMap Foundation is a non-profit company registered in England and Wales, “supporting, but not controlling, the OpenStreetMap Project”. The OSMF calls for an online general meeting once a year, where they elect new members for the board of directors. The board, however, did not pass a circular resolution that would have rejected these signups. The Membership Working Group (MWG), whose duties include the administration of OSMF memberships, undertook an investigation into the circumstances around this matter. According to the report, some of the observations that were brought to light include: All were Associate members; there’s usually a mix of membership types. All had @gmail.com addresses. Almost none provided OSM usernames; this is very unusual. Many were associated with the IP address of GlobalLogic, an outsourcing firm in India operating in the OSM/mapping world. All came in at the last minute in a very concentrated manner. Rischard in his email addressing his fellow OSMF members wrote, “We have uncovered evidence that the company behind the campaign, GlobalLogic, is not being truthful, and that the members did not sign up individually. GlobalLogic has provided versions of the event that are contradictory and not credible. We do not know the motivations for this campaign, but strongly suspect that this was an attempt, luckily unsuccessful, to influence the recent OSMF board election.” In their report, they have stated that “these new members were not eligible to vote in the 2018 AGM, and unless they renew again next year, probably won’t be able to vote in December 2019.” To know more about this news in detail, read the report, “Investigation into the Unusual Signups”. SEC’s EDGAR system hacked; allowing hackers to allegedly make a profit of $4.1 million via insider trading Hyatt Hotels launches public bug bounty program with HackerOne Black Hat hackers used IPMI cards to launch JungleSec Ransomware, affects most of the Linux servers.

Last week, Mastodon 2.8, a self-hosted social media service, was shipped with Keybase’s brand new proof system. Yesterday, the team behind Keybase announced that this new proof system is now available for all Mastodon servers. With this update, any community will be able to cryptographically connect their profiles to Keybase. https://twitter.com/malgorithms/status/1117888468544147456 Keybase is a free security app for groups, communities, families, and friends using which you can affirm your identity across the web. At its core, Keybase is a key directory that maps social media identities to encryption keys. Users can also have an encrypted chat with Keybase’s end-to-end chat service called Keybase Chat. With Keybase, users can prove a “link” between online identities such as Twitter or Reddit account and their encryption keys. So, instead of relying on a system like OAuth, identities are proven by posting a signed statement on the account a user wants to prove ownership of. For instance, a user just needs to enter their Twitter handle in the Keybase app following which a signed tweet is generated and is sent to Twitter. Once the tweet is posted, the user returns to the Keybase app. This mechanism makes identity proofs publicly verifiable instead of having to trust that the service is truthful. Though this method is quick and easy, it does have some limitations. Keybase app automatically generates the verification tweet, which users are expected to post. However, the user can edit these tweets. The Keybase team has now updated the proof system, which solves this problem. When a user claims on Keybase that they are a user on a site, they are redirected to that particular site. The verification is then completed in just two steps: Source: Keybase The site will then show the following row, signaling that the user is verified: Source: Keybase To read the full announcement, visit Keybase’s official website. Mastodon 2.7, a decentralized alternative to social media silos, is now out! Mastodon 2.5 released with UI, administration, and deployment changes 5 ways to reduce App deployment time

Coinhive, an in-browser Monero cryptocurrency miner, announced that it would be shutting down all its operations next week on March 8, 2019. Users will be given time until April 30th for withdrawing any remaining Monero from their accounts. Launched in 2017, Coinhive service provided ways to mine cryptocurrency in the background of a website, turning visitors’ processing power directly into cash. The company in their blog post mentioned reasons for the service closure including the fall in the value of Monero over the past year. Coinhive said, "The drop in hash rate (over 50%) after the last Monero hard fork hit us hard. So did the 'crash' of the cryptocurrency market with the value of XMR depreciating over 85% within a year. The company further mentions, “This and the announced hard fork and algorithm update of the Monero network on March 9 has led us to the conclusion that we need to discontinue Coinhive." Security researcher Troy Mursch said, “Coinhive had a market share of 62 percent in August 2018.” According to an academic paper, the company was making in an estimated $250,000 per month up until last summer, the ZDNet reports. https://twitter.com/bad_packets/status/1030201187381927936 Jérôme Segura, malware researcher at Malwarebytes told ZDNet “While 'cryptojacking' or 'drive-by mining' dominated the threat landscape in late 2017 and early 2018, it took a backseat for the rest of the year, with the notable exception of some campaigns powered by a large number of compromised IoT devices (i.e. MikroTik exploits).” “Some sites were upfront with visitors about their use of the software, most notably the news website Salon and UNICEF, but countless others either didn’t disclose the fact they were using it or saw the Javascript code added without their knowledge as part of a “cryptojacking” malware attack. Eventually, ad-blockers and anti-virus software learned to identify and block such code, so that users could avoid having their CPUs used and their batteries drained by the software”, The Verge reports. To know more about the Coinhive closure in detail, head over to Coinhive’s official blog post. Hackers are our society’s immune system – Keren Elazari on the future of Cybersecurity Winbox vulnerability in MicroTik routers forwarding traffic to attackers, say researchers at NetLabs 360 Cryptojacking is a growing cybersecurity threat, report warns

It was later last month on 19th March, when Norsk Hydro ASA, a Norwegian and one of the world’s largest aluminum producer firm, had to halt its production due to a cyber attack that impacted its operations across Europe and the U.S. Earlier this week, the firm shared a video on YouTube, highlighting how the employees of Magnor Extrusion in Norway (one of the 160 hydro sites affected by the cyber attack) went out of their way to keep the plant up and running during crucial times. “With a tremendous effort of our colleagues at Magnor, the plant has managed to get production up to 100% of normal production, despite operating in normal mode”, states the video. https://twitter.com/NorskHydroASA/status/1110981944513388544 Olav Schulstad, Production Manager at Magnor mentions that people have been very supportive in the firm and volunteered to help without even being asked. Also, Frode Halteigen, an operator at Magnor, mentioned in the video that all the employees including the people on the shop floor sacrificed time with their families and weekends, to be able to get the operations back in shape. https://www.youtube.com/watch?v=S-ZlVuM0we0&feature=youtu.be                                     Cyber Attack on Hydro Magnor In fact, many employees also took unconventional roles to help out on the shop floor. For instance, Mads Madsstuen is an Area Sales Manager but is helping out with the shop floor in the plant. https://twitter.com/fabrikkfrue/status/1113426747809247232 https://twitter.com/GossiTheDog/status/1113442133267091456 Post-attack, Norsk Hydro kept providing updates on the attack to inform the public about progress made in securing safe and stable operations across the company. “With a systematic approach our experts are step by step restoring business-critical IT based functions to ensure stable production, serve our customers and limit financial impact, while always safeguarding our employee’s safety,” said Eivind Kallevik, CFO, Norsk Hydro in an update posted on March 21st. As per the update, the root cause of the problems had been detected, and a cure had been identified. Hydro’s experts have been working since then on bringing the virus infected systems back to a pre-infected state. The firm also called in experts from Microsoft and other IT security partners to help Hydro take all necessary actions in a systematic way to get business back in normal operation. “Hydro has experienced good progress over the weekend and continues to approach normal operations after the cyber attack. Our focus so far has been technical recovery. This week we are moving on to business and operation recovery”, Hydro updated earlier this week. Norsk Hydro lost over $40 million in the week following the cyber attack as it incapacitated most of its operations. It decided to switch the units to manual operations after the company’s IT systems had been attacked and blocked with ransomware, called LockerGoga. LockerGoga is a new and evolving ransomware that could have infected the systems at Norsk via stolen remote desktop credentials, phishing or a nonupdated targeting software reports Chemistry World. Other two US-based chemical companies, namely, Momentive and Hexion, have also suffered cyber attacks due to LockerGoga. The video states that thousands of people at Hydro around the world, are working day and night to fix the operations, showing a “true display of care, courage, and collaboration”. It sheds light on the indefatigable fervor of the Nosk Hydro employees and how the firm has managed to foster a work culture that many companies should aspire to. The video also shows behind-the-scenes of how challenging it becomes for the employees within a company to recuperate with the reality of such extensive cyber attacks in terms of both financial and operational constraints. Resecurity reports ‘IRIDUIM’ behind Citrix data breach, 200+ government agencies, oil and gas companies, and technology companies also targeted A security researcher reveals his discovery on 800+ Million leaked Emails available online Security researcher exposes malicious GitHub repositories that host more than 300 backdoored apps