Tech News - Security

Malware or a malicious software is designed to harm user’s computer systems in multiple ways. Over the years, hackers and attackers have implemented various methods to inject viruses, worms, Trojans, and spyware to collapse a computer system. To combat against the current age malware, you must know how a malware function and what techniques attackers use to launch a malware within a system. Some advanced malware techniques include: Privilege Escalation is how a malware attempts to increase its reach within the system. Persistence Methods keep malware in execution state for a longer time. Data Encoding basically explores ways to hide the intent of the malware. Covert launching techniques help in launching malware in the most stealthy manner. Out of the three, privilege escalation is a network intrusion method where malware can enter the system via programming errors or design flaws. With the help of these channels, the attacker can have a direct access to the network and its associated data and applications. Watch the video below by Munir Njenga to know all about privilege escalation and its types in depth using real world examples. https://www.youtube.com/watch?v=Qzlkw5sJUsw About Munir Njengar Munir is a technology enthusiast, cybersecurity consultant, and researcher. His skills and competencies stem from his active involvement in engagements that deliver advisory services such as network security reviews, security course development, training and capacity building, mobile and internet banking security reviews (BSS, MSC, HLR/AUC, IN, NGN, GGSN/SGSN), web applications, and network attack and penetration testing. To know more about privilege Escalation and to learn other malware analysis methods, check out our course titled ‘Advanced Malware Analysis’ to which this video belongs.

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

On 8th October, at it’s 'Fall Desktop Launch Event', Intel unveiled the 9th-generation Core i9-9900K, i7-9700K, and i5-9600K processors for desktops. With an aim to deliver ‘the best gaming performance’ in the word, the processors also come with fixes for the much controversial  Specter, Meltdown, and L1TF vulnerabilities. Major features of this launch include, #1 Security fixes for Specter, Meltdown, and LITF Faults In March 2018, Intel announced that they would be adding hardware protection to forthcoming CPUs protecting users against some of the processor's security flaws. These 'protective walls' added in the hardware would keep malicious code in a physically different location from areas of the CPU were speculative execution is taking place. Intel kept its word by announcing hardware mitigations in the 9th Gen CPU’s for Spectre/Meltdown. Former Intel CEO Brian Krzanich stated in a press release, "We have redesigned parts of the processor to introduce new levels of protection through partitioning that will protect against both Variants 2 and 3. Think of this partitioning as additional “protective walls” between applications and user privilege levels to create an obstacle for bad actors." It has not been detailed what specific hardware changes were made to add protection. It was noted that the previous software and microcode protections added would cause a performance hit on older CPUs. These new CPUs are powerful enough that any performance hit caused by these protections should not be noticeable. #2 Forgoing HyperThreading Intel is forgoing HyperThreading on some of the Core i9 parts. This will partly help make the product stack more linear. This could also possibly help mitigate one of the side-channel attacks that can occur when HyperThreading is in action. Disabling HyperThreading on the volume production chips, ensures that every thread on that chip is not competing for per-core resources. #3 Hardware Specifications Source: AnandTech Core i9-9900K The  Core i9-9900K processor is designed to deliver the best gaming performance in the world. Users can enable up to 220 FPS on Rainbow Six: Siege, Fortnite, Counter-Strike: Global Offensive and PlayerUnknown Battlegrounds. It comes with8 cores, 16 threads and a base frequency of 3.6GHz which can be boosted up to 5.0GHz. This processor is aimed at desktop-based enthusiasts and with a dual-channel DDR4 and up to 40 PCIe lanes. The i9-9900K is based off Intel’s 14nm process. Hyperthreading is an added bonus in this processor. Core i7-9700K The i7-9700K comes with 8 cores and 8 threads. With a  base clock speed is of 3.6 GHz (which can be boosted to 4.9 GHz on all cores), the processor comes without hyperthreading.  It can turbo up to 4.9 GHz only on a single core. The i7-9700K is meant to be the direct upgrade over the Core i7-8700K. While both chips have the same Coffee Lake microarchitecture, the 9700K has two more cores and slightly better turbo performance. That being said, it has less L3 cache per core at only 1.5MB per core. Core i5-9600K The  i5-9600K is clocked at a base frequency of 3.7 GHz and can be boosted up to 4.6 GHz. With 6 cores and 6 threads, it comes without Hyperthreading. This processor is really similar to the Core i5 of the previous generation, but with an added frequency for better performance. It would be interesting to see how these new processors will help in mitigating security flaws without impacting their performance. For detailed information on each of the processors, you can head over to AnandTech. You could also check out BleepingComputer for additional insights. NetSpectre attack exploits data from CPU memory Intel faces backlash on Microcode Patches after it prohibited Benchmarking or Comparison Meet ‘Foreshadow’: The L1 Terminal Fault in Intel’s chips

