Tech News - Security

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

Last week, the National Cyber Security Centre (NCSC) reported that they are investigating the exploitation, by Advanced Persistent Threat (APT) actors, of known vulnerabilities in VPN products. These VPN products are from vendors like Pulse secure, Palo Alto and Fortinet. It is an ongoing activity, targeted to the UK and other international organizations. According to NCSC, affected sectors include government, military, academic, business and healthcare. Vulnerabilities exist in several SSL VPN products As per the report, vulnerabilities exist in several SSL VPN products that can allow an attacker to retrieve arbitrary files containing authentication credentials. An attacker can use these stolen credentials to connect to the VPN and change configuration settings or connect to further internal infrastructure. The report also highlights that unauthorized connection to a VPN can provide the attacker with the privileges needed to run secondary exploits aimed at accessing a root shell. Read Also: MITRE’s 2019 CWE Top 25 most dangerous software errors list released Top Vulnerabilities in VPN exploited by APTs The highest-impact vulnerabilities known to be exploited by APTs are listed below: Pulse Connect Secure: CVE-2019-11510: Pre-auth arbitrary file reading CVE-2019-11539: Post-auth command injection Fortinet: CVE-2018-13379: Pre-auth arbitrary file reading CVE-2018-13382: Allows an unauthenticated attacker to change the password of an SSL VPN web portal user CVE-2018-13383: Post-auth heap overflow. This allows an attacker to gain a shell running on the router Palo Alto: CVE-2019-1579: Palo Alto Networks GlobalProtect Portal NCSC suggests that users of these VPN products should investigate their logs for evidence of compromise, especially if the security patches were not applied immediately after their release. Additionally, administrators should look for evidence of compromised accounts in active use, such as anomalous IP locations or times. The report also covers product-specific advice to detect exploitation in VPN connections. Steps to mitigate the vulnerabilities in VPN NCSC provides essential steps to be taken to mitigate the risk of these vulnerabilities. They suggest that owners of vulnerable products should take two steps promptly: Apply the latest security patches released by vendors Reset authentication credentials associated with affected VPNs and accounts connecting through them The most effective way to mitigate the risk of actors exploiting these vulnerabilities is to ensure that the affected products are patched with the latest security updates. Pulse secure, Palo Alto and Fortinet have released patches for these vulnerabilities. NCSC also emphasizes on reporting any current activity related to these threats at incidents@ncsc.gov.uk where they will offer help and guidance. On Hacker News, this report has gained significant traction and users are discussing the nature of various VPN products and services. One of them commented, “Commercial enterprise VPN products are an open sewer, and there aren't any, from any vendor, that I trust. I don't like OpenVPN or strongSwan, but you'd be better off with either of them than you would be with a commercial VPN appliance. The gold standard, as ever, is Wireguard.” To know more about this report, check out the official NCSC website. An unpatched security issue in the Kubernetes API is vulnerable to a “billion laughs” attack Google Project Zero discloses a zero-day Android exploit in Pixel, Huawei, Xiaomi and Samsung devices 10 times ethical hackers spotted a software vulnerability and averted a crisis A Cargo vulnerability in Rust 1.25 and prior makes it ignore the package key and download a wrong dependency VLC media player affected by a major vulnerability in a 3rd library, libebml; updating to the latest version may help

