Tech News - Cybersecurity

Last month, two security researchers, Noam Rotem and Ran Locar found an unprotected database managed by TrueDialog. The database exposed tens of millions of SMS text messages exchanged between businesses and their customers. TrueDialog is a US-based SMS text service provider for enterprise businesses and higher education. Its cloud-based texting platform enables users to send both one-to-one as well as bulk messages to customers. What data TrueDialog’s database exposed Along with millions of sent and received text messages, this database included phone numbers, marketing messages from businesses with discount codes, job alerts, and more. Some of the two-way messages had a unique conversation code using which anyone would be able to read the entire thread of conversations. What concerning is that there were also text messages with sensitive information. As per TechCrunch, the database included “two-factor codes and other security messages, which may have allowed anyone viewing the data to gain access to a person’s online accounts.” TechCrunch further shared that the database also included messages containing codes to access online medical services, password reset and login codes for sites including Facebook and Google, and usernames and passwords of TrueDialog’s customers. TrueDialog took the database offline shortly after being contacted by TechCrunch. However, the company’s chief executive John Wright did not acknowledge the breach or gave any clarity on whether TrueDialog will be informing this to its customers. This is another case of companies being negligent towards their customers’ data. In October this year, an Elasticsearch server, allegedly belonging to two data enrichment companies exposed the personal information of nearly 1.2 billion users. In another case, security researcher Oliver Hough discovered that printing company Vistaprint left an online database containing customer interactions unencrypted. Check out the report by Noam Rotem and Ran Locar to know more about TrueDialog data leak in detail. GDPR complaint in EU claim billions of personal data leaked via online advertising bids How to protect your VPN from Data Leaks DoorDash data breach leaks personal details of 4.9 million customers, workers, and merchants  

Brave, the open source privacy- focussed browser, has allegedly introduced a ‘backdoor’ to remotely inject headers in HTTP requests that may track users, say users on HackerNews. Users on Twitter and HackerNews have expressed their concerns over the new update on custom HTTP headers added by the Brave team: https://twitter.com/WithinRafael/status/1094712882867011585 Source: HackerNews A user on Reddit has explained this move as “not tracking anything, they just send the word "Brave" to the website whenever you visit certain partners of theirs. So for instance visiting coinbase.com sends an "X-Brave-Partner" custom header to coinbase.com.” Brendan Eich, from the Brave team, has replied back to this allegation saying that the ‘Update is not a "backdoor" in any event and is a custom header instead.’  He says the update is about custom HTTP headers that Brave sends to its partners, with fixed header values. There is no tracking hazard in the new update. He further stresses on the fact that Brave blocks 3rd party cookies and storage and 3rd party fingerprinting along with HSTS supercookies; thus assuring users on preserving their privacy. “I find it silly to assume we will "heel turn" so obviously and track our users. C'mon! We defined our model so we can't cheat without losing lead users who would see through it. That requires seeing clearly things like the difference between tracking and script blocking or custom header sending, though.” Users have also posted on Hacker News that the Brave browser Tracking Protection feature does not block tracking scripts from hostnames associated with Facebook and Twitter. The tracking_protection_service.h file contains a comment informing that a tracking protection white_list variable was created as a "Temporary hack which matches both browser-laptop and Android code". Bleepingcomputer also reports that this whitelist variable is associated with code in the tracking_protection_service.cc file that adds various Facebook and Twitter hostnames to the whitelist variable so that they are not blocked by Brave's Tracking Protection feature. In response to this comment, Brave says that the issue that was opened on September 8th, 2018 and developers decided to whitelist tracking scripts from Facebook and Twitter because blocking them would “affect the functionality of many sites” including Facebook logins. You can head over to Brendan’s Reddit thread for more insights on this update. Brave introduces Brave Ads that share 70% revenue with users for viewing ads Chromium-based Brave browser shows 22% faster page load time than its Muon-based counterpart Otter Browser’s first stable release, v1.0.01 is out