Last week, the Git Project revealed a vulnerability, CVE-2018-17456, which can cause arbitrary code to be executed when a user clones a malicious repository. The new Git v2.19.1 has been released with a fix to this vulnerability. Also, backports in v2.14.5, v2.15.3, v2.16.5, v2.17.2, and v2.18.1 have been added. Users have been advised to update their clients in order to protect themselves. For those who have not yet updated, they can protect by simply avoiding submodules from untrusted repositories. This includes commands such as git clone --recurse-submodules and git submodule update. The community, in their post, mentions that neither GitHub.com nor GitHub Enterprise is directly affected by the vulnerability. However, as with previously discovered vulnerabilities, GitHub.com will detect malicious repositories and will reject pushes or API requests attempting to create them. Versions of GitHub Enterprise with this detection will be shipped on October 9th. About the CVE-2018-17456 vulnerability This vulnerability is similar to CVE-2017-1000117, as both are option-injection attacks related to submodules. In the previous attack, a malicious repository would ship a .gitmodules file pointing one of its submodules to a remote repository with an SSH host starting with a dash (-). The ssh program—spawned by Git—would then interpret that as an option. The new attack works in a similar way, except that the option-injection is against the child git clone itself. Learning from the previous attack, the researchers have audited all of the .gitmodules values and implemented stricter checks as appropriate. These checks should prevent a similar vulnerability in another code path. They also implemented detection of potentially malicious submodules as part of Git’s object quality checks, which was made much easier by the infrastructure added during the last submodule-related vulnerability. Products affected by the CVE-2018-17456 vulnerability GitHub Desktop GitHub Desktop versions 1.4.1 and older included an embedded version of Git that was affected by this vulnerability.  All GitHub Desktop users are encouraged to update to the newest version (1.4.2 and 1.4.3-beta0) available today in the Desktop app. Atom Atom included the same embedded Git and was also affected. Releases 1.31.2 and 1.32.0-beta3 include the patch. Users should ensure they have the latest Atom release by completing any of the following: Windows: From the toolbar, click “Help” -> “Check for updates” MacOS: From the menu bar, click “Atom” -> “Check for Update” Linux: Update manually by downloading the latest release from atom.io Git on the command line and other clients In order to be protected from the vulnerability, users must update their command-line version of Git and any other application that may include an embedded version of Git, as they are independent of each other. 4 myths about Git and GitHub you should know about 7 tips for using Git and GitHub the right way GitHub addresses technical debt, now runs on Rails 5.2.1