Last week, two lawsuits were filed in Seattle that allege that Amazon is recording voiceprints of children using its Alexa devices without their consent. This is in violation of laws governing recordings in at least eight states, including Washington. The complaint was filed on behalf of a 10-year-old Massachusetts girl on Tuesday in federal court in Seattle. Another nearly identical suit was filed the same day in California Superior Court in Los Angeles, on behalf of an 8-year-old boy. What was the complaint? Per the complaint, “Alexa routinely records and voiceprints millions of children without their consent or the consent of their parents.” The complaint notes that Alexa devices record and transmit any speech captured after a “wake word” activates the device. This is regardless of the speaker and whether that person purchased the device or installed the associated app. It alleges that Amazon saves a permanent recording of the user’s voice instead of deleting the recordings after storing them for a short time or not at all. In both cases, the children had interacted with Echo Dot speakers in their homes, and in both cases the parents claimed they had never agreed for their child's voice to be recorded. The lawsuit alleges that Amazon’s failure to obtain consent, violates the laws of Florida, Illinois, Michigan, Maryland, Massachusetts, New Hampshire, Pennsylvania and Washington, which require consent of all parties to a recording, regardless of age. Aside from “the unique privacy interest” involved in recording someone’s voice, the lawsuit says, “It takes no great leap of imagination to be concerned that Amazon is developing voiceprints for millions of children that could allow the company (and potentially governments) to track a child’s use of Alexa-enabled devices in multiple locations and match those uses with a vast level of detail about the child’s life, ranging from private questions they have asked Alexa to the products they have used in their home.” What does the lawsuit suggest Amazon should do? The plaintiffs suggest that more could be done to ensure children and others were aware of what was going on. The lawsuit claims that Amazon should inform users who had not previously consented that they were being recorded and ask for consent. It should also deactivate permanent recording for users who had not consented. The complaints also suggest that Alexa devices should be designed to only send a digital query rather than a voice recording to Amazon's servers. Alternatively, Amazon could automatically overwrite the recordings shortly after they have been processed. What is Amazon’s response? When Vox reporters asked Amazon for a comment, they wrote to them in an email, “Amazon has a longstanding commitment to preserving the trust of our customers, and we have strict measures and protocols in place to protect their security and privacy.” They also pointed to a company blog post about the FreeTime parental controls on Alexa. Per their FreeTime parental control policy, parents can review and delete their offspring's voice recordings at any time via an app or the firm's website. In addition, it says, they can contact the firm and request the deletion of their child's voice profile and any personal information associated with it. However, these same requirements do not apply to a child’s use of Alexa outside of the FreeTime service and children’s Alexa skills. Amazon’s Alexa terms of use notes, “if you do not accept the terms of this agreement, then you may not use Alexa.” However, according to Andrew Schapiro, an attorney with Quinn Emanuel Urquhart & Sullivan, one of two law firms representing the plaintiffs. “There is nothing in that agreement that would suggest that “you” means a marital community, family or household. I doubt you could even design terms of service that bind ‘everyone in your household.’” This could also mean that Alexa is storing details of everyone, and not just children. A comment on Hacker News reads, “Important to note that if this allegation is true, it means Alexa is recording everyone and storing it indefinitely, not just children. The lawsuit just says children because children have more privacy protections than adults so it's easier to win a case when children's rights are being violated.” Others also share similar opinions: https://twitter.com/_FamilyInsights/status/1140490515240165377 https://twitter.com/lewiskamb/status/1138895472351883265   However, a few don’t agree: https://twitter.com/shellypalmer/status/1139545654567559169 https://twitter.com/CarolannJacobs/status/1139165270524780554   The suit asks a judge to certify the class action and rule that Amazon violated state laws, require it to delete all recordings of class members, and prevent further recording without prior consent. It seeks damages to be determined at trial. The Seattle case seeks damages up to $100 a day and the California case wants damages of $5,000 per violation. Google Home and Amazon Alexa can no longer invade your privacy; thanks to Project Alias! US regulators plan to probe Google on anti-trust issues; Facebook, Amazon & Apple also under legal scrutiny. Amazon shareholders reject proposals to ban sale of facial recognition tech to govt and to conduct an independent review of its human and civil rights impact.

Last week, RedTeam Pentesting had discovered a command injection vulnerability in the web-based certificate generator feature of the Cisco RV320 router. According to RedTeam Pentesting, the feature was inadequately patched by the vendor. On Saturday, Cisco acknowledged that it had mismanaged a patch which would give rise to a vulnerability in two router models, namely, Cisco RV320 and RV325 WAN VPN routers. https://twitter.com/RedTeamPT/status/1110843396657238016 The security flaws These router vulnerabilities were discovered way back in September 2018. Post four months the discovery, a patch was issued for blacklisting the curl which is a command-line tool used for transferring data online and is also integrated into internet scanners. The idea behind introducing this curl was to prevent the devices from the attackers. Cisco patches were intended to protect these vulnerable devices. And initially, it was believed that Cisco’s patches were the ideal choice for businesses. Cisco’s RV320 product page reads, "Keep your employees, your business, and yourself productive and effective. The Cisco RV320 Dual Gigabit WAN VPN Router is an ideal choice for any small office or small business looking for performance, security, and reliability in its network." Around 10,000 of these devices are still accessible online and are vulnerable to attacks. Cisco’s patch could merely blacklist the curl which turned out be a major problem. In January, this year, security researcher David Davidson published a proof-of-concept for two Cisco RV320 and RV325 vulnerabilities. The security flaws patched by Cisco were: CVE-2019-1652 This flaw allows remote attackers to inject and run admin commands on the device without using a password. CVE-2019-1653 This flaw allows remote attackers to get sensitive device configuration details without using a password. But it seems instead of fixing the vulnerable code in the actual firmware, Cisco has instead blacklisted the user agent for curl. https://twitter.com/bad_packets/status/1110981011523977217 Most of the users are surprised by this news and they think that these patches can be easily bypassed by the attackers. https://twitter.com/hrbrmstr/status/1110995488235503616 https://twitter.com/tobiasz_cudnik/status/1111068710360485891 To know more about this news, check out RedTeam Pentesting’s post. Redis Labs raises $60 Million in Series E Funding led by Francisco partners San Francisco legislation proposes a citywide ban on government’s use of facial recognition technology Cisco and Huawei Routers hacked via backdoor attacks and botnets  