A group of researchers recently disclosed seven additional attacks in the Spectre and Meltdown families. These seven attacks are said to impact the AMD, ARM, and the Intel CPUs to a certain extent. The researchers have presented an execution of these attacks in detail, in their research paper titled, ‘A Systematic Evaluation of Transient Execution Attacks and Defenses’. 2 Meltdown and 5 Spectre variants found The 7 newly found attacks include 2 new Meltdown variants namely, Meltdown-PK, and Meltdown-BR. It also includes 5 new Spectre mistraining strategies for Spectre-PHT and SpectreBTB attacks. The researchers said that these 7 new attacks have been overlooked and not been investigated so far. The researchers successfully demonstrated all seven attacks with proof-of-concept code. However, experiments to confirm six other Meltdown-attacks did not succeed. The two new Meltdown attacks include: Meltdown-PK - bypasses memory protection keys on Intel CPUs Meltdown-BR - exploits an x86 bound instruction on Intel and AMD The other Meltdown attacks  which the researchers tried and failed to exploit targeted the following internal CPU operations: Meltdown-AC - tried to exploit memory alignment check exceptions Meltdown-DE - tried to exploit division (by zero) errors Meltdown-SM - tried to exploit the supervisor mode access prevention (SMAP) mechanism Meltdown-SS - tried to exploit out-of-limit segment accesses Meltdown-UD - tried to exploit invalid opcode exception Meltdown-XD - tried to exploit non-executable memory Source: A Systematic Evaluation of Transient Execution Attacks and Defenses In order to understand the Spectre-type attacks, the researchers proposed a categorization based on, first, the prediction mechanism exploited, and second, the mistraining mechanism. Here researchers propose to combine all attacks that exploit the same microarchitectural element: Spectre-PHT: Exploits the Pattern History Table (PHT) Spectre-BTB: Exploits the Branch Target Buffer (BTB) Spectre-STL: Exploits the CPUs memory disambiguation prediction, specifically store-to-load forwarding (STLF) Spectre-RSB: Exploits the Return Stack Buffer (RSB) According to ZDNet, “Based on the experiments, the researchers found three new Spectre attacks that exploit the Pattern History Table (PHT) mechanism and two new Spectre attacks against the Branch Target Buffer (BTB).” PHT-CA-OP PHT-CA-IP PHT-SA-OP BTB-SA-IP BTB-SA-OP Defenses for these new Spectre and Meltdown attacks For each of the Spectre and Meltdown attack types, the researchers have categorized the defenses into three and two categories respectively. For Spectre-type attacks, the defense categories are: Mitigating or reducing the accuracy of covert channels used to extract the secret data. Mitigating or aborting speculation if data is potentially accessible during transient execution. Ensuring that secret data cannot be reached. For Meltdown-type attacks, the defense categories are: Ensuring that architecturally inaccessible data remains inaccessible on the microarchitectural level. Preventing the occurrence of faults. The researchers in the paper said, “We have systematically evaluated all defenses, discovering that some transient execution attacks are not successfully mitigated by the rolled out patches and others are not mitigated because they have been overlooked. Hence, we need to think about future defenses carefully and plan to mitigate attacks and variants that are yet unknown”. To know more about these newly found attacks in detail and the related experiments, head over to the research paper written by Claudio Canella et al. Intel announces 9th Gen Core CPUs with Spectre and Meltdown Hardware Protection amongst other upgrades NetSpectre attack exploits data from CPU memory SpectreRSB targets CPU return stack buffer, found on Intel, AMD, and ARM chipsets

Last week, a potentially serious and unpatched security issue was revealed in the Kubernetes API server GitHub repository by StackRox. The security lapse was due to the parsing of a  Kubernetes API server deployment called YAML (Yet Another Markup Language) which is used for specifying configuration-type information. This security issue makes the cluster’s Kubernetes API service vulnerable to an attack called “billion laughs”. The billion laughs attack is a type of denial-of-service (DoS) attack. The vulnerability has got a CVE-2019-11253, however, the details of the security attack are reserved till the Kubernetes organization makes the security problem public. Kubernetes has not yet released a security patch to fix the underlying vulnerability. StackRox states, “The issue once again serves as a reminder that, like all software, Kubernetes is vulnerable to zero-day exploits. Thus, mere access to your Kubernetes API server should be treated as sensitive, regardless of how tight your application-level authorization policies (i.e., Kubernetes RBAC) are.” Read Also: CNCF-led open-source Kubernetes security audit reveals 37 flaws in Kubernetes cluster; recommendations proposed The Kubernetes cluster’s master and its resources are contacted by the Kubernetes API service which is backed by the Kubernetes apiserver. The Kubernetes apiserver accepts the incoming connections, after checking their authenticity of the entity and then applies the corresponding request handlers. One of the types of payloads that is accepted by the Kubernetes API service is exclusive to the YAML manifests and is concerned with the use of “references”. These references to nodes can be used in nodes that are themselves referenced in other nodes. This nesting of references and its subsequent expansion is the reason behind the current security vulnerability in the Kubernetes API. The Kubernetes apiserver does not perform any input validation on the uploaded YAMLs, and also does not impose hard limits on the size of the expanded file. These non-responsive actions make the Kubernetes apiserver an easy target. Thus, StackRox believes that only a clear fix to the Kubernetes apiserver code can safeguard the Kubernetes GitHub repository from this “billion laughs” attack. Read Also: Kubernetes 1.16 releases with Endpoint Slices, general availability of Custom Resources, and other enhancements StackRox recommends to protect the Kubernetes API server Users should analyze the Role-based access control (RBAC) policies of the Kubernetes to ensure that only reliable entities hold privileged access to a cluster’s resources. The cluster roles must be audited regularly. Users should be cautioned to keep the privileges of entities with low or no trust as unauthenticated users. Users should also disable any anonymous access by passing the --anonymous-auth=false flag to both the API server and the Kubelets. It should be noted that any small information like the API server version or the fact that the Kubernetes API server is running on a particular host can also be a piece of valuable information to the attacker. The Kubernetes API server endpoint should not be exposed to the internet, instead, it should be made secure using network firewalls. The API server access should only be given to trustworthy (private) subnets or VPC networks. Head over to the Stackrox page for more details on the security vulnerability of Kubernetes API. 6 Tips to Prevent Social Engineering How Chaos Engineering can help predict and prevent cyber-attacks preemptively An unpatched vulnerability in NSA’s Ghidra allows a remote attacker to compromise exposed systems GitLab 11.7 releases with multi-level child epics, API integration with Kubernetes, search filter box and more Pivotal open sources kpack, a Kubernetes-native image build service