It's been a year since the Project zero team published the results of their research about the resilience of modern browsers against DOM fuzzing. They also published Domato, their DOM fuzzing tool that was used to find those bugs. The results of the research were astonishing since Apple Safari, or more specifically, WebKit (its DOM engine) did not fare well in this test. The team decided to revisit the project again using exactly the same methodology and exactly the same tools to see whether the browsers have managed to implement better security mechanisms. The Test Setup In the previous research, the fuzzing was initially done against WebKitGTK+ and then all the crashes were tested against Apple Safari running on a Mac. In this research, WebKitGTK+ version 2.20.2 was used. To improve the fuzzing process, a couple of custom changes were made to WebKitGTK+ . For instance: Building WebKitGTK+ with ASan (Address Sanitizer) is now possible Changed window.alert() implementation to immediately call the garbage collector instead of displaying a message window. Generally, when a DOM bug causes a crash, due to the multi-process nature of WebKit, only the web process would crash, but the main process would continue running. Code was added to crash the main process when the web process crashes The team created a custom target binary. Results Obtained After running the fuzzer for 100.000.000 iterations, the team discovered 9 unique bugs that were reported to Apple. The bugs are summarized in the table below. All of these bugs have been fixed at the time of release of this blog post.   Project Zero bug ID CVE Type Affected Safari 11.1.2 Older than 6 months Older than 1 year 1593 CVE-2018-4197 UAF YES YES NO 1594 CVE-2018-4318 UAF NO NO NO 1595 CVE-2018-4317 UAF NO YES NO 1596 CVE-2018-4314 UAF YES YES NO 1602 CVE-2018-4306 UAF YES YES NO 1603 CVE-2018-4312 UAF NO NO NO 1604 CVE-2018-4315 UAF YES YES NO 1609 CVE-2018-4323 UAF YES YES NO 1610 CVE-2018-4328 OOB read YES YES YES UAF = use-after-free. OOB = out-of-bounds Out of the 9 bugs found, 6 affected the release version of Apple Safari, directly affecting Safari users. While this is significantly less than the 17 bugs found a year ago, it is still a notable number, especially since the fuzzer has been public for a long time now. After the results were in, the team found that most of the bugs were sitting in the WebKit codebase for longer than 6 months, however, only 1 of them is older than 1 year. Also, the team notes that throughout the past year, their fuzzing process came up with 14 bugs but they cannot surely say if these bugs have been resolved or are still live. The Exploit performed on the bugs To prove that bugs like this can lead to a browser compromise, an exploit was written for one of them. Out of the 6 issues affecting the release version of Safari, the researchers selected the use-after-free issue to exploit. The details of this issue are well explained in Project Zero’s Blog post. The exploit was successfully tested on Mac OS 10.13.6 (build version 17G65). All the details of the exploit can be seen at bugs.chromium.org. An interesting aspect of this exploit is that, on Safari for Mac OS it could be written in a very "old-school' way due to lack of control flow mitigations on the platform. That being said, on the latest mobile hardware and in iOS 12, which was published after the exploit was already written, Apple introduced control flow mitigations by using Pointer Authentication Codes (PAC). The issues were reported to Apple between June 15 and July 2nd, 2018. On September 17th 2018, Apple published security advisories for iOS 12, tvOS 12 and Safari 12 which fixed all of the issues. Although the bugs were fixed at that time, the corresponding advisories did not initially mention them. The issues described in the blog post were only added to the advisories one week later, on September 24, 2018, when the security advisories for macOS Mojave 10.14 were also published. The researchers affirm that there were clear improvements in WebKit DOM when tested with Domato. However, the public fuzzer was still able to find a large number of bugs. This is worrying because if a public tool was able to find that many bugs, private tools can be even more effective in exploiting these bugs. To know more about this experiment, head over to Google Project Zero’s official Blog. Google Project Zero discovers a cache invalidation bug in Linux memory management, Ubuntu and Debian remain vulnerable Google, Amazon, AT&T met the U.S Senate Committee to discuss consumer data privacy, yesterday Ex-googler who quit Google on moral grounds writes to Senate about company’s “Unethical” China censorship plan