A team of researchers at the University of Maryland released unCaptcha2 last week, an updated version of their tool Uncaptcha that defeated Google's reCAPTCHA audio challenge with 85.15% accuracy in 2017. Google’s Audio challenge is aimed at solving reCAPTCHA's accessibility problem for visually challenged people who can’t see where to "tick the box" to prove that they’re a human and not a robot. Hence, they’re offered an option to listen to the audio and enter what they hear as a response. UnCaptcha, which was released in 2017, managed to pass the reCAPTCHA audio system by using an approach that involved downloading the audio and segmenting it. These segments were then uploaded to multiple speech-to-text services, which in turn would convert the message.                                                            unCaptcha Finally, the response obtained would be typed into the reCAPTCHA form to solve the challenge. However, after the attack in 2017, Google updated the reCAPTCHA form by introducing changes such as improved browser automation detection and using spoken phrases instead of digits for reCAPTCHA. These changes managed to successfully protect reCAPTCHA from the 2017 unCaptcha attack but failed to protect it from the new unCaptcha2. “As of June 2018, these challenges have been solved. The reCAPTCHA team..is..fully aware of this attack. The team has allowed us to release the code. The code now only needs to make a single request to a free, publicly available speech to text API (by Google) to achieve around 90% accuracy over all the captchas”, states the team. UnCaptcha2 makes use of a screen clicker that helps it move to certain pixels on the screen and move around the webpage as a human would. However, this method is not very robust and still needs more working. Also, unCaptcha2 uses a different approach than the first version and no longer requires the use of multiple speech-to-text engines as well as the segmentation approach. UnCaptcha2 involves navigating to Google's ReCaptcha Demo site, navigating to audio challenge for reCAPTCHA and then downloading the audio challenge. After this step, the audio challenge is submitted to Speech To Text services. Finally, the response obtained is typed in and submitted to solve the challenge. “unCaptcha2, like the original version, is meant to be a proof of concept. As Google updates its service, this repository will not be updated. As a result, it is not expected to work in the future, and is likely to break at any time,” state the researchers. Google launches score-based reCAPTCHA v3 to filter abusive traffic on websites Google’s secret Operating System ‘Fuchsia’ will run Android Applications: 9to5Google Report Google Cloud releases a beta version of SparkR job types in Cloud Dataproc

Yesterday the team at Mozilla announced that the company is receiving hundreds of bug reports and feature requests from Firefox users on a daily basis. The team noted that it’s important to get the bugs fixed as soon as possible for the smooth functioning of the systems. Also, the developers should quickly come to know that there is a bug in order to fix it. Bug triage, a process where tracker issues are screened and prioritised can be useful in such cases. However, even when developers come to know that bugs exist in the system, it is still difficult for the developers to closely look at each bug. The team at Mozilla has been using Bugzilla since years now which is a web-based general-purpose bugtracker and testing tool that group the bugs by product. But product assignment or the grouping process was done manually by the developers so this process failed to scale. Now Mozilla is experimenting with Machine Learning to train systems to triage bugs. BugBug It’s important to get the bugs in the eye of the right set of engineers, for which the team at Mozilla developed BugBug, a machine learning tool that assigns a product and component automatically for every new untriaged bug. By bringing the bugs into the radar of the triage owners, the team at Mozilla has made an effort towards decreasing the turnaround time to fix new issues. Training the BugBug model Mozilla has a large training set of data for this model which includes two decades worth of bugs that have been reviewed by Mozillians and assigned to products and components. The bug data can’t be used as-is and any change to the bug after triage would create trouble during operation. So the team at Mozilla rolled back the bug to the time it was originally filed. Out of 396 components, 225 components had more than 49 bugs filed in the past 2 years. During operation, the team performed the assignment when the model was confident enough of its decision and currently, the team is using a 60% confidence threshold. Ever since the team has deployed BugBug in production at the end of February 2019, they have triaged around 350 bugs. The median time for any developer to act on triaged bugs is 2 days. Usually, 9 days is the average time to act, but with BugBug the Mozilla team took just 4 days to remove the outliers. Mozilla plans to use Machine learning in the future The Mozilla team has planned to use machine learning to assist in other software development processes, such as identifying duplicate bugs, providing automated help to developers, and detecting the bugs important for a Firefox release. The team plans to extend BugBug to automatically assign components for other Mozilla products. To know more about this news, check out the post by Mozilla. Mozilla is exploring ways to reduce notification permission prompt spam in Firefox Mozilla launches Firefox Lockbox, a password manager for Android Mozilla’s Firefox Send is now publicly available as an encrypted file sharing service  

An example of a social engineering attack using Kali Linux - use a credential harvester to gather the victim's credentials. Redirect your victim to a spoofed website and then collect the login credentials. Part of Kali Linux - Backtrack Evolved: Assuring Security by Penetration Testing. For the full course visit: https://www.packtpub.com/networking-and-servers/kali-linux-backtrack-evolved-assuring-security-penetration-testing-video