Yesterday, GitHub announced that it now supports Web Authentication (WebAuthn) for security keys. In addition to time-based one-time password (TOTP) applications and text messages, you can now also configure two-factor authentication using a security key. https://twitter.com/github/status/1164240757278027779 WebAuthn is a standard by W3C that uses a public key instead of passwords or SMS texts for registering and authentication. It leverages strong authenticators that come built into devices like Windows Hello or Apple’s Touch ID. The purpose behind WebAuthn is not only to address security problems like phishing and data breaches but also significantly increase ease of use. Citing the reason behind bringing this support, Lucas Garron, GitHub’s Security Engineer, wrote in the announcement, “Account security is critical for GitHub. Although we support strong authentication options, many people still don’t use a password manager or two-factor authentication because individual passwords have always been the easiest choice.” You will be able to use physical security keys on GitHub if you are using the following: Firefox and Chrome-based browsers on Windows, macOS, Linux, and Android Edge users on Windows Brave on iOS using the new YubiKey 5Ci Safari Technology Preview on macOS GitHub also allows using your laptop or phone as a security key if you do not want to carry an actual physical key. For this, you are required to register your device first. People using Microsoft Edge on Windows can register their device using Windows Hello with facial recognition, fingerprint reader, or PIN. Chrome users on macOS can use Touch ID, while on Android they can use the fingerprint reader to register their device. Currently, security keys are secondary to authentication with a TOTP application or a text message. As more platforms start supporting security keys, GitHub plans to eventually make them the primary second factor. “Because platform support is not yet ubiquitous, GitHub currently supports security keys as a supplemental second factor. But we’re evaluating security keys as a primary second factor as more platforms support them. In addition, WebAuthn can make it possible to support login using your device as a “single-factor” security key with biometric authentication instead of a password,” Garron said. This announcement got mixed reactions from users. While some think that security keys are future of online authentication, others believe that we are better off with just a plain username-and-password authentication. The concerns users have for fingerprints and other biometric means for authentication is that they are not really a secret and if in case they are compromised there is no way to reset them. https://twitter.com/probonopd/status/1164241777089548289 Those supportive of this step are excited about the ease of use WebAuthn brings. A user on Hacker News commented, "This is fantastic. I look forward to finally having much easier authentication on the web. Imagine browsers syncing between devices a single encryption key that will authenticate you to all sites, which you can easily back up to a piece of paper." Another user suggested, "In a somewhat related vein: it would be really fantastic if Github allowed the same SSH key (in my case: a Yubikey-resident SSH key) on multiple accounts; we use separate accounts for different clients, and Github's refusal to allow an SSH key to be used on multiple accounts means I can't use Yubikey SSH keys for those." If you’d like to add support for security keys as an authentication option for your web service, you can use a JSON. Check out the official announcement by GitHub to know in detail. GitHub deprecates and then restores Network Graph after GitHub users share their disapproval DockerHub database breach exposes 190K customer data including tokens for GitHub and Bitbucket repositories Apache Software Foundation finally joins the GitHub open source community  