Facebook revealed last Friday that a major security breach compromised 50 million user accounts on Facebook. The security attack not only affected user’s Facebook accounts but also impacted other accounts that were linked to Facebook. The hackers had exploited Facebook’s “View As” feature that lets people see what their own profile looks like to someone else. The hackers had stolen Facebook access tokens to hack into other user’s accounts. These tokens provide hackers with full control over victim’s account, including logging into third-party applications that use Facebook Login. “We wanted to provide an update on the security attack that we announced last week. We fixed the vulnerability and we reset the access tokens for a total of 90 million accounts — 50 million that had access tokens stolen and 40 million that were subject to a “View As” look-up in the last year” wrote Guy Rosen, VP of product management. Resetting the tokens required users to login into their Facebook accounts again as well as re-login into any accounts or apps that use Facebook. As far as questions about the effects of this attack on the apps that used Facebook are concerned, Facebook is yet to find any impact. “We have now analyzed our logs for all third-party apps installed or logged in during the attack we discovered last week. That investigation has so far found no evidence that the attackers accessed any apps using Facebook Login”, states the Facebook post. All the developers leveraging the official Facebook SDKs along with people checking the validity of their users’ access tokens were automatically protected, on resetting the access tokens. However, to be extra careful, Facebook is developing a tool which will allow developers to manually identify users of the apps affected by the security breach so that they can be logged out. This will also prove to be beneficial for all those developers who don’t leverage Facebook’s SDKs or who don’t regularly check whether Facebook access tokens are valid. Additionally, Facebook recommends that developers always use Facebook Login security best practices as a guideline. It recommends that a developer use Facebook’s official SDKs for Android, iOS, and JavaScript, as these automatically check the validity of access tokens. These also force a fresh login every time the tokens are reset by Facebook, thereby protecting users accounts. Another thing to keep in mind is that Facebook wants developers to use the Graph API. This keeps the information updated regularly and makes sure that users are logged out of apps in case they show any Facebook session as invalid. “Security is incredibly important to Facebook. We’re sorry that this attack happened — and we’ll continue to update people as we find out more” reads the post. For more information, check out the official announcement. How far will Facebook go to fix what it broke: Democracy, Trust, Reality Ex-employee on contract sues Facebook for not protecting content moderators from mental trauma Did you know Facebook shares the data you share with them for ‘security’ reasons with advertisers?

Yesterday, FireEye revealed a new group of hackers named APT38, a financially motivated North Korean regime-backed group responsible for conducting destructive attacks against financial institutions, as well as for some of the world's largest cyber heists. FireEye Inc. is a cybersecurity firm that provides products and services to protect against advanced persistent threats and spear phishing. Earlier this year, FireEye helped Facebook find suspicious accounts linked to Russia and Iran on its platform and also alerted Google of election influence operations linked to Iranian groups. Now FireEye cybersecurity researchers released a special report titled APT38: Un-usual Suspects, to expose the methods used by the APT38 group. In the report, they said,“Based on observed activity, we judge that APT38's primary mission is targeting financial institutions and manipulating inter-bank financial systems to raise large sums of money for the North Korean regime.” The researchers also state that the group has attempted to steal more than $1.1 billion and were also responsible for some of the more high-profile attacks on financial institutions in the last few years.  Some of the publicly reported attempted heists attributable to APT38 include: Vietnam TP Bank in December 2015 Bangladesh Bank in February 2016 Far Eastern International Bank in Taiwan in October 2017 Bancomext in January 2018 Banco de Chile in May 2018 Sandra Joyce, FireEye’s vice president of global intelligence says, “The hallmark of this group is that it deploys destructive malware after stealing money from an organization, not only to cover its tracks, but [also]  in order to distract defenders, complicate the incident response process, and gain time to get out the door.” Some details of the APT38 targeting Since at least 2014, APT38 has conducted operations in more than 16 organizations in at least 11 countries. The total number of organizations targeted by APT38 may be even higher when considering the probable low incident reporting rate from affected organizations. The group is careful, calculated, and has demonstrated a desire to maintain access to a victim environment for as long as necessary to understand the network layout, required permissions, and system technologies to achieve its goals. On average, they have observed that APT38 remain within a victim network for approximately 155 days, with the longest time within a compromised environment believed to be almost two years. In just the publicly reported heists alone, APT38 has attempted to steal over $1.1 billion dollars from financial institutions. APT38 Attack Lifecycle FireEye researchers believe that APT38’s financial motivation, unique toolset, tactics, techniques and procedures (TTPs) observed during their carefully executed operations are distinct enough to be tracked separately from other North Korean cyber activity. The APT38 group overlaps characteristics with other operations, known as ‘Lazarus’ and the actor they call as TEMP.Hermit. On Tuesday, the U.S. government released details on malware it alleges Pyongyang’s computer operatives have used to fraudulently withdraw money from ATMs in various countries. The unmasking of APT38 comes weeks after the Justice Department announced charges against Park Jin Hyok, a North Korean computer programmer, in connection with the 2014 hack of Sony Pictures and the 2017 WannaCry ransomware attack. According to Jacqueline O’Leary, a senior threat intelligence analyst at FireEye, Park has likely contributed to both APT38 and TEMP.Hermit operations. However, the North Korean government has denied allegations that it sponsors such hacking. Reddit posts an update to the FireEye’s report on suspected Iranian influence operation Facebook COO, Sandberg’s Senate testimony Google’s Protect your Election program  