Yesterday, the Atlassian Support released the Jira security advisory affecting Jira Server and Jira Data Center. This advisory reveals a critical severity security vulnerability, labeled as CVE-2019-11581, which was introduced in version 4.4.0 of Jira Server and Jira Data Center. How can one exploit this vulnerability? For this issue to be exploitable, the attacker needs to meet any one of the following conditions: An SMTP server configured in Jira and the Contact Administrators Form is enabled, which will allow the attackers to exploit this issue without authentication. An SMTP server configured in Jira and an attacker has "JIRA Administrators" access, where attackers can exploit the issue using  JIRA Administrators’ credentials. In any of the cases, exploitation of this issue helps an attacker to remotely execute code on systems that run a vulnerable version of Jira Server or Data Center. The official post reads, “All versions of Jira Server and Data Center from 4.4.0 before 7.6.14 (the fixed version for 7.6.x), from 7.7.0 before 7.13.5 (the fixed version for 7.13.x), from 8.0.0 before 8.0.3 (the fixed version for 8.0.x), from 8.1.0 before 8.1.2 (the fixed version for 8.1.x), and from 8.2.0 before 8.2.3 are affected by this vulnerability.” To address this issue, the team has fixed this vulnerability in the 8.2.3, 8.1.2, 8.0.3, 7.13.5, 7.6.14 versions of Jira Server and Jira Data Center. Atlassian recommends that users upgrade to the latest version. How can users quickly mitigate this issue? For mitigating, users can first disable the Contact Administrators Form and then also block the /secure/admin/SendBulkMail!default.jspa endpoint from being accessed. This can be easily achieved by denying access in the reverse-proxy, load balancer, or Tomcat directly. However, blocking the SendBulkMail endpoint will prevent Jira Administrators from being able to send bulk emails to users. Hence, after upgrading Jira, users can re-enable the Administrator Contact Form, and unblock the SendBulkMail endpoint. To know more about this news, check out Jira security advisory. JIRA 101 Gadgets in JIRA Securing your JIRA 4

Yesterday a remote code execution bug was found in the APT high-level package manager used by Debian, Ubuntu, and other related Linux distributions. Max Justicz, the security researcher who discovered the bug, says that the bug "allows a network man-in-the-middle (or a malicious package mirror) to execute arbitrary code as root on a machine installing any package.” Justicz’s blog post states that the vulnerable versions of APT don't properly sanitize certain parameters during HTTP redirects. An attacker can take advantage of this and perform a remote man-in-the-middle attack to inject malicious content, thus tricking the system to install certain altered packages. HTTP redirects while using apt-get command help Linux machines to automatically request packages from an appropriate mirror server when other servers are unavailable. If the first server fails, it returns the location of the next server from where the client should request the package. Justicz has also demonstrated this man-in-the-middle attack in a short video: https://justi.cz/assets/aptpoc.mp4 Justicz told The Hacker News that a malicious actor intercepting HTTP traffic between APT utility and a mirror server, or just a malicious mirror, could execute arbitrary code on the targeted system with the highest level of privileges, i.e. root. He further adds, "You can completely replace the requested package, as in my proof of concept. You could substitute a modified package as well if you wanted to”. The APT is also used by major Linux distributions like Debian and Ubuntu, who have also acknowledged and released security patches for this vulnerability. Hacker News also points how this flaw comes around the time when cybersecurity experts are fighting over Twitter, in favor of not using HTTPS and suggesting software developers to rely on signature-based package verification since the APT on Linux also does the same. They further add that the APT exploitation could have been mitigated if the software download manager was strictly using HTTPS to communicate securely. The developers of APT have released version 1.4.9 that fixes the issue. The bug has also been fixed in APT 1.2.29ubuntu0.1, 1.7.0ubuntu0.1, 1.0.1ubuntu2.19, and 1.6.6ubuntu0.1 packages, as well as in APT 1.4.9 for the Debian distribution. You can head over to Max Justicz official blog for more insights on this news. Kali Linux 2018 for testing and maintaining Windows security – Wolf Halton and Bo Weaver [Interview] Black Hat hackers used IPMI cards to launch JungleSec Ransomware, affects most of the Linux servers Homebrew 1.9.0 released with periodic brew cleanup, beta support for Linux, Windows and much more!