With the GDPR deadline looming closer everyday, Microsoft has started to apply General Data Protection Regulation (GDPR) to its cloud services. Microsoft recently announced that they are providing some enhancements to help organizations using Azure and Office 365 services meet GDPR requirements. With these improvements they aim at ensuring that both Microsoft's services and the organizations benefiting from them will be GDPR-compliant by the law's enforcement date. Microsoft tools supporting GDPR compliance are as follows: Service Trust Portal, provides GDPR information resources Security and Compliance Center in the Office 365 Admin Center Office 365 Advanced Data Governance for classifying data Azure Information Protection for tracking and revoking documents Compliance Manager for keeping track of regulatory compliance Azure Active Directory Terms of Use for obtaining user informed consent Microsoft recently released a preview of a new Data Subject Access Request interface in the Security and Compliance Center and the Azure Portal via a new tab. According to Microsoft 365 team, this interface is also available in the Service Trust Portal. Microsoft Tech Community post also claims that the portal will be getting a "Data Protection Impacts Assessments" section in the coming weeks. Organizations can now perform a search for "relevant data across Office 365 locations" with the new Data Subject Access Request interface preview. This helps organizations search across Exchange, SharePoint, OneDrive, Groups and Microsoft Teams. As explained by Microsoft, once searched the data is exported for review prior to being transferred to the requestor. According to Microsoft, the Data Subject Access Request capabilities will be out of preview before the GDPR deadline of May 25th. It also claims that IT professionals will be able to execute DSRs (Data Subject Requests) against system-generated logs. To know more in detail you can visit Microsoft’s blog post.

A zero-day vulnerability in Apple's iMessage, which bricks an iPhone and survives hard resets was recently brought to light. A specific type of malformed message is sent out to a victim device, forcing users to factory-reset it again. The issue was first posted by Google Project Zero researcher, Natalie Silvanovich on the project’s issue page on April 19, 2019. Due to the usual 90-day disclosure deadline, the bug is held from public view until either 90 days had elapsed or a patch had been made broadly available to the public. On 4th July, Silvanovich revealed that the issue was fixed in the Apple iOS 12.3 update, thus making it public. Labelled as CVE-2019-8573 and CVE-2019-8664, this vulnerability causes a Mac to crash and respawn. Silvanovich says on an iPhone, this code is in Springboard and “receiving this message will cause Springboard to crash and respawn repeatedly, causing the UI not to be displayed and the phone to stop responding to input. The only way I could find to fix the phone is to reboot into recovery mode and do a restore. This causes the data on the device to be lost”. According to Forbes, “The message contains a property with a key value that is not a string, despite one being expected. Calling a method titled IMBalloonPluginDataSource _summaryText, the method assumes the key in question is a string but does not verify it is the case”.  The subsequent call for IMBalloonPluginDataSource replaceHandlewithContactNameInString calls for im_handleIdentifiers for the supposed string, which in turn results in a thrown exception.  For testing purposes, Silvanovich, in her patch update has shared three ways that she found to unbrick the device: wipe the device with 'Find my iPhone' put the device in recovery mode and update via iTunes (note that this will force an update to the latest version) remove the SIM card and go out of Wifi range and wipe the device in the menu Google Project Zero has also released instructions to reproduce the issue: install frida (pip3 install frida) open sendMessage.py, and replace the sample receiver with the phone number or email of the target device in the local directory, run: python3 sendMessage.py Users should make sure their iPhone is up to date with the latest iOS 12.3 update. Read more about the vulnerability on Google Project Zero’s issue page. Approx. 250 public network users affected during Stack Overflow's security attack Google researcher reveals an unpatched bug in Windows’ cryptographic library that can quickly “take down a windows fleet” All about Browser Fingerprinting, the privacy nightmare that keeps web developers awake at night

Yesterday, the U.S. Customs and Border Protection(CBP) revealed a data breach occurrence exposing the photos of travelers and vehicles traveling in and out of the United States. CBP first learned of the attack on May 31 and said that none of the image data had been identified “on the Dark Web or Internet”. According to a CBP spokesperson, one of its subcontractors transferred images of travelers and license plate photos collected by the agency to its internal networks, which were then compromised by the attack. The agency declined to name the subcontractor that was compromised. They also said that its own systems had not been compromised. “A spokesperson for the agency later said the security incident affected “fewer than 100,000 people” through a “few specific lanes at a single land border” over a period of a month and a half”, according to TechCrunch. https://twitter.com/AJVicens/status/1138195795793055744 “No passport or other travel document photographs were compromised and no images of airline passengers from the air entry/exit process were involved,” the spokesperson said. According to The Register’s report released last month, a huge amount of internal files were breached from the firm Perceptics and were being offered for free on the dark web to download. The company’s license plate readers are deployed at various checkpoints along the U.S.-Mexico border. https://twitter.com/josephfcox/status/1138196952812806144 Now, according to the Washington Post, “in the Microsoft Word document of CBP’s public statement, sent Monday to Washington Post reporters, included the name “Perceptics” in the title: CBP Perceptics Public Statement”. “Perceptics representatives did not immediately respond to requests for comment. CBP spokeswoman Jackie Wren said she was “unable to confirm” if Perceptics was the source of the breach.”, the Washington post further added. In a statement to The Post, Sen. Ron Wyden (D-Ore.) said, “If the government collects sensitive information about Americans, it is responsible for protecting it — and that’s just as true if it contracts with a private company.” “Anyone whose information was compromised should be notified by Customs, and the government needs to explain exactly how it intends to prevent this kind of breach from happening in the future”, he further added. ACLU senior legislative counsel, Neema Singh Guliani said that the breach “further underscores the need to put the brakes” on the government’s facial recognition efforts. “The best way to avoid breaches of sensitive personal data is not to collect and retain such data in the first place,” she said. Jim Balsillie on Data Governance Challenges and 6 Recommendations to tackle them US blacklist China's telecom giant Huawei over threat to national security Privacy Experts discuss GDPR, its impact, and its future on Beth Kindig’s Tech Lightning Rounds Podcast

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