Last week, California’s Governor Jerry Brown passed a bill giving rise to a new law that will ban automated accounts, more commonly known as bots, from pretending to be real people in pursuit of selling products or influencing elections. The bill was approved on September 28 and will be effective from July 1, 2019. As per the California Senate, "This bill would, with certain exceptions, make it unlawful for any person to use a bot to communicate or interact with another person in California online with the intent to mislead the other person about its artificial identity for the purpose of knowingly deceiving the person about the content of the communication in order to incentivise a purchase or sale of goods or services in a commercial transaction or to influence a vote in an election.” The law will assist in tackling social media manipulation to determine foreign interference. Bots caused major issues during the 2016 U.S. Presidential elections and have ever since grown to be a menace that platforms like Twitter have been trying to combat. The 2016 U.S. Presidential elections saw Russian-controlled bots playing an active role in manipulating opinions, retweeting Donald Trump's tweets 470,000 times, and Hillary Clinton's fewer than 50,000 times. The main aim of this effort is to target bots that spread misinformation. Twitter said that it took down 9.9 million potentially spammy or automated accounts per week in May and has placed warnings on suspicious accounts. Twitter has also announced an update in its work on its "election integrity" project, ahead of the US mid-term elections in November. These include updating its rules regarding fake accounts and sharing stolen information. It said it would now take into account stock avatar photos and copied profile bios in determining whether an account is genuine. Robert Hertzberg, a state senator from California who pushed for the new law forcing bots to disclose their lack of humanity, told The New York Times he was the subject of a bot attack over a bail reform bill. So he decided to fight bots with bots by launching @Bot_Hertzberg in January. As per California law, the account discloses its automated nature. “*I AM A BOT.*” states the account’s Twitter profile. “Automated accounts like mine are made to misinform & exploit users. But unlike most bots, I'm transparent about being a bot.” To know more about this California Senate ’s bill in detail, check out the Senate bill. Sentiment Analysis of the 2017 US elections on Twitter Facebook, Twitter takes down hundreds of fake accounts with ties to Russia and Iran, suspected to influence the US midterm elections DCLeaks and Guccifer 2.0: How hackers used social engineering to manipulate the 2016 U.S. elections