About a thousand Google employees frustrated with a series of controversies involving Google have signed a letter to demand transparency on building a censored search engine for China. The project named Dragonfly is a censored search engine for the Chinese market. In the letter employees mentioned, “Currently we do not have the information required to make ethically-informed decisions about our work, our projects, and our employment.” The letter published by the Buzzfeed news was circulated on Google’s internal communications system and is signed by about 1400 Googlers. The Dragonfly project will be Google’s return to China after 8 years of withdrawal from its decision to protest against censorship and government hacking. China has the world’s largest internet audience but has frustrated American tech giants with content restrictions or outright blockages of services including Facebook and Instagram. Crisis already hailing in Google This is not the first time Google’s outspoken workforce has been agitated by changes in strategy. In April, the internet company’s employees spoke out against its involvement in a Pentagon program that uses artificial intelligence to improve weaponry. Over 4,000 employees signed a petition asking the company to cancel it. A dozen engineers resigned in protest, and Google eventually promised not to renew the contract. Following that uproar, Google published AI ethics guidelines for the company. The letter about Dragonfly that's currently being circulated inside the company, argues that those guidelines are not enough and employees further added, "As a company and as individuals we have a responsibility to use this power to better the world, not to support social control, violence, and oppression," the letter reads. "What is clear is that Ethical Principles on paper are not enough to ensure ethical decision making. We need transparency, oversight, and accountability mechanisms sufficient to allow informed ethical choice and deliberation across the company." What does Google’s management say Allison Day, a program manager at Google is not shocked by this outrage and says to the Buzzfeed news, “I can see the bottom line for any corporation is growth, and [China] represented a gigantic market,” she said. “The ‘Don’t be Evil’ slogan or whatever is, you know… It’s not a farce. I wouldn’t go so far as to say that. But it is a giant corporation, and its bottom line is to make money.” Google CEO Sundar Pichai has repeatedly expressed interest in the company making a return to China, which it pulled out of for political reasons in 2010. Pichai’s apparent decision to return, which was not addressed companywide before Thursday, has caused some employees to consider leaving the company altogether. “There are questions about how [Dragonfly] is implemented that could make it less concerning, or much more concerning,” an anonymous Google employee said. “That will continue to be on my mind, and the mind of other Googlers deciding whether to stay.” The Dragonfly project secrecy Two Google employees who were working on Dragonfly were so disturbed by the secrecy that they quit the team over it. Developers who were working on the project had been asked to keep Dragonfly confidential — not just from the public, but also from their coworkers. Even more upsetting to some employees is the fact that the company has blocked off internal access to Dragonfly’s code. Managers also shut down access to certain documents pertaining to the project, according to the Intercept. Employees feel that this is a special kind of betrayal and erosion of trust because they talk and act like, “Once you’re at Google, you can look up the code anywhere in the code base and see for yourself.” “We pride ourselves on having an open and transparent culture,” said the anonymous Google developer. “There [are] definitely employees at the company who are very frustrated because that’s clearly not true.” Google has not responded to specific questions about Dragonfly from the Intercept, nor to Bloomberg, nor to BuzzFeed News, only saying in a statement, “We don’t comment on speculation about future plans.” An anonymous Google developer said, “Even though a lot of us have really good jobs, we can see that the difference between us and the leadership is still astronomical. The vision they have for the future is not our vision.” Google releases new political ads library as part of its transparency report Google is missing out $50 million because of Fortnite’s decision to bypass Play Store Google’s censored Chinese search engine is a stupid, stupid move, says former exec Lokman Tsui

Update: Six days after an anonymous researcher had disclosed a zero-day pre-auth remote code execution vulnerability in vBulletin, Cloudflare has deployed a new rule within their Cloudflare Specials Rulesets (ruleId: 100166).  The Cloudflare team states, “We assess this vulnerability to be very significant as it has a CVSS score of 9.8/10 and affects 7 out of the 10 key risk areas of the OWASP 2017 Top 10. Protection against common RCE attacks is a standard feature of Cloudflare's Managed Rulesets.” Cloudflare customers with Managed Rulesets and Cloudflare Specials can be protected against this vulnerability by enabling the WAF Managed Rulesets in the Firewall tab of Cloudflare. Head over to the Cloudflare blog for more details about Cloudflare’s protection against this vulnerability. On September 23rd, an anonymous researcher published a zero-day pre-authentication remote code execution vulnerability in vBulletin, which allows an attacker to remotely execute malicious shell commands on any vBulletin server running versions 5.0.0 up to 5.5.4. The vulnerability was disclosed on Full Disclosure, a public access mailing list. Yesterday, the vBulletin team issued a security patch for this vulnerability, which is now tracked under the CVE-2019-16759. How does the zero-day vulnerability in vBulletin work Ryan Seguin, a research engineer at Tenable explains in his blog that this vulnerability utilizes default vBulletin configurations. This enables an unauthenticated attacker to send a specially crafted HTTP POST request to a vulnerable vBulletin host and execute commands. He further states, “These commands would be executed with the permissions of the user account that the vBulletin service is utilizing. Depending on the service user’s permissions, this could allow complete control of a host.” Another security researcher, Troy Mursch of the Bad Packets security intelligence service told Arstechnica that the attackers are employing botnets to actively exploit vulnerable servers. The exploit, Mursch says, can modify the includes/vb5/frontend/controller/bbcode.php via the "sed" command to add a backdoor to the code. Mursch adds, “This is done by setting a “password” (epass) of 2dmfrb28nu3c6s9j. By doing this, the compromised site will only execute code in the eval function if 2dmfrb28nu3c6s9j is set in future requests sent to the server. This would allow a botnet command-and-control (C2) server to exclusively exploit CVE-2019-16759 and issue commands to the targeted site. The vulnerability itself has been regarded by some as a backdoor.” The vBulletin vulnerability is exploiting websites via the backdoor to build a list of bots that can configure supplementary ways of exploiting the infected hosts. The backdoor can infect the compromised hosts with DDoS malware and conduct denial-of-service attacks. It is not known yet if the anonymous publisher of this vulnerability had reported the vulnerability to the vBulletin team or not. Another possibility is that the vBulletin team could not find a timely solution to this issue, encouraging the user to publish the vulnerability on Full Disclosure. The anonymous researcher has published about the zero-day vulnerability from an unnamed email service. Why is a vulnerability in vBulletin so severe? vBulletin, a popular web forum software package has around 0.1% market share of all the running forums across the internet. Though the percentage looks small, the vulnerability in vBulletin can impact billions of internet users, reports ZDNet. vBulletin is designed to collect user information about registered users. “While billions of internet sites don't store any info about users, a handful of online forums could very easily store data on most internet users. Therefore, a market share of 0.1% is actually pretty significant, when we factor in how many users could be registered on these forums.” Steam, EA, Zynga, NASA, Sony, BodyBuilding.com, the Houston Texans, and the Denver Broncos are some of the customers that use the vBulletin server. Yesterday, GreyNoise, a cybersecurity company has tweeted that the vBulletin hackers are actively using this vulnerability to attack vulnerable forums. https://twitter.com/GreyNoiseIO/status/1176898873622781954 According to Chaouki Bekrar, founder and CEO of the Zerodium exploit broker, the vulnerability is known for many years. https://twitter.com/cBekrar/status/1176803541047861249 The vBulletin team has already issued a patch for CVE-2019-16759 for vBulletin versions 5.5.2, 5.5.3, and 5.5.4. Users on earlier versions of vBulletin 5.x are advised to update to one of the supported versions in order to implement the patch. The vBulletin cloud version has already updated and fixed this issue. Silicon-Interconnect Fabric is soon on its way to replace Printed Circuit Boards, new UCLA research claims Google Chrome Keystone update can render your Mac system unbootable ReactOS 0.4.12 releases with kernel improvements, Intel e1000 NIC driver support, and more