Google’s Project Zero disclosed a zero-day Android exploit in popular devices from Pixel, Huawei, Xiaomi, and Samsung, last Friday. This flaw unlocks root-level access and requires no or minimal customization to root a phone that’s exposed to the bug. A similar Android OS flaw was fixed in 2017 but has now found its way on newer software versions as well. The researchers speculate that this vulnerability is attributed to the NSO group based in Israel. Google has published a proof of concept which states that it is a kernel privilege escalation which uses a ‘use-after-free’ vulnerability, accessible from inside the Chrome sandbox. How does the zero-day Android exploit work As described in the upstream commit, “binder_poll() passes the thread->wait waitqueue that can be slept on for work. When a thread that uses epoll explicitly exits using BINDER_THREAD_EXIT, the waitqueue is freed, but it is never removed from the corresponding epoll data structure. When the process subsequently exits, the epoll cleanup code tries to access the waitlist, which results in a use-after-free.” Basically, the zero-day Android exploit can gain arbitrary kernel read/write when running locally. If the exploit is delivered via the web, it only needs to be paired with a renderer exploit, as this vulnerability is accessible through the sandbox. The vulnerability is exploitable in Chrome's renderer processes under Android's 'isolated_app' SELinux domain, making Binder as the vulnerable component. Affected devices include Pixel, Pixel XL, Pixel 2, Pixel 2 XL, Huawei P20, Redmi 5A, Redmi Note 5, Mi A1, Oppo A3, Moto Z3, Oreo LG phones, Samsung Galaxy S7, Samsung Galaxy S8, and Samsung Galaxy S9.  This vulnerability was earlier patched in the Linux kernel version 4.14 and above, but without a CVE. Now, the vulnerability is being tracked as CVE-2019-2215. “This issue is rated as High severity on Android and by itself requires installation of a malicious application for potential exploitation. Any other vectors, such as via web browser, require chaining with an additional exploit,” Project Zero member Tim Willis wrote in the post. Project Zero normally offers a 90-day timeline for developers to fix an issue before making it public, but since this vulnerability was exploited in the wild, it was published in just seven days. In case 7 days elapse or a patch is made broadly available (whichever is earlier), the bug report will become visible to the public. Google said that affected Pixel devices will have the zero-day Android exploit patched in the upcoming October 2019 Android security update. Other OEMs have not yet acknowledged the vulnerability, but should ideally release patches soon. An unpatched security issue in the Kubernetes API is vulnerable to a “billions laugh attack” An unpatched vulnerability in NSA’s Ghidra allows a remote attacker to compromise exposed systems A Cargo vulnerability in Rust 1.25 and prior makes it ignore the package key and download a wrong dependency. New iPhone exploit checkm8 is unpatchable and can possibly lead to permanent jailbreak on iPhones. Google’s Project Zero reveals several serious zero-day vulnerabilities in a fully remote attack surface of the iPhone.

Phishing attacks these days are a common phenomenon. Fraudsters use technical tricks and social engineering to deceive users into revealing sensitive personal information such as usernames, passwords, account IDs, credit card details and social security numbers through fake emails. Gophish provides a framework to simulate real-world phishing attacks. This enables industries to avail phishing training to make employees more aware of security in their business. Gophish is an open-source phishing toolkit written in Golang, specially designed for businesses and penetration testers. It is  This means that the Gophish releases do not have any dependencies. It's easy to set up and run and can be hosted in-house. Here are some of the features of Gophish #1 Ease of use Users can easily create or import pixel-perfect phishing template while customizing their templates in their browser itself. Phishing emails can be scheduled and can be sent in the background. Results of the simulation are delivered in near real-time. #2 Cross Platform Gophish can be used across platforms like Windows, Mac OSX, and Linux. #3 Full REST API The framework is powered with REST API. Gophish’s Python client makes it really easy to work with the API. #4 Real-Time Results Results obtained by Gophish are updated automatically. Users can view a timeline for every recipient, track if the email was opened, link clicks, submitted credentials, and more. Damage caused by phishing in a corporate environment can have dangerous repercussions like loss or misuse of confidential data, ruining the consumer's trust in the brand, use of corporate network resources etc. The Gophish framework aims to help industry professionals learn how to tackle phishing attacks with its ease of setup, use, and powerful results. To learn more about how to use Gophish and its benefits, head over to their official Blog. Google’s Protect your Election program: Security policies to defend against state-sponsored phishing attacks, and influence campaigns Microsoft claims it halted Russian spear phishing cyberattacks IBM launches Industry’s first ‘Cybersecurity Operations Center on Wheels’ for on-demand cybersecurity support