The U.S. Justice Department filed a lawsuit against California yesterday after the California governor Jerry Brown signed the state’s Net Neutrality proposal into law. This was to restore open internet protections known as Net Neutrality, that requires internet service providers like AT&T, Comcast, and Verizon to treat all web traffic equally in the state. California’s Net Neutrality bill is a state-level response to the FCC’s decision to revoke the existing legislation earlier this year. The law that was set when President Obama was in office was scrapped after the Republicans took over leadership of the FCC in 2017.  Considered one of the toughest Net Neutrality bills in the U.S., it prevents ISPs from throttling traffic, and from charging websites for special access to internet users. It also bans “zero rating” on certain apps (where using certain apps would not count against a user’s data usage). The California Net Neutrality bill, namely, Senate No. 822  was approved by the State Assembly and the Senate, in August, despite receiving many protests. However, after the governor decided to enact the Net Neutrality proposal as a law yesterday, senior Justice Department officials sued them on the grounds that only the federal government, not state leaders, have the power to regulate Net Neutrality. Attorney General Jeff Sessions issued the following statement, for filing the complaint: “Once again the California legislature has enacted an extreme and illegal state law attempting to frustrate federal policy. The Justice Department should not have to spend valuable time and resources to file this suit today, but we have a duty to defend the prerogatives of the federal government and protect our Constitutional order. We are confident that we will prevail in this case—because the facts are on our side”. FCC Chairman Ajit Pai also issued a statement stating, “I’m pleased the Department of Justice has filed this suit. Not only is California’s Internet regulation law illegal, but it also hurts consumers.  The law prohibits many free-data plans, which allow consumers to stream video, music, and the like exempt from any data limits. They have proven enormously popular in the marketplace, especially among lower-income Americans. But notwithstanding the consumer benefits, this state law bans them.” Member of the California state and author of the state bill, Scott Wiener, tweeted his response to the lawsuit, saying that it’s just an attempt by the administration to block the state's initiatives. https://twitter.com/Scott_Wiener/status/1046585508472602624 Furthering the Net Neutrality debate, GOP proposes the 21st Century Internet Act California passes the U.S.’ first IoT security bill Like newspapers, Google algorithms are protected by the First amendment making them hard to legally regulate them

"Raise your game on merging kernel security fixes, you're leaving users exposed for weeks" -Jann Horn to maintainers of Ubuntu and Debian Jann Horn, the Google Project Zero researcher who discovered the Meltdown and Spectre CPU flaws, is making headlines once again. He has uncovered a cache invalidation bug in the Linux kernel. The kernel bug is a cache invalidation flaw in Linux memory management that has been tagged as CVE-2018-17182. The bug has been already reported to Linux kernel maintainers on September 12. Without any delay, Linux founder, Linus Torvalds fixed this bug in his upstream kernel tree two weeks ago. It was also fixed in the upstream stable kernel releases 4.18.9, 4.14.71, 4.9.128, and 4.4.157 and  3.16.58. Earlier last week, Horn released an "ugly exploit" for Ubuntu 18.04, which "takes about an hour to run before popping a root shell". The Bug discovered by Project Zero The vulnerability is a use-after-free (UAF) attack. It works by exploiting the cache invalidation bug in the Linux memory management system, thus allowing an attacker to obtain root access to the target system. UAF vulnerabilities are a type of ‘memory-based corruption bug’. Once attackers gain access to the system, they can cause system crashes, alter or corrupt data, and gain privileged user access. Whenever a userspace page fault occurs, for instance, when a page has to be paged in on demand, the Linux kernel has to look up the Virtual Memory Area (VMA) that contains the fault address to figure out how to handle the fault. To avoid any performance hit, Linux has a fastpath that can bypass the tree walk if the VMA was recently used. When a VMA is freed, the VMA caches of all threads must be invalidated - otherwise, the next VMA lookup would follow a dangling pointer. However, since a process can have many threads, simply iterating through the VMA caches of all threads would be a performance problem. To solve this, both the struct mm_struct and the per-thread struct vmacache are tagged with sequence numbers. When the VMA lookup fastpath discovers in vmacache_valid() that current->vmacache.seqnum and current->mm->vmacache_seqnum don't match, it wipes the contents of the current thread's VMA cache and updates its sequence number. The sequence numbers of the mm_struct and the VMA cache were only 32 bits wide, meaning that it was possible for them to overflow.  To overcome this, in version 3.16, an optimization was added. However, Horn asserts that this optimization is incorrect because it doesn't take into account what happens if a previously single-threaded process creates a new thread immediately after the mm_struct's sequence number has wrapped around to zero. The bug was fixed by changing the sequence numbers to 64 bits, thereby making an overflow infeasible, and removing the overflow handling logic.   Horn has raised concerns that some Linux distributions are leaving users exposed to potential attacks by not reacting fast enough to frequently updated upstream stable kernel releases. End users of Linux distributions aren't protected until each distribution merges the changes from upstream stable kernels, and then users install that updated release. Between these two points, the issue also gets exposure on public mailing lists, giving both Linux distributions and would-be attackers a chance to take action. As of today, Debian stable and Ubuntu releases 16.04 and 18.04 have not yet fixed the issue, in spite of the latest kernel update occurring around a month earlier. This means there's a gap of several weeks between the flaw being publicly disclosed and fixes reaching end users. Canonical, the UK company that maintains Ubuntu, has responded to Horn's blog, and says fixes "should be released" around Monday, October 1. The window of exposure between the time an upstream fix is published and the time the fix actually becomes available to users is concerning. This gap could be utilized by an attacker to write a kernel exploit in the meantime. It is no secret that Linux distributions don’t publish kernel updates regularly. This vulnerability highlights the importance of having a secure kernel configuration. Looks like the team at Linux needs to check and re-check their security patches before it is made available to the public. You can head over to Google Project Zero’s official blog page for more insights on the vulnerability and how it was exploited by Jann Horn. NetSpectre attack exploits data from CPU memory SpectreRSB targets CPU return stack buffer, found on Intel, AMD, and ARM chipsets Meet ‘Foreshadow’: The L1 Terminal Fault in Intel’s chips