This week, an IoT worm called Silex that targets a Unix-like system took down around 2,000 devices, ZDNet reports. This malware attacks by attempting a login with default credentials and after gaining access. Larry Cashdollar, an Akamai researcher, the first one to spot the malware, told ZDNet in a statement, "It's using known default credentials for IoT devices to log in and kill the system.” He added, “It's doing this by writing random data from /dev/random to any mounted storage it finds. I see in the binary it's calling fdisk -l which will list all disk partitions."  He added, "It then writes random data from /dev/random to any partitions it discovers." https://twitter.com/_larry0/status/1143532888538984448 It deletes the devices' firewall rules and then removes its network config and triggers a restart, this way the devices get bricked. Victims are advised to manually reinstall the device's firmware for recovering. This malware attack might remind you of the BrickerBot malware that ended up destroying millions of devices in 2017. Cashdollar told ZDNet in a statement, "It's targeting any Unix-like system with default login credentials." He further added, "The binary I captured targets ARM devices. I noticed it also had a Bash shell version available to download which would target any architecture running a Unix like OS." This also means that this malware might affect Linux servers if they have Telnet ports open and in case they are secured with poor or widely-used credentials. Also, as per the ZDNet report, the attacks were carried out from a VPS server that was owned by a company operating out of Iran. Cashdollar said, "It appears the IP address that targeted my honeypot is hosted on a VPS server owned by novinvps.com, which is operated out of Iran."  With the help of NewSky Security researcher Ankit Anubhav, ZDNet managed to reach out to the Silex malware author who goes by the pseudonym Light Leafon. According to Anubhav, Light Leafon, is a 14-year-old teenager responsible for this malware.  In a statement to Anubhav and ZDNet, he said, “The project started as a joke but has now developed into a full-time project, and has abandoned the old HITO botnet for Silex.” Light also said that he has plans for developing the Silex malware further and will add even more destructive functions. In a statement to Anubhav and ZDNet, he said, "It will be reworked to have the original BrickerBot functionality."  He is also planning to add the ability to log into devices via SSH apart from the current Telnet hijacking capability. He plans to give the malware the ability to use vulnerabilities for breaking into devices, which is quite similar to most of the IoT botnets. Light said, "My friend Skiddy and I are going to rework the whole bot.” He further added, "It is going to target every single publicly known exploit that Mirai or Qbot load." Light didn’t give any justification for his actions neither have put across any manifesto as the author of BrickerBot (goes with the pseudonym-Janit0r) did post before the BrickerBot attacks. Janit0r motivated the 2017 attacks to protest against owners of smart devices that were constantly getting infected with the Mirai DDoS malware. In a statement to ZDNet, Anubhav described the teenager as "one of the most prominent and talented IoT threat actors at the moment." He further added, "Its impressive and at the same time sad that Light, being a minor, is utilizing his talent in an illegal way." People are surprised how a 14-year-old managed to work this out and are equally worried about the consequences the kid might undergo. A user commented on Reddit, “He's a 14-year old kid who is a bit misguided in his ways and can easily be found. He admits to DDoSing Wix, Omegle, and Twitter for lols and then also selling a few spots on the net. Dude needs to calm down before it goes bad. Luckily he's under 18 so really the worst that would happen in the EU is a slap on the wrist.”  Another user commented, “It’s funny how those guys are like “what a skid lol” but like ... it’s a 14-year-old kid lol. What is it people say about the special olympics…” Few others said that developers need to be more vigilant and take security seriously. Another comment reads, “Hopefully manufacturers might start taking security seriously instead of churning out these vulnerable pieces of shit like it's going out of fashion (which it is).” To know more about this news, check out the report by ZDNet. WannaCry hero, Marcus Hutchins pleads guilty to malware charges; may face upto 10 years in prison FireEye reports infrastructure-crippling Triton malware linked to Russian government tech institute ASUS servers hijacked; pushed backdoor malware via software updates potentially affecting over a million users  