A few days ago, a German security agency CERT-Bund revealed it had found a Remote Code Execution (RCE) flaw in the popular open-source, VLC Media Player allowing hackers to install, modify, or run any software on a victim’s device without their authority and could also be used to disclose files on the host system. The vulnerability (listed as CVE-2019-13615) was first announced by WinFuture and received a vulnerability score of 9.8 making it a "critical" problem. According to a release by CERT-Bund, “A remote, anonymous attacker can exploit a vulnerability in VLC to execute arbitrary code, create a denial of service state, disclose information, or manipulate files.” According to Threat Post, “Specifically, VLC media player’s heap-based buffer over-read vulnerability exists in mkv::demux_sys_t::FreeUnused() in the media player’s modules/demux/mkv/demux.cpp function when called from mkv::Open in modules/demux/mkv/mkv.cpp.” VLC is not vulnerable, VideoLAN says Yesterday, VideoLAN, the makers of VLC, tweeted that VLC is not vulnerable. They said, “the issue is in a 3rd party library, called libebml, which was fixed more than 16 months ago. VLC since version 3.0.3 has the correct version shipped, and @MITREcorp did not even check their claim.” https://twitter.com/videolan/status/1153963312981389312 VideoLAN said a reporter, opened a bug on their public bug tracker, which is outside of the reporting policy and should have mailed in private on the security alias. “We could not, of course, reproduce the issue, and tried to contact the security researcher, in private”, VideoLAN tweeted. VideoLAN said the reporter was using Ubuntu 18.04, an old version of Ubuntu and “clearly has not all the updated libraries. But did not answer our questions.” VideoLAN says it wasn’t contacted before the CVE was issued VideoLAN is quite unhappy that MITRE Corp did not approach them before issuing a CVE for the VLC vulnerability, which is a direct violation of MITRE’s own policies. Source: CVE.mitre.org https://twitter.com/videolan/status/1153965979988348928 When VideoLAN complained and asked if they could manage their own CVE (like another CNA), “we had no answer and @usnistgov NVD told us that they basically couldn't do anything for us, not even fixing the wrong information”, they tweeted. https://twitter.com/videolan/status/1153965981536010240 VideoLAN said even CERT Bund did not contact them for clarifications. They further added, “So, when @certbund decided to do their "disclosure", all the media jumped in, without checking anything nor contacting us.” https://twitter.com/videolan/status/1153971024297431047 The VLC CVE on the National Vulnerability Database has now been updated. NVD has downgraded the severity of the issue from a Base Score of 9.8 (critical) to 5.5 (medium). Also, the changelog specifies that the “Victim must voluntarily interact with attack mechanism.” Dan Kaminsky, an American security researcher, tweeted, “A couple of things, though: 1) Ubuntu 18.04 is not some ancient version 2) Playing videos with VLC is both a first-class user demand and a major attack surface, given the realities of content sourcing.  If Ubuntu can't secure VLC dependencies, VLC probably has to ship local libs.” https://twitter.com/dakami/status/1154118377197035520 Last month, VideoLAN fixed two high severity bugs in their security update for the VLC media player. The update included fixes for 33 vulnerabilities in total, of which two were marked critical, 21 medium and 10 rated low. Jean-Baptiste Kempf, president of VideoLAN and an open-source developer, wrote, “This high number of security issues is due to the sponsoring of a bug bounty program funded by the European Commission, during the Free and Open Source Software Audit (FOSSA) program”. To know more about this news in detail, you can read WinFuture’s blog post. The EU Bounty Program enabled in VLC 3.0.7 release, this version fixed the most number of security issues A zero-day vulnerability on Mac Zoom Client allows hackers to enable users’ camera, leaving 750k companies exposed VLC’s updating mechanism still uses HTTP over HTTPS