ESET researchers stated that they have found evidence that 'Fancy Bear' (Russia-backed hackers group) is using ‘LoJax’ malware to target certain government organizations in Europe. This research was presented on Thursday at the 2018 Microsoft BlueHat conference. This is the first case of a UEFI rootkit recorded as ‘active’ and still in use. The researchers have not explicitly named the governments that have been targeted. They have only stated that the hackers were active in targeting the Balkans and some central and eastern European countries. This attempt to target european governments is another one of Fancy Bears tactics after hacking into the Democratic National Committee. The hackers had previously targeted senators, social media sites, the French presidential elections, and leaked Olympic athletes’ confidential medical files, which demonstrates their hacking abilities. The LoJax UEFI rootkit LoJax is known for its brutal persistence in making it challenging to remove from a system. It embeds itself in the computer’s firmware and launches when the OS boots up. Sitting in a computer’s flash memory,  LoJax consumes time, effort and extreme care to reflash the memory with a new firmware. In May 2018, Arbor Networks suggested that this Russian hacker group was utilizing Absolute Software's 'LoJack'- a legitimate laptop recovery solution- for unscrupulous means. Hackers tampered with the samples of the LoJack software and programmed it to communicate with a command-and-control (C2) server controlled by Fancy Bear, rather than the legitimate Absolute Software server. The modified version was named as LoJax to separate it from Absolute Software's legitimate solution. LoJax is implemented as a UEFI/BIOS module, to resist operating system wipes or hard drive replacement. This UEFI rootkit was found bundled together with a toolset that was able to patch a victim's system firmware and install malware at the system’s deepest level. In at least one recorded case, the hackers behind the malware were able to write a malicious UEFI module into a system's SPI flash memory leading to the execution of malicious code on disk during the boot process. ESET further added that the malicious UEFI module is being bundled into exploit kits which are able to access and patch UEFI/BIOS settings. Alongside the malware, three other tools were found in Fancy Bear's refreshed kit. A tool that dumps information related to PC settings into a text file A tool to save an image of the system firmware by reading the contents of the SPI flash memory where the UEFI/BIOS is located A tool that adds the malicious UEFI module to the firmware image to write it back to the SPI flash memory. The researchers affirm that the UEFI rootkit has increased the severity of the hacking group. However, there are preventative measures to safeguard your system against this notorious group of hackers. The Fancy Bear’s rootkit isn’t properly signed and hence a computer’s Secure Boot feature could prevent the attack by properly verifying every component in the boot process. This can be switched on at a computer’s pre-boot settings. For more insights on this news, head over to ZDNet. Microsoft claims it halted Russian spearphishing cyberattacks Russian censorship board threatens to block search giant Yandex due to pirated content UN meetings ended with US & Russia avoiding formal talks to ban AI enabled killer robots