Robert J. Hansen, a maintainer of the GnuPG FAQ, revealed about a certificate spamming attack against him and Daniel Kahn Gillmor, two high-profile contributors in the OpenPGP community, in the last week of June 2019. The attack exploited a defect in the OpenPGP protocol to "poison" both Hansen’s and Gillmor’s OpenPGP certificates. “Anyone who attempts to import a poisoned certificate into a vulnerable OpenPGP installation will very likely break their installation in hard-to-debug ways”, Hansen wrote on his GitHub blog post. Gillmor said his OpenPGP certificate was flooded with bogus certifications which were uploaded to the SKS keyserver network. The main use of OpenPGP today is to verify downloaded packages for Linux-based operating systems, usually using a software tool called GnuPG. This attack has the following consequences: If you fetch a poisoned certificate from the keyserver network, you will break your GnuPG installation. Poisoned certificates cannot be deleted from the keyserver network. The number of deliberately poisoned certificates, currently at only a few, will only rise over time. The attackers may have an intent on poisoning other certificates and the scope of the damage is still unknown A year ago, OpenPGP experienced similar certificate flooding, one, a spam on Werner Koch's key and second, abuse tools made available years ago under the name "trollwot". There's a keyserver-backed filesystem proposed as a proof of concept to point out the abuse. “Poisoned certificates are already on the SKS keyserver network. There is no reason to believe the attacker will stop at just poisoning two certificates. Further, given the ease of the attack and the highly publicized success of the attack, it is prudent to believe other certificates will soon be poisoned”, Hansen further added. He also said that the mitigation to this attack cannot be carried out “in any reasonable time period” and that the future releases of OpenPGP software may have mitigation. However, he said he is unsure of the time frame. The best mitigation that can be applied at present is simple: stop retrieving data from the SKS keyserver network, Hansen says. The “keyserver software” was written to facilitate the discovery and distribution of public certificates. Users can search the keyserver by a variety of different criteria to discover public certificates which claim to belong to the desired user. The keyserver network, however, does not attest to the accuracy of the information. This was left for each user to ascertain according to their own criteria. According to the Keyserver design goals, “Keyservers could add information to existing certificates but could never, ever, ever, delete either a certificate or information about a certificate”, Hansen said as he was involved in the PGP community since 1992 and was present for these discussions. “In the early 1990s this design seemed sound. It is not sound in 2019. We've known it has problems for well over a decade”, Hansen adds. This shows that Keyservers are vulnerable and susceptible to attacks and how the data can be easily misused. Why SKS Keyserver Network can never be fixed Hansen has also given some reasons why the software was not fixed or updated for security to date. A difficult to understand algorithm The SKS or standard keyserver software was written by Yaron Minsky. It became the keystone of his Ph.D. thesis, and he wrote SKS originally as a proof of concept of his idea. The algorithm is written in an unusual programming language called OCaml, which Hansen says has an idiosyncratic dialect. “ Not only do we need to be bright enough to understand an algorithm that's literally someone's Ph.D. thesis, but we need expertise in obscure programming languages and strange programming customs”, Hansen says. Change in design goal may result in changes from scratch Due to a difficult programming language it is written in, there are hardly any programmers who are qualified to do such a major overhaul, Hansen says. Also, the design goal of the keyserver network is "baked into" essentially every part of the infrastructure and changing it may lead to huge changes in the entire software. Lack of a centralized authority The lack of centralized authority was a feature, not a bug. This means there is no single point of failure for a government to go after. This makes it even harder to change the design goals as the network works as a confederated system. Keyserver network is a Write-only file system The Keyserver network is based on a write-only, which makes it susceptible to a lot of attacks as one can only write into it and have a tough time deleting files. The keyserver network can be thought of as an extremely large, extremely reliable, extremely censorship-resistant distributed file system which anyone can write to. Attackers can easily add any malicious or censored content files or media, which no one can delete. Mitigations for using the Synchronization Key server Hansen says high-risk users should stop using the keyserver network immediately. For those confident with editing their GnuPG configuration files, the following process is recommended: Open gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it. Open dirmngr.conf in a text editor. Add the line keyserver hkps://keys.openpgp.org to the end of it. keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this sort of attack. It has some limitations like its search functionality is sharply constrained. However, once changes are made users will be able to run gpg --refresh-keys with confidence. Daniel Kahn Gillmor, in his blogpost, says, “This is a mess, and it's a mess a long time coming. The parts of the OpenPGP ecosystem that rely on the naive assumptions of the SKS keyserver can no longer be relied on because people are deliberately abusing those keyservers. We need significantly more defensive programming and a better set of protocols for thinking about how and when to retrieve OpenPGP certificates”. Public reaction to this attack is quite speculative. People shared their opinions on Twitter. Some have also suggested migrating the SKS server towards the new OpenPGP key server called Hagrid. https://twitter.com/matthew_d_green/status/1145030844131753985 https://twitter.com/adulau/status/1145045929428443137 To know more about this in detail, head over to Robert J. Hansen’s GitHub post. Training Deep Convolutional GANs to generate Anime Characters [Tutorial] Former npm CTO introduces Entropic, a federated package registry with a new CLI and much more! Microsoft introduces Service Mesh Interface (SMI) for interoperability across different service mesh technologies