Yesterday Aleksa Sarai, Senior Software Engineer at SUSE Linux GmbH, notified users that the ‘docker cp' is vulnerable to symlink-exchange race attacks. This attack makes all the Docker versions vulnerable. This attack can be seen as a continuation of some 'docker cp' security bugs that Sarai had found and fixed in 2014. This attack was discovered by Sarai, “though Tõnis Tiigi (software engineer at Docker) did mention the possibility of an attack like this in the past (at the time we thought the race window was too small to exploit)”, he added. The basis of this attack is that FollowSymlinkInScope suffers from a fundamental TOCTOU attack. FollowSymlinkInScope is used to take a path and resolve it safely as though the process was inside the container. Once the full path is resolved, it is passed around a bit and operated later on. If an attacker adds a symlink component to the path after the resolution, but before it is operated on, then the user will end up resolving the symlink path component on the host as root. Sarai adds, “As far as I'm aware there are no meaningful protections against this kind of attack. Unless you have restricted the Docker daemon through AppArmor, then it can affect the host filesystem”. Two reproducers of the issue have been attacked, including a Docker image and an empty directory in a loop hoping to hit the race condition. The Docker image contains a simple binary that does a RENAME_EXCHANGE of a symlink to "/”. In both the scripts, the user will be trying  to copy a file to or from a path containing the swapped symlink. However, the run_write.sh script can overwrite the host filesystem in very few iterations. This is because internally Docker has a "chrootarchive" concept where the archive is extracted from within a chroot. However in Docker, it chroots into the parent directory of the archive target which can be controlled by the attacker. This makes the attacker more likely to succeed. In an attempt to come up with a better solution for this problem, Sarai is working on Linux kernel patches. This will “add the ability to safely resolve paths from within a roots”. Users are concerned with the Docker versions being vulnerable as ‘docker cp’ is a very popular command. A user on Reddit says, “This seems really severe, it basically breaks a lot of the security that docker is assumed to provide. I know that we're often told not to rely upon docker for security, but still. I guess trusted but unsecure containers where the attack is executed after startup are still safe, because the docker cp command has already been executed before the attack begins.” A user on Hacker News comments, “So from a reading of the advisory and pull request, this seems to affect a specific set of scenarios, where a malicious image is running. Not sure if there are other scenarios where this would hit as well. One to be aware of, but as with most vulnerabilities, good to understand how it can be exploited, when you're assessing mitigations” To read more details of the notification, head over to Sarai’s mailing list. Angular 8.0 releases with major updates to framework, Angular Material, and the CLI Canva faced security breach, 139 million users data hacked: ZDNet reports SENSORID attack: Calibration fingerprinting that can easily trace your iOS and Android phones, study reveals

IEEE Computer Society (IEEE-CS) released its annual tech future predictions, earlier this week, unveiling the top ten most likely to be adopted technology trends in 2019. "The Computer Society's predictions are based on an in-depth analysis by a team of leading technology experts, identify top technologies that have substantial potential to disrupt the market in the year 2019," mentions Hironori Kasahara, IEEE Computer Society President. Let’s have a look at their top 10 technology trends predicted to reach wide adoption in 2019. Top ten trends for 2019 Deep learning accelerators According to IEEE computer society, 2019 will see widescale adoption of companies designing their own deep learning accelerators such as GPUs, FPGAs, and TPUs, which can be used in data centers. The development of these accelerators would further allow machine learning to be used in different IoT devices and appliances. Assisted transportation Another trend predicted for 2019 is the adoption of assisted transportation which is already paving the way for fully autonomous vehicles. Although the future of fully autonomous vehicles is not entirely here, the self-driving tech saw a booming year in 2018. For instance, AWS introduced DeepRacer, a self-driving race car, Tesla is building its own AI hardware for self-driving cars, Alphabet’s Waymo will be launching the world’s first commercial self-driving cars in upcoming months, and so on. Other than self-driving, assisted transportation is also highly dependent on deep learning accelerators for video recognition. The Internet of Bodies (IoB) As per the IEEE computer society, consumers have become very comfortable with self-monitoring using external devices like fitness trackers and smart glasses. With digital pills now entering the mainstream medicine, the body-attached, implantable, and embedded IoB devices provide richer data that enable development of unique applications. However, IEEE mentions that this tech also brings along with it the concerns related to security, privacy, physical harm, and abuse. Social credit algorithms Facial recognition tech was in the spotlight in 2018. For instance, Microsoft President- Brad Smith requested governments to regulate the evolution of facial recognition technology this month, Google patented a new facial recognition system that uses your social network to identify you, and so on.  According to the IEEE, social credit algorithms will now see a rise in adoption in 2019. Social credit algorithms make use of facial recognition and other advanced biometrics that help identify a person and retrieve data about them from digital platforms. This helps them check the approval or denial of access to consumer products and services. Advanced (smart) materials and devices IEEE computer society predicts that in 2019, advanced materials and devices for sensors, actuators, and wireless communications will see widespread adoption. These materials include tunable glass, smart paper, and ingestible transmitters, will lead to the development of applications in healthcare, packaging, and other appliances.   “These technologies will also advance pervasive, ubiquitous, and immersive computing, such as the recent announcement of a cellular phone with a foldable screen. The use of such technologies will have a large impact on the way we perceive IoT devices and will lead to new usage models”, mentions the IEEE computer society. Active security protection From data breaches ( Facebook, Google, Quora, Cathay Pacific, etc) to cyber attacks, 2018 saw many security-related incidents. 2019 will now see a new generation of security mechanisms that use an active approach to fight against these security-related accidents. These would involve hooks that can be activated when new types of attacks are exposed and machine-learning mechanisms that can help identify sophisticated attacks. Virtual reality (VR) and augmented reality (AR) Packt’s 2018 Skill Up report highlighted what game developers feel about the VR world. A whopping 86% of respondents replied with ‘Yes, VR is here to stay’. IEEE Computer Society echoes that thought as it believes that VR and AR technologies will see even greater widescale adoption and will prove to be very useful for education, engineering, and other fields in 2019. IEEE believes that now that there are advertisements for VR headsets that appear during prime-time television programs, VR/AR will see widescale adoption in 2019. Chatbots 2019 will also see an expansion in the development of chatbot applications. Chatbots are used quite frequently for basic customer service on social networking hubs. They’re also used in operating systems as intelligent virtual assistants. Chatbots will also find its applications in interaction with cognitively impaired children for therapeutic support. “We have recently witnessed the use of chatbots as personal assistants capable of machine-to-machine communications as well. In fact, chatbots mimic humans so well that some countries are considering requiring chatbots to disclose that they are not human”, mentions IEEE.   Automated voice spam (robocall) prevention IEEE predicts that the automated voice spam prevention technology will see widespread adoption in 2019. It will be able to block a spoofed caller ID and in turn enable “questionable calls” where the computer will ask questions to the caller for determining if the caller is legitimate. Technology for humanity (specifically machine learning) IEEE predicts an increase in the adoption rate of tech for humanity. Advances in IoT and edge computing are the leading factors driving the adoption of this technology. Other events such as fires and bridge collapses are further creating the urgency to adopt these monitoring technologies in forests and smart roads. "The technical community depends on the Computer Society as the source of technology IP, trends, and information. IEEE-CS predictions represent our commitment to keeping our community prepared for the technological landscape of the future,” says the IEEE Computer Society. For more information, check out the official IEEE Computer Society announcement. Key trends in software development in 2019: cloud native and the shrinking stack Key trends in software infrastructure in 2019: observability, chaos, and cloud complexity Quantum computing, edge analytics, and meta learning: key trends in data science and big data in 2019

