Recorded August 27, 2019 at G-Unit Studios in Rhode Island!
- We have exciting news about the Security Weekly webcast program: We are now partnered with (ISC)2 as an official CPE provider! If you attend any of our webcasts, you will be receiving 1 CPE credit per webcast! Register for one of our upcoming webcast with Zane Lackey of Signal Sciences, Ian McShane from Endgame, or Stephen Smith and Jeff Braucher of LogRhythm (or all 3!) by going to securityweekly.com/webcasts If you have missed any of our previously recorded webcasts, you can find our on-demand library at securityweekly.com/ondemand
- Hacker Finds Instagram Account Takeover Flaw Worth $10,000 | SecurityWeek.Com - India-based white hat hacker Laxman Muthiyah identified the flaw while looking at Instagram’s password recovery system for mobile devices, a process in which users receive a six-digit code on their phone and they have to enter it within 10 minutes to be allowed to change their password. Instagram developers have implemented some protection mechanisms to prevent attempts to obtain the code through brute-force attacks. However, according to Muthiyah, an ID that is randomly generated by the Instagram app for every device is included in the request when the password reset code is solicited. This device ID is also used to check the validity of the six-digit code.
- Code Execution Flaw in QEMU Mostly Impacts Development, Test VMs | SecurityWeek.Com - The security hole, described as a heap-based buffer overflow that can lead to a virtual machine (VM) escape, is related to Slirp, an old tool that can be used to emulate PPP, SLIP and CSLIP connections via a shell account. According to Wikipedia, Slirp is still useful for connecting mobile devices via their serial ports, and for firewall piercing and port forwarding...However, QEMU developer Stefan Hajnoczi clarified that production VMs typically do not use Slirp and CVE-2019-14378 mainly impacts users who run QEMU manually for development and testing purposes.
- Judge ordered Capital One hacker Paige Thompson to remain in prison - This story is getting bizare: A U.S. judge ordered Capital One hacker Paige Thompson to remain in custody pending trial because her “bizarre and erratic” behavior makes the woman at risk. The judge argued that she is a flight risk and poses a physical danger to herself and others. “In today’s America, it is easy enough to obtain firearms, and there is every reason to be concerned that Thompson, who repeatedly has threatened to kill, would obtain the means to carry out … her threats – particularly when confronted with the alternative of near-certain conviction and imprisonment,” prosecutors said in their motion to keep the woman in custody. In July, Capital One, one of the largest U.S. –card issuer and financial corporation suffered a data breach that exposed personal information from 106 million Capital One credit applications. Paige Thompson, that goes online with the handle “erratic,” breached the systems at Capital One and gained access to the huge trove of personal information. Law enforcement identified and arrested the hacker. The judge believes that Thompson should remain detained, for the time being, the woman had already attempted to commit “suicide by cop.”
- ThreatList: Half of All Social Media Logins Are Fraud - “The extremely high attack rate on social-media logins is indicative of the value placed on the data fraudsters extract from compromised social accounts,” said Kevin Gosschalk, CEO of Arkose, in a media statement. “Because more than 50 percent of social media logins are fraud, we know that fraudsters are using large-scale bots to launch attacks on social-media platforms with the goal of disseminating spam, stealing information, spreading social propaganda and executing social-engineering campaigns targeting trusting consumers.” From an overall digital fraud perspective, Arkose examined more than 1.2 billion transactions spanning account registrations, logins and payments from financial services, e-commerce, travel, social media, gaming and entertainment industries, and found that one in 10 transactions overall are malicious, ranging from automated bots to humans carrying out scams.
- Hackers are actively trying to steal passwords from two widely used VPNs - The vulnerabilities can be exploited by sending unpatched servers Web requests that contain a special sequence of characters, researchers at the Black Hat security conference in Las Vegas said earlier this month. The pre-authorization file-reading vulnerabilities resided in the Fortigate SSL VPN, installed on about 480,000 servers, and the competing Pulse Secure SSL VPN, installed on about 50,000 machines, researchers from Devcore Security Consulting reported. The Devcore researchers discovered other critical vulnerabilities in both products. These make it possible for attackers to, among other things, remotely execute malicious code and change passwords. Patches for the Fortigate VPN became available in May and in April for Pulse Secure. But installing the patches can often cause service disruptions that prevent businesses from carrying out essential tasks. Internet scans performed over the weekend by security intelligence service Bad Packets show there are 14,528 Pulse Secure VPN endpoints vulnerable to flaw that's currently being exploited, up from a previous scan that found about 2,658 unpatched servers.
- Biz forked out $115k to tout 'Time AI' crypto at Black Hat. Now it sues organizers because hackers heckled it - "This small group of detractors used this staged 'event' to initiate a smear campaign on social media during the conference and immediately after," the complaint stated. "In that campaign, these detractors defamed Crown Sterling, questioning both its integrity and its cryptography solutions, which they described in one publication as 'Snake Oil Crypto.'" In a phone interview with The Register, Dan Guido, CEO of infosec biz Trail of Bits, who attended the Black Hat presentation, barracked the presentation, and was removed from the room by conference security, argued Crown Sterling was trying to "mix mysticism and magic into science" and that "none of it made any sense."
- Apple released an emergency patch to address CVE-2019-8605 iOS flaw - Well, of course they did: Recently, Apple accidentally unpatched a vulnerability it had already fixed, making current versions of iOS vulnerable to hackers and allowing the jailbreak of the devices. Experts discovered that the iOS version 12.4 released in June has reintroduced a security flaw found by a Google Project Zero white hat hacker that was previously fixed in iOS 12.3. A public Jailbreak for iPhones in was published by the Pwn20wnd hacker, it works with the latest version of the iOS mobile operating system. Google Project Zero expert Ned Williamson confirmed that the jailbreak worked on his iPhone. The flaw potentially exposed iPhone devices running 12.4 version and older iOS versions (any 11.x and 12.x below 12.3) to the risk of a hack until the 12.4.1will be released.
- GitHub joins WebAuthn club - This is great! WebAuthn supersedes U2F and offers everything the older standard did along with some additional benefits: It upgrades GitHub’s 2FA support to the latest industry standard. The World Wide Web Consortium (W3C), which oversees many of the standards that make up the web, approved WebAuthn as an official standard in March 2019. While you can use a third-party hardware security key to use WebAuthn, in many cases you don’t need to. You can also use a digital key stored on your phone instead, turning the phone itself into your hardware key. WebAuthn can be a primary access factor. U2F still needed a password to gain access, meaning that it could only ever be a second factor in your login process. The U2F-based physical key effectively said “yes, the person entering that password is legit, because I am in their possession”.
- Vast majority of newly registered domains are malicious | SC Media - The NRDs are an interesting breed with some staying active for a very brief period, just hours, while others are quickly spotted behaving as command and control servers or distributing malware, phishing attacks or used for typosquatting. For the most part NRDs are registered under the .com TLD, but those registered under a country code extension tend to be malicious in nature. Palo Alto Networks found NRDs registered as .to (Tongo) and .di Kiribati) had the highest rate of nasty domains with more than 90 percent in each case being considered malicious or suspicious. Courtesy Palo Alto Networks: Top 15 TLDs with the highest malicious NRD rate. Because there are such a high number of NRDs from specific locations Palo Alto Networks recommends combatting the problem using URL filtering.
In a time where we read about entire cities being shut down due to ransomware outbreaks, the idea of having an incident response plan should not be a new one. However, Like many of you, I’ve experienced situations where things that seemed too ridiculous have actually occurred. So let’s talk about the basics of having an incident response plan. The idea of having such a plan in place is so that you don’t have to make it up in the middle of the incident. Having experienced a couple of incidents like this early in my career, I can attest to the fact that it is not an experience you want to have.
There are a few components should be in every incident response plan. First, are some non-technical concerns. There are a number of questions that you need to ask and have answers for. Things like, who is in charge and how does communication flow? How do things get reported? Who can declare an incident? Who should be involved in responding to an incident? These may seem to have obvious answers, but the opinions on them can vary wildly. Especially if a system owner realizes that an incident being declared may result in their application going offline for a period of time.
Next, are the technical components. You need to make sure you have the proper people available during an incident and backups in case they are unavailable. It needs to be determined what software and equipment will be needed. A number of years ago, I wrote a blog post on this topic and gave some suggestions for tools and software. It’s a little dated in some areas, but you can check it out via the link to that in the show notes. At a mimimim, you are going to need storage for evidence, forensics software, various cables, and software to help in analyzing the system. Built-in OS commands may be tampered with, so be prepared with tools that are trusted and your team knows how to use.
One thing that I really like the idea of is tabletop exercises. When I first heard of this idea, I really didn’t respond well to it. It seemed like there was too much opportunity to game the exercise and make it scripted for success. That’s still a risk, but if done right they can be invaluable in figuring out who needs to be involved for a set of systems, who needs to be making decisions and making these individuals aware that they are responsible for making them. If you ask someone to make a decision to take an important application down during a crisis with no preparation, you are going to end up with a bad decision. Or more likely, no decision at all. They will try to pass the responsibility for that to someone else. They aren’t sure what the right answer is because they aren’t ready for it. A tabletop exercise allows them to get that experience and start thinking about those decisions before they start fearing for their job. After all, it’s only an exercise.
I don’t know where Black Hills Information Security got the idea of using Dungeons and Dragons d20 dice to determine the success or failure of decisions in a tabletop, but I really like it. As people make a decision on what to do, roll the d20 to see if it works. If you need to do forensics and have someone trained in forensics, give it a +5 to succeed. It so simple and removes you from being accused of gaming the exercise.
Incident response is a fairly large topic and what we’ve covered today only scratches at the surface of it. The main point is that trying to figure out who needs to be in charge, who needs to be involved, and what tools you need during an incident is a disaster. Period. Take some time to make preparations ahead of time. If you are working in an organization that doesn’t see the need for such a thing and doesn’t want to devote any resources to it, then I’d recommend working on your own to create a rough plan. It doesn’t have to be perfect, as this is a rough plan, but get something written down. Email it to your manager with a message saying something like, “Hey I was thinking about what an IR plan might look like and this is what I came up with?” That way you’ve made it known that you are attempting to address a gap and it is in writing. When something does go wrong and the painful response begins, you will have at least protected yourself a little bit from accusations that you should have done something earlier. And you give your plan a pretty good shot at being implemented before the next incident arrives.