On July 2, 2019, Cloudflare suffered a major outage due to a massive spike in CPU utilization in the network. Ten days after the outage, on July 12, Cloudflare’s CTO John Graham-Cumming, has released a report highlighting the details about how the Cloudflare service went down for 27 minutes. During the outage, the company speculated the reason to be a single misconfigured rule within the Cloudflare Web Application Firewall (WAF), deployed during a routine deployment of new Cloudflare WAF Managed rules. This speculation turns out to be true and caused CPUs to become exhausted on every CPU core that handles HTTP/HTTPS traffic on the Cloudflare network worldwide. Graham-Cumming said they are “constantly improving WAF Managed Rules to respond to new vulnerabilities and threats”. The CPU exhaustion was caused by a single WAF rule that contained a poorly written regular expression that ended up creating excessive backtracking. Source: Cloudflare report The regular expression that was at the heart of the outage is : Graham-Cumming says Cloudflare deploys dozens of new rules to the WAF every week, and also have numerous systems in place to prevent any negative impact of that deployment. He shared a list of vulnerabilities that caused the major outage. What’s Cloudflare doing to mend the situation? Graham-Cumming said they had stopped all release work on the WAF completely and are following some processes: He says, for longer-term, Cloudflare is “moving away from the Lua WAF that I wrote years ago”. The company plans to port the WAF to use the new firewall engine, which provides customers the ability to control requests, in a flexible and intuitive way, inspired by the widely known Wireshark language. This will make the WAF both faster and add yet another layer of protection. Users have appreciated Cloudflare’s efforts in taking immediate calls for the outage and being completely transparent about the root cause of it with a complete post mortem report. https://twitter.com/fatih/status/1150014793253904386 https://twitter.com/nealmcquaid/status/1150754753825165313 https://twitter.com/_stevejansen/status/1150928689053470720 “We are ashamed of the outage and sorry for the impact on our customers. We believe the changes we’ve made mean such an outage will never recur,” Graham-Cumming writes. Read the complete in-depth report by Cloudflare on their blog post. How Verizon and a BGP Optimizer caused a major internet outage affecting Amazon, Facebook, CloudFlare among others Cloudflare adds Warp, a free VPN to 1.1.1.1 DNS app to improve internet performance and security Cloudflare raises $150M with Franklin Templeton leading the latest round of funding

If you think closing down a website, closes down the possibility of the device being tracked, then you are wrong! Some Greek researchers have revealed a new browser-based attack named MarioNet, using which attackers can run malicious code inside users' browsers even after users have closed the webpage or even navigated away from the web page on which they got infected. The researchers in the paper titled, “Master of Web Puppets: Abusing Web Browsers for Persistent and Stealthy Computation” have also explained different anti-malware browser extensions and anti-mining countermeasures, and also puts forward several mitigations that browser makers could take. The MarioNet attack was presented on February 25 at the NDSS 2019 conference in San Diego, USA. MarioNet allows hackers to assemble giant botnets from users’ browsers. The researchers state that these bots can be used for in-browser crypto-mining (crypto jacking), DDoS attacks, malicious files hosting/sharing, distributed password cracking, creating proxy networks, advertising click-fraud, and traffic stats boosting. Even after a user exits a browser or web page, MarioNet can easily survive. This is because modern web browsers support a new API called Service Workers. “This mechanism allows a website to isolate operations that rendering a page's user interface from operations that handle intense computational tasks so that the web page UI doesn't freeze when processing large quantities of data”, the ZDNet reports. In their research paper, they explain technical details of how service workers are an update to an older API called Web Workers. They say, unlike web workers, a service worker, once registered and activated, can live and run in the page's background, without requiring the user to continue browsing through the site that loaded the service worker. The attack routine consists of registering a service worker when the user lands on an attacker-controlled website and then abusing the Service Worker SyncManager interface to keep the service worker alive after the user navigates away. The attack doesn't require any type of user interaction as browsers don't alert users or ask for permission before registering a service worker. Everything happens under the browser's hood as the user waits for the website to load. MarioNet allows attackers to place malicious code on high-traffic websites for a short period of time. This allows the attackers to gain a huge user base, remove the malicious code, but continue to control the infected browsers from another central server. The attack can also persist across browser reboots by abusing the Web Push API. This requires the attacker from getting user permission from the infected hosts to access this API. The researchers also highlighted the fact that as Service Workers have been introduced a few years back, the MarioNet attack also works in almost all desktop and mobile browsers. Places, where a MarioNet attack won't work, are IE (desktop), Opera Mini (mobile), and Blackberry (mobile). To know more about MarioNet attack in detail, read the complete research paper. New research from Eclypsium discloses a vulnerability in Bare Metal Cloud Servers that allows attackers to steal data Security researchers discloses vulnerabilities in TLS libraries and the downgrade Attack on TLS 1.3 Remote Code Execution Flaw in APT Linux Package Manager allows man-in-the-middle attack