Stack overflow has expanded its Code of Conduct which previously focused on just “Being Nice” to include more virtues around kindness, collaboration, and mutual respect. Recently, there has been many supporters of the idea that Stack Overflow is a “toxic wasteland”. https://twitter.com/aprilwensel/status/974859164747931650 There is also a Reddit thread, from six months ago, where people have shared their woes on Stack Overflow being too toxic. This Code of Conduct is a formal, far less ambiguous and a more informative way of Stack Overflow to regulate belittling language and condescension. It is applicable to everyone using Stack Overflow and the Stack Exchange network, including the team, moderators, and anyone posting to Q&A sites or chat rooms. The Be Nice policy, since its inception in 2008, was a single guiding principle that everyone was expected to follow. However, just two words turned out to be too little, too ambiguous and later, in 2014, a revised version of the policy was released to reflect Stack Exchange as a better community than what was believed on the Internet. The revised version also added instructions on how to report rare cases of bad behavior.  However, this still was not specific enough to meet the needs of a much larger dynamic site Stack Overflow was growing to be. This is when, they decided to launch a more formal policy, one that covers “Be nice, here’s how, here’s why, and here’s what to do if someone isn’t.” The main tenets of the new code are: If you’re here to get help, make it as easy as possible for others to help you. If you’re here to help others, be patient and welcoming. Offer support if you see someone struggling or otherwise in need of help. Be clear and constructive when giving feedback, and be open when receiving it. Be kind and friendly. Avoid sarcasm and be careful with jokes, as tone can be hard to decipher online. The code also denounces subtle put-downs or unfriendly language, name-calling or personal attacks, bigotry, and harassment. Source: Stack Overflow In case someone is guilty of breaking the code of conduct, there are three stages: Warning: For most first-time misconduct, moderators will remove the offending content and send a warning. Account Suspension: For repetitive misconduct, moderators will impose a temporary suspension Account Expulsion: For very rare cases, moderators will expel people who display a pattern of harmful destructive behavior towards the community. The Stack Overflow team plans to assess the CoC by taking feedback, every 6 months, from both new and experienced users about their recent experiences on the site. They have also added a code of conduct tag which members can use on Meta Stack Exchange to ask questions about or propose changes to the CoC. You can go through the entire Code of Conduct on Stack Overflow. 10 predictable findings from Stack Overflow’s 2018 survey Stack Overflow Developer Survey 2018: A Quick Overview 4 surprising things from Stack Overflow’s 2018 survey 96% of developers believe developing soft skills is important