Cisco Systems is urging customers to update several models of their IP phones after issuing patches for five high-severity flaws found in its popular business-focused IP phones. Impacted are Cisco’s IP Phone 8800 series, which are business desk phones that have HD video included and its IP Phone 7800 series, which are meant for desktops and conference rooms in businesses. The vulnerabilities could allow unauthenticated, remote attackers to conduct a cross-site request forgery attack, launch denial of service attacks or write arbitrary files to the targeted device’s filesystem. Cisco released the patches on Wednesday adding the most serious of these flaws is a cross-site request forgery vulnerability found in the Cisco IP Phone 8800 series. Cross-site request forgery is an attack that forces an end user to execute unwanted actions (changing their email, transferring funds, etc.) on a web application in which they’re currently authenticated. The vulnerability (CVE-2019-1764) has a CVSS score of 8.1, and stems from insufficient cross-site request forgery protections for the web-based management interface of the phone’s software. Cisco said that a remote, unauthenticated attacker could exploit this vulnerability by persuading an authenticated user of the interface to follow a special crafted link: “A successful exploit could allow the attacker to perform arbitrary actions on a targeted device via a web browser and with the privileges of the user,” according to the advisory. Another serious vulnerability in the IP Phone 8800 series is a path traversal flaw (CVE-2019-1765) which has a CVSS score of 8.1. This flaw also exists in the web-based management interface of the phone’s software, and could allow an authenticated, remote attacker to write arbitrary files to the filesystem, Cisco said. “The vulnerability is due to insufficient input validation and file-level permissions,” said Cisco. “An attacker could exploit this vulnerability by uploading invalid files to an affected device. A successful exploit could allow the attacker to write files in arbitrary locations on the filesystem.” The IP Phone 8800 series running Session Initiation Protocol (SIP) Software prior to version 11.0(5) (for Wireless IP Phone 8821-EX), or version 12.5(1)SR1 (for the IP Conference Phone 8832 and the rest of the IP Phone 8800 Series), are vulnerable to both these flaws and can upgrade to those latest versions. The Cisco IP Phone 8800 series also has a file upload denial of service flaw in the web-based management interface feature of its software. The vulnerability (CVE-2019-1766), which has a CVSS score of 7.5, could allow a remote attacker to cause high disk utilization, resulting in denial of service. That’s because the impacted software does not restrict the maximum size of certain files that can be written to disk – so an attacker who has valid administrator credentials for an affected system could exploit the flaw by sending a crafted, remote connection request to an affected system. “A successful exploit could allow the attacker to write a file that consumes most of the available disk space on the system, causing application functions to operate abnormally and leading to a DoS condition,” said Cisco. Cisco said that IP Phone 8800 series products running a SIP Software release prior to 12.5(1)SR1 are impacted and should upgrade. Cisco also patched an authorization bypass vulnerability (CVE-2019-1763) in its IP Phone 8800 series, which could allow an unauthenticated, remote attacker to bypass authorization, access critical services, and launch a denial of service attack. “The vulnerability exists because the software fails to sanitize URLs before it handles requests,” according to Cisco. “An attacker could exploit this vulnerability by submitting a crafted URL. A successful exploit could allow the attacker to gain unauthorized access to critical services and cause a DoS condition.” Finally, Cisco patched a remote code execution flaw in its IP Phone 7800 series and 8800 series, which could allow an unauthenticated, remote attacker to cause a denial of service condition or execute arbitrary code. Because the phones’ software improperly validates user-supplied input during user authentication, an attacker could exploit this vulnerability by connecting to an affected device using HTTP and supplying malicious user credentials. “A successful exploit could allow the attacker to trigger a reload of an affected device, resulting in a DoS condition, or to execute arbitrary code with the privileges of the app user,” said Cisco. The patches come a week after Cisco fixed a critical vulnerability allowing adversaries to access monitoring system used for gathering info on operating systems and hardware.
In the era of the cloud, enterprises house sensitive corporate data outside of the traditional perimeter; employees can access this from any endpoint, including mobile devices, and from any network. This presents a host of new challenges for companies looking to protect their sensitive information. On this webinar replay, Threatpost’s Tara Seals is joined by Gartner’s Patrick Hevesi, Lookout’s David Richardson, and Google/Android’s Mike Burr to talk about practical strategies for locking down this work-from-anywhere environment, for both the Android and iOS ecosystems. Hevesi presents a working, vendor-agnostic framework for evaluating risk and determining solution approaches, while Richardson discusses real-world threats and the most common attack vectors that enterprises need to defend against. Burr meanwhile talks about specific aspects of the Android Enterprise ecosystem that organizations can leverage to manage their devices for security. And finally, a Q&A covers user awareness, two-factor authentication, APT threats, mobile VPNs and more. Below is the transcription of this webinar, in its entirety. Tara Seals: Hello, everyone. Thank you for attending today’s Threatpost webinar, titled Enterprise Mobility and Post-Perimeter Security: Inside the Evolving Mobile Enterprise Threat Landscape. Let me introduce myself. I’m Tara Seals, senior editor at Threatpost. I’ll be your moderator today. I’m excited to welcome our panelists. We have a really great set of thought leaders today who are going to give a comprehensive dive into the developing area of mobile enterprise security. There are a lot of challenges in the space, as we know, and it’s proving difficult to address them with a legacy security model. We’ll talk a little bit about the top challenges, some best practices for adjusting to them, and thoughts for the future, what might be coming down the pike. Today we’re going to hear first from Patrick Hevesi, who is senior director analyst at Gartner. He’s going to frame our discussion by talking about some of the top mobile enterprise security challenges. He’s also going to offer a pretty interesting framework for [helping] administrators to decide how to address them. Next up, we’re going to hear from David Richardson, who is senior director of product management of Lookout. He’s going to discuss what they’ve been seeing in terms of their telemetry and threat intelligence, and talk about some specific threats, real campaigns and also some best practices for defending against those. Finally, we’ll hear from Mike Burr, who is the platform specialist for Android Enterprise at Google. He’s going to address some perceived threats to the Android ecosystem, along with some of the best practices for managing Android devices within in the enterprise. We have a lot to get through, so I’m going to turn it right over to Patrick to get us started. Patrick, over to you. Gartner’s Patrick Hevesi, Senior Director Analyst Patrick Hevesi: Hello. Thank you. Can everybody hear me? Yes. Thank you, Tara. Let’s start with talking about what mobile attack vectors look like. In IT, we’ve been accustomed to defending our desktops, PCs and our servers for many, many years, but the mobile attack vectors are slightly different. See, now we’re just not thinking about these websites that people are clicking on their phones, they’re installing applications from app stores, they’re getting SMS text messages with possible tiny URL links from colleagues or hackers or different sources throughout, and then possibly clicking on them and actually being led to web pages or possible other downloads. Then you walk into a Starbucks, you walk into an airport café. Are you really on that WiFi? How do you know for sure that you’ve connected to a safe and secure thing? Government organizations care about things like, are you on the right cellular tower? Is someone trying to listen in and trying to intercept your call, intercept that actual voice traffic and possibly do something malicious? Then, of course, possibly somebody comes in and tries to do a Bluetooth-based or a near-field communication attack. That’s very proximity-based. Let’s say the device then becomes infected through one of these means and then you come into your organization. You join the VPN, you get onto the corporate WiFi. You plug that device through USB into your PC or your Mac. The hackers are trying to listen for those different aspects to possibly come into your organization as well. Thinking about these new attack surfaces, how do you actually start trying to address these? What are some of the different threats out there? You’ll hear from our colleagues about some other examples, but we’re starting to see that there are these different malwares and vulnerabilities that are approaching. This is just a short, small list of what we’ve seen, with some historical ramifications as well. In 2017, we started seeing ransomware on Android. One example was a ransomware that was actually targeting based upon the geographic location of that device. If you were in the United States, it would pop up an FBI warning saying that you need to call the FBI right now because you’re doing something malicious. If you actually did call in, they would ask for Bitcoin. Obviously, the [real] FBI wouldn’t do something like that. But that same ransomware was then used in Canada. They looked at the phones in Canada and a Royal Canadian Mounted Police ransomware screen popped up as well. [Other threats run the gamut from] kernel privilege-escalation attempts to possibly even opening up SOCKS backdoors inside and looking for proxies as they come onto your network. And not just on Android, but on iOS. Here are some examples. One of the bigger ones that happened a few years ago was the Pegasus/Trident [incident]. It was actually a Safari-based exploit, a low-level exploit. The attackers were able to send an SMS message to that device, you clicked it, it would start the Safari browser on iOS and then immediately crash. What would the end user do? What would you have done when that happened? What happened in the background was that exploit found a targeted vulnerability inside the device, actually then installed surveillance software without you knowing anything was happening. We saw people just click that link again, trying to get to that link yet again and again. By that time, that low-level escalation was already done, that everything that was then typed on that device was then being transmitted to malicious sites. Not only are they attacking the devices, but years ago, there were some Chinese attacks based on the Xcode developer platform, where they actually installed and built a maliciously infected Xcode developer set of tools and they were delivering it to developers all over China rather than coming all the way back to the Apple site. They were actually pushing those out to local developers, and those local developers, and everything written with those XcodeGhost-infected platforms, had malware, over 4,000 apps. There are malicious profile attacks as well, so thinking about iOS, as you install a management profile. There are also configuration profiles. But you could see here there are many different ways that these different attacks can be leveraged. What do we do about that? At Gartner, we came up with a mobile security strategy, and there’s some prework that has to be done. You have to start considering what type of data is actually being installed on the devices. Different levels of data will require different types of tools and technologies and security solutions. Higher-secured data won’t require additional security practices, tools, configurations, obviously. Then you’ll also have to look at possible business requirements: You may have specific mobile applications that only run on a specific platform — as well [as] carrier. Then we’ll quickly talk about mobile education. Many of you, I’m sure, are already doing phishing training for your employees, but we’ll talk about how it becomes critical for you to also do mobile security awareness. Then as we go through this, as we go through the strategy, we talk about these different areas. Since we only have a short time, we’ll talk about some of the key areas. How do you define the right minimum OS and hardware versions? We’ll talk about mobile threat defenses, a new set of tools that will come out that will give you advanced mobile security above and beyond what the operating systems might have. That gets into application security, network security, device protection security as well. Then we’ll give you an example of how all this looks together. Now let’s look at this example. There are many out there. I just picked one that comes up a lot. This is a flashlight app in the Android marketplace. There’s examples of this all throughout both iOS and Android. This flashlight app is yearly updated. You could see here it’s a 4.6 rated, 200,000 reviews on this device. This is a flashlight app. We all know that all of our mobile devices today, any modern mobile device today, has a flash. It has a flash. You turn it on right inside the operating system. But this particular author has created some variety of lighting. It does SOS, it does music, it does all these different fancy things. But let’s look at what this particular application has access to after you install it. I’m going to read this for those of you that might not be able to see it: “Updates to flashlight may automatically add any additional capabilities within that list on the right.” Can any of you tell me why a flashlight app needs anything more than access to the flash? You could see here on the right, this app could … It doesn’t mean it’s turned on by default, but could, at anytime, ask for and turn on access to your phone, access to your file system, access to the WiFi, to your pictures, to your video. Most of our employees today will just install this because it’s got a high set of ratings, it’s downloaded by everybody out there. Think about this as you train your employees. Why does that app need that privilege? Is it actually coming from the real source as well? Does something need GPS access? Does something need access to each of these individual things? Now there’s nothing malicious about this particular app at this point in time. Google scanned it through their Play Protect, and this particular author hasn’t done anything malicious with it. But this is something that you have to start considering as you train your employees. They need to be aware. They need to think about what they’re installing on that device because it could, at some point in time, later have possible ramifications for your enterprise. Now we do a year-over-year comparison as we look at the different mobile operating systems. We’re in the process of doing the 2019 update, but here’s the current one. The 2019 update will come out later [in March]. But you need to start thinking about starting with a core-based operating system and a core set of hardware that meets a minimum bar. Think about the devices that you allow onto your network today. If it’s below 6.0 or, in its current monthly Android security patch, the January 2018 security patch actually has the Spectre and Meltdown fixes. You shouldn’t allow anything underneath 6.0 and at least this year’s January patch. You could see here on the right, there’s some additional recommendations on hardware as well. Mike will talk a little bit more about this in his section, but Google has taken their Pixel devices, added some additional capabilities above and beyond their common definition requirements, and added additional security. Samsung Knox has government-grade security, BlackBerry Android, and the Google Android Enterprise-recommended program is pushing the bar and adding additional hardware-based, software-based higher requirements to meet enterprise security standards. On iOS, [you want] 11.2 because that’s where their Specter and Meltdown fixes are. With the iPhone 5S, and you can see the iPad Air equivalents, that’s when they added their hardware-based security called the Secure Enclave, where they start storing keys into that, that helps with some of the kernel-mode protections as well. Then as you’re looking at Windows, like a Surface tablet, kind of bring-your-own-device, we’re recommending Windows 10 Fall Creators in the past, which is 1709, and obviously the current Windows updates as well. These are the devices that, at a minimum, should be your requirements for all BYOD and corporate-managed devices coming into your organization. After you set the baseline, what do we need to look at for possible higher sets of security practices above and beyond that? A few years ago, mobile threat defense (MTD) vendors came out with this additional layer of security. Your employees want to install an MTD agent onto the device, it will provide application layer of protection. What they’ve done is gone out and done static and dynamic analysis of the mobile applications, looked at those above and beyond, looked at when some authors are trying to update or make changes out-of-band through web service connections. They look to ensure to see if you’re on that right WiFi. Obviously, as attackers are trying to do Pineapple-based attacks or trying to spoof WiFi in your local coffee shop or your airport, there are certain indications that could possibly be detected. Then what happens if an application installs through a side-load and then tries to instantiate a VPN? Why does that application need it? That’s behavioral anomaly detection. This agent then communicates with the back-end cloud service and then you can manage it that way. This is great for bring-your-own-device scenarios, MTD or what they call standalone mode. This doesn’t prompt the user to say, “I have to accept this,” and then, like traditional EMM [enterprise mobility management], would require full control, full access so that you could delete data and everything else like that. MTD and standalone doesn’t prompt that user to do that. It’s giving them the power and the ability to secure their device, both from a personal side as well as from an enterprise side. Now once you do add from a managed perspective the full unified endpoint management [UEM] or EMM or MDM [multi-device management] solution to it, these controls are more around configuration, policy management, device management. MTD is the security solution. EMM, UEM, MDM is really more the management solution. But what the MTD vendors have done is, they’ve actually integrated with that. For your managed devices, you can install the MTD, integrate it with your back-end, and then once a threat is detected on the device, since you have that back channel, that integration, you could actually create a policy that says, “Oh, I see a malicious device,” or, “something’s going wrong on that.” “Someone’s trying to do a man-in-the-middle attack. Go ahead and force a VPN or require an uninstall of that application,” because you have that management channel. Now there are a lot of different things going on here. But in the beginning, it’s really important to make sure you set that minimum platform level that we discussed and start thinking about mobile threat defense as that agent. You deploy endpoints today and you’ll always deploy some kind of endpoint protection platform or an EDR or some kind of [anti-malware] on it. It’s starting to become to the same level on mobile devices needing to have this additional more advanced security practice. Just think about it. You’re using your mobile device first, 80% to 90% of the day. The hackers are also realizing that as well. There are some other capabilities for some organizations that we see: If you have line-of-business applications, actually adding mobile application security where you’re actually doing hardening or locking it down or scanning for certain types of APIs and secure coding practices inside the line-of-business applications. Then from a management perspective, bringing that UEM, EMM, MDM on there to give you that configuration, management and control aspect. But then in the end, that training, that education becomes so critical. People are aware of what they need to do for emails, but even email phishing goes through. But think about all the different things they do on their device today. That device has corporate data as well as personal data. As you reach out through the education programs inside your organizations, talk about it that way. You’re not only helping them to be more secure because their banking data is on there, you’re also helping them be more secure with the enterprise data that’s on those devices as well. The culmination of this Gartner security strategy that we built looks like this: These are some examples of how you can actually start. It goes back to that first part of the discussion that I was talking about. Depending upon the level of data that’s on that device, you may have more requirements. As we talk to clients all the time, everyone’s saying, “My CEO wants that latest and greatest device.” Well, it depends on what that CEO needs on that device, if he needs corporate-sensitive, very critical data, you can give him a table like this and say, “Fine. If you need that sensitive data, here’s the security requirement.” You’re not saying, no, he can’t have that greatest, latest, large screen, foldable screen phone that just came out, but you’re giving him some prescriptive guidance on what … If he just wants email, calendar, contacts, some low-sensitive data, you can look at the bottom line and get him quickly on board, giving access to his email, but still protecting your corporate resources. This menu that you build allows to handle BYOD to fully manage and everything in between. These are recommendations…You can change, obviously, the data classifications, but looking at the operating system separate from the EMM, are you possibly looking at containers? Do you need to have a container for separating the personal data from the corporate data? Device-level, app-level or container-level VPNs? Are you looking at mobile threat defense, looking at hardening those corporate applications? The other thing that quickly we touched on in a quick survey: Device authentication versus the corporate container authentication. I talked to a CSO recently, and his CIO took his corporate-owned iPad device home and registered his entire family’s fingerprints on that device. That iPad, in this particular case, became that family-use thing, but it had corporate data on it. This is not just an iPad thing, but anything that has biometrics — there’s no way to really detect that. Thinking about the personal side, device authentication should be different than having to get into the corporate container. That container application, having separate authentication methods so you can make sure that at least that device is not just getting unlocked [and offering] seamless access into your corporate information. Of course, encryption both at a device-level and a file-level. Then as you start getting into higher sensitive data and use cases, possibly even looking at doing full voice, LTE, SMS and data end-to-end encryption for your mobile strategy. With that, quickly just running through some of the different recommendations. We all need to start looking at the risk and the tactics that are being [used]. You have people that are looking at threats today for your endpoints and your servers. You need to start thinking about looking at the endpoints and the mobile devices in that same threat-hunting [effort]. Setting that minimum OS, and you could see here for BYOD, obviously you might not have full control of the EMM, but trying to verify what actually is installing. Google, Apple, Microsoft have done a good job about vetting the applications that go into their app stores, but the ones that are going into those third-party app stores where the process of vetting applications is not as good becomes important. Looking at mobile threat defenses solutions and then adaptive access-based state of control, so thinking about if that MTD detects that device as a high risk, removing it from having access to your cloud and your corporate information, through a manual process. Then, deliver training. Now the only quick change between that and corporate-managed is once you have the EMM on there, you could actually enforce which applications are being installed and from what sources. Then,, with the mobile threat defense looking at that integration between MTD and EMM it gives you complete control of the security and the management of that device. With that, I will pass it over to David Richardson. Lookout’s David Richardson, Senior Director, Product Management David Richardson: Thank you, Patrick. That was very informative. I’m going to follow up on some of those items and go a little bit deeper into a couple of specific threats. But first let me get started by just explaining a little bit of what’s changed in the landscape in the last couple of years that’s brought us to this point of post-perimeter security. Your data no longer resides within your four walls, within your own data center. Your data is in the cloud. It is no longer within your physical perimeter, but it’s also no longer within your digital perimeter of firewalls, secure web gateways, access gateways, things like that. This data is up there in the cloud and you fetch it directly from cloud service providers. Your users have gone mobile at the same time, and so these mobile devices can connect to any network and they can access that data that’s in the cloud from anywhere. Essentially, your corporate network is now the Starbucks WiFi, any hotel WiFi or home WiFi anywhere in the world. These are how your employees are getting work done. They’re connecting to these networks. Essentially, your perimeter has disappeared. All the controls that you previously built into your network, your VPN, your physical infrastructure, they no longer apply in this new world of mobile plus cloud-delivered software. In this new perimeter of this world, there’s a couple of things that you need to think about how to do differently. One, you can’t trust the devices accessing your data. Just because the device is able to enter in a username and password and get on your network or try to access the cloud service doesn’t mean that this device should be trustworthy. Furthermore, bad actors know that users are no longer being protected by your perimeter, so they know which devices to target. They know to target your mobile devices for a variety of reasons. To make things even more complicated, end users are increasingly demanding privacy, free from inspection of their content on their mobile devices. No matter how locked down a corporate device you issue to someone, every single mobile device is inherently a mix of personal and corporate. There are various percentages depending on how you lock it down, but if you think about it, your mobile device, even if it’s fully corporate device, it knows where you are 24/7. That’s personal data. Your camera roll is most likely a mix of personal data, photos of your family and work data, photos of sensitive whiteboards with IP information on them. These devices are inherently a blend of personal and corporate, and so your traditional security approaches don’t apply. In this new perimeter of this world, you need to do things a little bit differently. You need to move some of the critical perimeter security services that you used to rely on to the endpoint or to an identity and access management solution or to the cloud service providers directly. Your access to your data must be based on a continuous assessment of trust, from an assumption of zero trust. Just because a device has the right user name and password doesn’t mean that that’s a device that complies with your corporate policies and should be allowed to access that data. You need to basically assume that all devices should be untrusted by default until you confirm that that device is trustworthy. There are really three pillars to the way that we look at post-perimeter security, at least here at Lookout. In post-perimeter security, you may have also heard other terms like zero trust or BeyondCorp. These are all very similar concepts. Post-perimeter security is about enabling those types of architectures. Basically, there’s three main components that you need to think about here. There’s the endpoint itself, whether that’s a mobile endpoint or an IoT [internet of things] device or a traditional desktop endpoint. There are the cloud services that it accesses, and there is the identity solution that allows you to identify who is who. Those services all need to be in communication with each other through a system called continuous conditional access. They need to all be able to share data with one another about the current health status of this endpoint, this identity associated with accessing this data, and the data itself from the cloud service provider’s perspective. They need to be able to determine whether or not this endpoint with this identity should be able to access that cloud resource. The continuous part here is crucial. If something changes to the risk posture of this device or the identity or the resource that you’re trying to reach out to, you need to be able to cut off access in real time. You need to not just not allow the user to login the next time that they’re trying to access something from an insecure device. You need to actually cut them off in real time. Here at Lookout, we’re a mobile threat defense vendor, so we focus mostly on the mobile endpoints. I’m going to talk about the mobile endpoint for a second and some of the threats that we’re seeing there. First of all, why target mobile? Patrick covered a lot of this already, but if you think about it, if you could only have one device that belongs to someone, the mobile device would be the perfect device for you to have because it’s always connected to the internet. It’s got microphones, it’s got cameras, it’s got corporate data on it, it’s got your location, it’s got your passwords and your multifactor authentication token. If you could just compromise one device, this is the perfect one to do it. If you think about protecting my devices with multifactor authentication, this is the one device where someone is going to type in their user name, their password and their multifactor authentication token all from the same device. If you could just watch what was going on in that one device, you would have all the keys that you need to compromise that user and access any data that they have access to. At Lookout, we were thinking about, as you enable more productivity for mobile devices, what are the risks that you need to be aware of, so we created something called the mobile risk matrix. I’m not going to walk through this square by square here, but at a high level, you need to think about the four various vectors, the apps that are on those devices, the device itself, the OS version, the way it’s configured, the hardware manufacturer, et cetera, the security pass level, the networks that that device connects to, whether that’d be WiFi, cellular, VPN, NAT or proxy, et cetera, and the web and content that device consumes. Then across each of these vectors, we need to be worried about three different components of risk. We need to be worried about threats. Obviously, we need to be worried about malware or rooted and jailbroken devices, man-in-the-middle attacks, phishing sites, et cetera. But you also need to be worried about software vulnerabilities that are introduced by out-of-date applications, out-of-date operating systems, vulnerable SDKs, things like that. You need to be worried about the behavior and configuration of each of these things and how they relate to your corporate policies. Here you see apps that are collecting way too much data, that flashlight app that is harvesting all this data from your device potentially, or one that’s over-permissioned that you need to worry about there, or devices that are configured in an insecure manner such as the sharing of passcodes or having no passcode, or allowing installation from third-party app stores. I wanted to dive into just a couple of threat examples in a few of those boxes there and cover some interesting trends that we’re seeing. One trend that we’re seeing is, we’re actually seeing phishing sites that are exclusively targeting mobile, that are built to target mobile. Here is an example of the WhatsApp campaign that we’ve seen spreading around. This is just one variant of it. But basically your WhatsApp account … someone in your address book will get compromised and they would send you this message that would come from a trusted source. You would know the sender. It would look like a pretty compelling, normal link. If you click on that link on a mobile device, you would get a phishing page. If you would click on that link on a non-mobile device, you would actually get the real website that it was trying to point you to. This is a case where the attacker has actually decided, “I want to only target the mobile users.” This technique actually allows these types of sites to go undetected for longer because many of the tools that are trying to detect phishing sites are being fooled by this simple thing of redirecting them to the real site in that case. Here if you just look very closely, you might have noticed it, but there’s a tiny dot underneath this ‘A’. That is called a homoglyph attack where basically it looks the same to the naked eye as the real URL, but to a computer, that’s a completely different unicode character, and [the URL] sends you to a completely different server. We’ve seen a lot of attacks like that coming up. We’ve also seen a lot of mobile malware-as-a-service campaigns, so attacks where you can actually essentially just buy malware that will target a specific account type. That malware will be high-quality and it will be branded to look exactly like the real thing. This threat, BancaMarStealer, the way that it works is it looks at what app is running in the foreground on your device and it presents a popup on top of that application when the target app is running. You open your Capital One app and suddenly a second app creates a popup on top of it that looks exactly like a Capital One login page. Users are easily tricked by that to type in their username and password. They click ‘Sign In’ and they go back into the Capital One app like where they were, before not realizing that they were just phished in that process. Then another interesting trend is proxy malware that we’re seeing. We’re seeing malware that will actually open up SOCKS proxies on devices that get infected and allow attackers to have access to any of the networks that that device can connect to. You might have someone who downloads malware at home in their free time and then they go and they connect their device to a work network. Now the owner of this proxy malware will sell to the highest bidder access into that corporate network and access into that device that’s associated with that corporate network. I just want to leave you with two thoughts here again about what you need to do as a result of this. You need to think about your long-term strategy as it relates to the perimeter around your data crumbling, and figure out where you need to move these critical perimeter services. Our recommendation is that a lot of these need to move to the endpoint, but there are other places that they can move to, such as the identity and access management solution and the cloud provider as well. A combination of those is the best approach. You need to stop assuming that you should trust your devices by default. With that, I’m going to hand things off to my colleague Mike here. Google’s Mike Burr, Platform Specialist, Android Enterprise Mike Burr: Great. Thanks, David and Patrick. Let’s see here. Pop this in. All right. Well, thanks again, everyone, for allowing me the opportunity to join today. I think to set the stage, I want to talk first about a couple of things. Then we’ll jump into some of what I see and what we see here at Google, particularly on the Android team, what we see as far as what we call misperceptions. Then also one of the bigger things is around, how do we manage Android devices efficiently. One of the first things that we like to talk about is obviously that there are a lot of Android devices on the planet. On a rolling 30-day schedule, we see roughly 2.3 billion Android devices checking into Google Play services. Those are obviously devices that have Google services. There could be more. The other part of the ecosystem is [IoT] — most people think that Android is just for smartphones and potentially tablets. But I think what we’re seeing over the last few years, due to some things like Windows Mobile going out of favor and being deprecated by Microsoft, is that Android’s actually landing on a lot of other pieces of hardware. There are a ton of these devices out there. The good news is that we have a way to manage these. We’ve removed that management fragmentation and done a lot of things over the past several years to help secure those devices and deploy them and manage them in a very secure way. One of the areas that I like to get into in the beginning [of these discussions] is what we call misperceptions. Really it all started when, a couple of years back, I think people just stopped looking at Android as a viable enterprise platform for various reasons. However, over the last couple of years, we’ve done a lot in the ecosystem and in asking our ecosystem partners to make these things — these Android devices and the platform and everything that runs on them — secure. I think one of the couple of areas [where there are misconceptions] is the idea that the updates are slow. That’s a misperception in the modern Android world. People also think and customers also think that a vulnerability equals an exploit. That is not true. A vulnerability is a chance and an exploit is writing code and getting it onto a device to exploit that chance. I think there’s a big delineation there to make — understanding that just because there’s a chance doesn’t mean anything is going to happen. In fact, history shows us that in those things with the major issues, things really never come to fruition as far as the vulnerability being exploited en masse in the wild. The second piece is around harmful apps (here at Google we call those potentially harmful apps), and the perception that Google Play is full of malware. We’ve actually done a very good job, and the ecosystem helps us with that as well. We’ll jump into a few things here to move forward. As far as Android patching goes, this is pretty impressive. I think this is a good key indicator that the devices are getting patched very regularly. We introduced something called Project Treble a year or two ago, which actually helps the ecosystem software and chip manufacturers, OEMs and carriers get updates out faster. It injects a harder extraction layer that makes developing these updates much faster. In 2018, we actually saw just over a billion devices getting regular updates, and I mean within 90 days of Google releasing those 30-day patches. That totaled 84 percent of devices at the end of last year. Quarter-over-quarter, we’re getting updates more regularly than a year ago. We are seeing this trend change, primarily because we’re driving the ecosystem, mainly OEMs and carriers, to accept those security updates and we’re making it easier for them to do so. Again, back to the story of where vulnerability doesn’t necessarily mean an exploit. I’m not saying that they’re not there. However, the various of layers of the Android operating system, including the hardware, actually made a lot of, or introduced a lot of, technical best practices in the operating system and the platform that mitigate (even when an exploit does get onto a device), what it can actually get to. In fact, if you really think about the whole broad picture of Android security, the concept now is that getting a true piece of malware on a managed Android device is pretty rare. Then if it does get on there, does it really get to your credit-card data? Does it really get to critical information or maybe it gets your contacts? Again, the risk posture there depends on what vertical you’re in and what kind of things you’re doing, but the idea here is that we have so many techniques outside the scope of this discussion that you can actually see used in modern Android. It all starts with secure hardware. Some of the things that you’re seeing on this screen, I won’t go through them in great detail. However, some of the things we’ve asked and actually mandated that the OEM and carrier ecosystem do, is start building secure hardware into the devices. In fact, in Oreo, it is mandated that devices come out of the box with a secure hardware component. Even if the device is compromised, you can still very strongly attest that the integrity of the device is preserved. With these particular components here, again this helps with deploying devices in enterprise because all of these things help you prevent allowing bad actors and even malware from taking data off of a device. Finally, on the PHA side, we at Google call PHAs “potentially harmful applications,” but it’s really important to understand that a PHA does not in any way, shape or form equal malware. It does not equal trojan. There’s all kinds of things that can get on a device. As my colleagues mentioned, screen overlays, which you can now control with modern management capabilities, are just one way. That’s categorized as click-fraud or screen-capturing or clickbait. [The percentage of] real malware on Google Play is pretty small. In fact, the whole PHA category, at the end of last year, was down to 0.042 percent, which is actually pretty darn good. You can see the blue line at the top there is going down on devices that are loading applications outside of Google Play, i.e., sideloading. One of the reasons for that is just because we’ve strengthened the operating system so that exploits are much harder to actually enable. Now some of the other pieces … and this is the big part because we’re here in an enterprise stance and an enterprise discussion. One of the biggest things we see is that many customers are still managing Android devices with legacy methods. A device administrator is just not the way to manage Android any longer. We want customers to start using modern Android under the Android Enterprise components. When you’re using legacy management, you can see here on the screen there’s a lot of problems that come out as far as being able to manage that device. With the new modern management, you have tons of knobs and levers that can actually help you mitigate that. What at Google do we think the best practices are to help you safeguard Android devices? No. 1 thing is awareness. You’ve heard it from my colleagues and my friends here on the call. You’ve got to educate your users because no matter how good you think you are, they, “they” being the bad actors, will always find a way to try and trick people. Social engineering and phishing is the No. 1 way, so you need to educate your users. The other way is to start adopting modern Android management. Now one of the ways to do that, obviously from a Google perspective, is to use devices and services that are on the Android Enterprise-recommended sites. Patrick mentioned that earlier. That’s a good way to understand and know that you’re getting devices that have a long runway, so you can select with confidence that these devices will give you consistent deployment and they will get regular updates, and that is under contract by these devices. Then your EMM partners and your managed solutions providers also recommend it. When you combine all that together and then you look at our partners in the ecosystem like Lookout and some of the other security vendors out there, when you couple all that together and use those protections and use those tools, Android can be managed in a very, very secure method. One of the other things that I mentioned earlier was using modern Android management, and that comes with the guise of Android Enterprise. Patrick mentioned it earlier, it’s going away from containers to potentially start to look at what we call profiles, that are based on Linux profiles on these devices. Using these modern management tools, you can actually mitigate a lot of the attack vectors that are posed by these type of attacks just because you have the tools to actually control the ways that they get on a device. One of the best ways is to use a strong Play store strategy. I think my colleagues will agree that installing your apps through managed Google Play and not sideloading and not using third-party app stores is the actual best way to do it. When you used managed Google Play, you get all kinds of benefits. You can’t have apps that get on that device outside of management. There’s no option for a user to sideload an app in any way, shape or form. By controlling that and then the layering on of some threat detection, you actually can control what gets on the device and what goes off the device as far as data. You can do that with third-party components. But the idea here is use modern management and move away from Device Administrator, because that’s too open. That’s this statement that I want to make here, is Device Admin has been deprecated or I should say has started being deprecated way back in Nougat, two years back, around December of 2017. All Device Administrator APIs have been marked as deprecated in Pie. Now that does close up a lot of attack vectors based on APIs and things of that nature. Basically, by the time Q rolls out, whichever dessert name that’s going to be, device administrator APIs will be no more. It behooves you to start migrating your apps over and managing them with Android Enterprise components of modern Android. Then, finally, I think one of the greatest things about Android is that we have what we call an ecosystem of just really phenomenal security defenders. My colleagues here on the phone, Patrick for education and David for the products that they build, combine that with all the entities that you see here. Many people say that Android is open, that’s bad. We don’t see it that way. Because it’s open, you have choice. It’s not fragmented anymore. Because we have all these different entities that are banging away to make Android secure, I’d argue it’s one of the securest. Of course, with that said, I think it’s good to note that we have a good system, we have a good ecosystem and many partners that actually make the system that much better. With that, I’ll go ahead and pass the ball back over to Tara to close up. Maybe we’ll do some Q&A. Q&A Tara Seals: Great. Thank you so much, Mike. Yeah, I know we got started a little bit on the later side, but I think we do have time for a few questions. Let’s kick it off. I think you guys all gave us a lot to think about. Let’s look towards the future a little bit with an eye towards the past. If we look at the most significant ways that enterprise mobile security has changed in the past five years, I’m curious as to what you guys say that those would be. Then also, do you feel as though there have been any surprising developments within that time frame and what does that hold for the future? Patrick, maybe if you want to start us off with your thoughts on that? Patrick Hevesi: Yeah, I mean definitely, as I was saying earlier, the mobile device is your primary device. We really need to start looking at it as a full-fledged endpoint. That’s where some of the endpoint-protection platforms have been integrating with mobile threat defense vendors and giving you a holistic look across all devices, be it a laptop, a Chromebook, an iPad, a Surface, an iOS device, an Android device, and start thinking about if something is compromised, if your phone gets compromised, what’s next? What is the hacker going to then possibly do, thinking about what cloud applications you might be accessing as well? I think that’s probably the biggest thing we’re seeing, and IT organizations are starting to staff that up as well, bringing that mobile security discipline integrated with their traditional endpoint-protection capabilities. Tara Seals: Great. Thanks. David or Mike, would either one of you like to weigh in on that? Mike Burr: Sure. I’ll add a little bit there. I think one of the surprising things that I’ve seen is just what’s forcing adoption of enterprise mobile security. One of the main things that we see is that it’s actually geared around a project around enabling mobility usually. For example, an organization is rolling out, say, G Suite or Office 365 to all of their devices, and they’re realizing that in that process, they’re opening up their mobile devices to access more data than they did before. It’s interesting to see how actually enabling mobility is one of the significant drivers for when organizations decide we need to have a more comprehensive mobile security strategy as a result. Tara Seals: Got it. Okay, great. David, we actually have another question for you from the audience. Allison would like to know if you could expand a little bit on the concept of secure SMS and how it works or would work. David Richardson: Secure SMS. Obviously, the current ways that SMS are delivered are they weren’t built with security in mind. It was a way to broadcast messages out quite broadly and without necessarily encryption or some of those other things together. Obviously, there’s a bunch of user experience issues with SMS as well, like character limits and read receipts and those types of things that many different players have been trying to expand upon that. David Richardson: I think SMS as a whole in its current form will shrink in terms of usage. Obviously, it’s already being replaced by whether it’s WhatsApp or Google Hangouts or iMessage or other methods like that. As far as the idea of secure SMS, I think that there’s obviously a lot of trends. I’m assuming secure SMS would be encrypted SMS messages, end-to-end encrypted SMS messages. Obviously, there’s a lot of debate about this at the moment in terms of what should and shouldn’t be done from an encryption perspective. I obviously don’t want to talk too much about that, but it is interesting how there’s been a whole bunch of tools that have sprung up lately that are enabling end users to form their own fully end-to-end encrypted conversations, which has obviously lots of applications for political purposes as well as insider trading and other things like that. I think that’s going to be a really difficult topic that we’re going to have to wrestle through in the next couple of years here. Tara Seals: Absolutely. Okay. We have another question from the audience that’s about basically denial of service. They’re asking, for very critical applications, should enterprises be concerned about deliberate jamming, and not just spoofing and sniffing? David Richardson: Yeah. I think yes. Obviously, as you enable users to do more from mobility, it may become a critical part of your workflow, as critical as cloud services being operational, that your mobile applications are operational and that people are able to get work done as a result of that. Tara Seals: Okay. Then we have a question for Mike. If someone is using Android Enterprise and they are using it in device-owner mode and everything’s been restricted to Google Play, they’re wondering if there is a need or a benefit to layering on third-party security solutions in that scenario? Mike Burr: Again, that always comes down to the risk posture and what’s your risk appetite and your mean time for failure is. I think that’s an individual decision. We at Google will never say not to use it. There’s obviously lots of things in the platform that protect the device, but that’s what it does: It protects the device. While things can still get on to devices, depending on your use case and depending on what the device is being used for, how many applications are on it, is it special purpose, is it shared, you have to take into consideration this full picture. One would argue if it’s fully managed and it’s in kiosk mode and there’s no way to get apps on there, do you need some sort of external or some other service? Maybe, maybe not, because you might want to protect the data that’s going to it. I think at Google, we look at it from a perspective of trying to keep exploits in any way, shape or form off a device, but we’re not protecting the networks per se other than guaranteeing that we’re using the proper certificates and modern TLS or more advanced TLS connections. Again, it boils down to the use case and what your risk posture is. Tara Seals: Okay, great. Patrick, another question that we had is, if you’re an end user, an employee, what part does end-user awareness play on this? For instance, is using my phone as a second factor of authentication a safe practice? What about using VPN while I’m on public WiFi? Does that protect me from some of those threats? What are your thoughts on that? Patrick Hevesi: Right. I mean definitely we’re going to see a lot of the cloud-service providers recommending multifactor authentication. The challenge with … using your device as a second factor is, are there any risky applications on there? Have I actually done that self-awareness? Am I actually policing my own device and putting only safe applications on there? MTD and standalone could help with that. The other thing we see is for government high-risk devices, some of the threat issues we look at are, has someone cloned my phone as well? If you’re starting to look at your bill and all of a sudden you see a whole bunch of different phone calls or things like that that might be happening, that could indicate someone might have done that. But that’s a very targeted, very personal attack. It gets back to [the fact that] you have to understand the health of your device to be okay for it to be used as a second factor of authentication. The second part of that question was about mobile VPN. Definitely, it’s going to help. If you are on a Starbucks WiFi or the airport WiFi or whatever, having that VPN will definitely secure the traffic. A lot of security-minded professionals are paying for always-on VPN. They have that additional layer of protection, so even if someone is trying to do a man-in-the-middle attack at some kind of coffee shop, that you’ll at least have that encryption. That also gets back to the corporation. If you have highly sensitive data on that device, possibly instantiating that VPN on that managed device is definitely a good best practice for protecting the network stack. Tara Seals: Got it. David Richardson: I want to add one thing at the end there. I agree with what Patrick is saying, but one thing that I want to caution is be careful about what VPN you’re using. There are a lot of free VPNs out there. If it’s a free VPN, [you must realize that] it is impossible for someone to pay for the cost to run a free VPN without somehow monetizing your data. We’re seeing VPNs get built into applications such as the Dolphin browser. These types of things create risks associated with the device as well. They’re also an avenue for man-in-the-middle attacks. We’ve actually seen VPNs that are better than free, where they pay users. There was a high-profile example recently of Facebook offering to pay I think it was teenagers $20 a month if they would turn on an always-on VPN so that Facebook could watch all their traffic. But we’ve seen that as a trend for a long time, and that is actually a source of man-in-the-middle, a source of enterprise data accidentally flowing through a third-party advertiser in a way that it really should not. Mike Burr: Yeah, Tara, real quick. I’d like to add one more thing to this. We at Google actually take another approach that seems to work extremely well. It’s not only about authenticating who you are and protecting that authentication with two-factor, but it’s also about trust level. There are all kinds of signals that come from your device, so when you make a connection to a resource, there are services … not necessarily network access control, but trust models. At Google, we call it BeyondCorp. Looking at signals about the device, where you are, the type of certifications. Do you have a machine cert or do you have a user cert? All these different various signals from a device will give you a trust level. Then that will only allow access to certain resources in your network. David Richardson: Yeah, absolutely agree there. Patrick Hevesi: Yeah, agreed. Tara Seals: Great. Okay, guys. Well, I want to wrap it up. We did have one more question from the audience though that I think is probably worth asking. This person would like to know, in terms of advanced persistent threat activity, nation-state activity, corporate espionage, that type of thing, how common is that? How much should enterprises have to worry about that type of activity? Mike Burr: Tara, I can speak from the Android perspective. I don’t have specific data. I’ll say it happens. I would say that, again going back to my part of the presentation, what we’ve done in the ecosystem is actually made it much more difficult even for OEMs and carriers to inject malware or bad pieces of data into the system partition. Some of the things that we look at when we certify a device are things like that. Then putting things into the platform itself actually will mitigate that attack. Then with remote out-of-station services, things like verified boot, we can very strongly attest that the system partition will be intact. When the device is under a management, there’s all kinds of signals that we can look at that are based on hashing and remote out-of-station that can strongly, strongly attest that a system partition truly has not been compromised. I won’t say it hasn’t been tried, I’m sure it has, but from my perspective I don’t see it, but that’s not to say that it doesn’t happen. Tara Seals: David, did you have any further thoughts on that? David Richardson: Yeah. Just a couple of thoughts on that. One, I’ll agree with what Mike’s saying about … especially what he was saying earlier about how the vulnerability is not an exploit. These nation-state attacks, the ones that we have seen, they are rare and they’re newsworthy when they happen. They involve chaining multiple exploits together. I’ll use the Pegasus example that Patrick mentioned earlier. This involves a Safari WebKit exploit on a webpage and then chaining two different kernel exploits in order for you to essentially jailbreak this device and install hooks on it in order to get persistent access to this device. [But] there are a lot of strong controls, isolation and sandboxing on both iOS and Android to ensure that just because you’ve exploited one vulnerability doesn’t mean you’re going to be able to get full access to the device. You need to chain a number of very expensive vulnerabilities together in order to pull that off. This does happen. We see it actually. We see it in our user base occasionally. It is not something that happens to every enterprise. It’s definitely on the rare side. What we see more often is more like the broad-based attacks … like the proxy malware I was talking about, where someone will try to target as many users as possible to get them to do something that they should know better not to do, like install an app from a third-party source or install a configuration profile or something like that. Then try to figure out, okay, what information can I glean from these users? What corporate data can I exfiltrate, et cetera? We see more of those types of attacks happening. Tara Seals: Really interesting stuff. Thank you, David Richardson. Thank you, Mike Burr. Thank you, Patrick Hevesi. We are going to have to leave it there since we’ve got a little bit of a late start. Thank you so much for participating. Patrick Hevesi: Happy to. Thank you. David Richardson: Thanks for the opportunity. Mike Burr: Thank you. Absolutely. Thanks again.
An ongoing three-year-old phishing campaign has been targeting the credentials of Saudi Arabian government agencies — with a financially motivated actor the likely culprit. The campaign, code-named “Bad Tidings,” has siphoned victims’ credentials by pretending to be the Kingdom’s Ministry of Interior’s e-Service portal, known as “Absher.” The recent emails have targeted four government entities: the Ministry of Interior, Saudi Government, Ministry of Foreign Affairs and the Ministry of Labor and Social Development – as well as the Saudi British Bank. While the campaign has been ongoing since November 2016, researchers with Anomali said that in the past few months, the number of phishing landing pages has suddenly spiked. “Anomali and [Saudi Telecom Company] believe the Bad Tidings campaign’s heavy focus on the Kingdom of Saudi Arabia (KSA)’s government agencies electronic services is reflective of information-gathering operations employed by a financially-motivated actor or group attempting to steal and monetize personally identifiable information (PII) and other sensitive data,” researchers said in a Tuesday post. Fake Landing Page Since it first started in 2016, the campaign has used a total of 95 unique phishing host names to target its victims. These were created as part of the campaign to impersonate the aforementioned Absher, which represents close to 60 percent of the Saudi-related phishing sites. The e-Service portal helps users with employment, passports, civil affairs, traffic services and more. The phishing landing pages in the campaign would typically contain two web pages: A fake homepage, and a login page. The fake login pages appear to display the legitimate account access portal for Absher – however, when users provide their user ID and password, they are redirected to the initial phishing landing page without logging into the intended resource. “Typically, at this stage the phishers have stolen the user’s credentials and are likely to sell them on underground markets or use them to impersonate the victim to commit fraudulent actions,” researchers said. Tricks and Tactics The attackers have used multiple spoofing techniques to disguise the fraudulent sites, researchers said. “We have observed the attackers creating sites using either a single or combined technique of punycode-based spoofing attacks, typosquatting or sub-domain spoofing attacks,” researchers said. Researchers said that to trick users, the websites that were created were using slightly misspelled domain names (a technique called “typosquatting,” which registers domains that can be confused for the legitimate site or brand name by incorporating hard-to-spot spelling or grammatical errors); subdomain spoofing, using alternative top level domains (TLDs) (i.e., near-identical URL names that use something other than the legitimate gov.sa suffix), or punycode-based sites to masquerade as the real portal. Punycode is a method of representing International Domain Names in local language characters, which are normally limited by letters or hyphens when supported by DNS. “For example, the Absher portal is a web page located underneath the website https://www.moi.gov.sa/; however, malicious actors have appropriated the brand name ‘Absher’ to create typosquatting domains with misspellings and wrong TLDs e.g. abshr[.]xyz or simply wrong TLDs e.g. absher[.]space,” said researchers. Moving forward, researchers said they expect the campaign to continue targeting Saudi government e-services using phishing attacks, either via email or text message. “Online government portals offering citizen services remain attractive targets, as they store vast amounts of personal and sensitive information in a centralized location and if compromised, can provide malicious actors with enough data for resale on underground markets or to commit fraudulent actions such as identity theft,” the researchers said.
A rogue developer at rideshare behemoth Uber created and deployed spyware in order to help his company get a leg up on the local competition in Australia, according to a report. The “secret spyware program” was dubbed Surfcam, and was developed in-house in 2015, according to an unnamed source who said he or she was a former senior Uber employee. The person told the Australian Broadcasting Corp.’s Four Corners team that the purpose of the malware was to allow Uber drivers to poach drivers from a ride-share competitor called GoCatch. GoCatch launched as a homegrown start-up in 2012, with backers that included international hedge-fund manager Alex Turnbull. “Surfcam when used in Australia was able to put fledgling Australian competitors onto the ropes,” the former employee said in the report. “Surfcam allowed Uber Australia to see in real time all of the competitor cars online and to scrape data, such as the driver’s name, car registration and so on.” The source alleged that Uber used the intel to give competitive employment offers to GoCatch drivers to lure them away from working for the startup. “GoCatch would lose customers due to poaching of its drivers, draining their supply. With fewer and fewer drivers, [the idea was that] GoCatch would eventually fold,” the purported former Uber employee said. GoCatch in fact did not go out of business, but “the fact that Uber used hacking technologies to steal our data and our drivers is appalling,” GoCatch’s co-founder and chief executive, Andrew Campbell, told the outlet. “It had a massive impact on our business.” This isn’t the first time that Uber and Surfcam have been in the headlines; in 2017, Bloomberg reported that the espionage tool was deployed in Singapore, against Grab, the local ride-share competitor there. “Surfcam, which hasn’t been previously reported, was named after the popular webcams in Australia and elsewhere that are pointed at beaches to help surfers monitor swells and identify the best times to ride them,” Bloomberg said in that report. Until the ABC report, it was thought that the effort to undermine Grab — which became more popular in the city-state than its multinational rival and last year bought Uber’s assets in the region — was Surfcam’s only outing. Threatpost reached out to Uber and will update this post with any reaction or comment. Rogue Developer Interestingly, the source said that Uber’s management back in California was unaware that the software had been developed or used. ABC’s source said that a developer in the Sydney office took it upon himself to modify off-the-shelf spyware (no word on which one) for Uber-specific purposes. That same developer then moved to Southeast Asia, where he apparently brought Surfcam with him in order to put the squeeze on Grab in Singapore. Once Uber found out about Surfcam’s existence, its use was prohibited, according to the source. An Uber Australia spokeswoman confirmed that narrative in a statement, ABC said. Bloomberg meanwhile said in the 2017 report that the employee eventually moved to Uber’s European headquarters in Amsterdam and is still employed by the company. Uber’s alleged use of Surfcam happened at a time when the company was fighting several legal battles and had landed in privacy turmoil more than once. In 2017 for instance, it agreed to 20 years of privacy audits as part of a settlement with the FTC over its “God View” function, which allowed the company to monitor and log the real-time locations of customers and drivers without their consent. Don’t miss our free live Threatpost webinar, “Exploring the Top 15 Most Common Vulnerabilities with HackerOne and GitHub,” TODAY, Wed., Mar 20, at 2:00 p.m. ET. Vulnerability experts Michiel Prins, co-founder of webinar sponsor HackerOne, and Greg Ose, GitHub’s application security engineering manager, will join Threatpost editor Tom Spring to discuss what vulnerability types are most common in today’s software, and what kind of impact they would have on organizations if exploited.
The popular SSH client program PuTTY has released the latest version of its software that includes security patches for 8 high-severity security vulnerabilities. PuTTY is one of the most popular and widely used open-source client-side programs that allows users to remotely access computers over SSH, Telnet, and Rlogin network protocols. Almost 20 months after releasing the last version of its software, the developers of PuTTY earlier this week released the latest version 0.71 for Windows and Unix operating systems. According to an advisory available on its website, all previous versions of the PuTTY software have been found vulnerable to multiple security vulnerabilities that could allow a malicious server or a compromised server to hijack client’s system in different ways. Here below I have listed all 8 vulnerabilities with brief information that PuTTY 0.71 has patched: 1) Authentication Prompt Spoofing — Since PuTTY doesn’t have a way to indicate whether a piece of terminal output is genuine, the user-interface issue could be exploited by a malicious server to generate a fake authentication prompt at the client side, prompting victims to enter their private key passphrases. “If the server had also acquired a copy of your encrypted key file (which, for example, you might have considered safe to copy around because it was securely encrypted), then this would give it access to your private key,” the advisory explains. 2) Code Execution via CHM Hijacking — When a user launches the online help within the PuTTY GUI tools, the software tries to locate its help file alongside its own executable. This behavior could allow an attacker to trick the user into executing malicious code on the client system via the hijacking CHM file. “If you were running PuTTY from a directory that unrelated code could arrange to drop files into, this means that if somebody contrived to get a file called putty.chm into that directory, then PuTTY would believe it was the real help file, and feed it to htmlhelp.exe.” 3) Buffer Overflow in Unix PuTTY Tools — According to the advisory, if a server opens too many port forwardings, PuTTY for Unix does not bounds-check the input file descriptor it collects while monitoring the collections of active Unix file descriptors for activity, leading to a buffer overflow issue. “We don’t know if this was remotely exploitable, but it could at least be remotely triggered by a malicious SSH server, if you enabled any of the options that allow the server to open a channel: remote-to-local port forwarding, agent forwarding or X11 forwarding,” the advisory says. 4) Reusing Cryptographic Random Numbers — This issue resides in the way cryptographic random number generator in PuTTY, occasionally using the same batch of random bytes twice. “This occurred because of a one-byte buffer overflow in the random pool code. If entropy from an external source was injected into the random pool exactly when the current-position index was pointing at the very end of the pool, it would overrun the pool buffer by one byte and overwrite the low byte of the position index itself.” 5) Integer Overflow Flaw — All prior versions of PuTTY suffers an Integer overflow issue due to missing key-size check-in RSA key exchange. A remote server can trigger the vulnerability by sending a short RSA key, leading to an integer overflow and uncontrolled overwriting of memory. PuTTY developers are not sure if this flaw can be exploited to gain control over the client, but since the issue occurs during key exchange and happens before host key checking, the overflow can be induced by a MitM attack even if the middle man does not know the correct host key. So even if you trust the server you think you are connecting to, you are not safe.” 6, 7 and 8) Terminal DoS Attacks — Last three vulnerabilities in PuTTY allows a server to crash, or slow down client’s terminal by sending different text outputs. Servers can send a long unbroken string of Unicode characters to the client’s terminal, which could lead to a denial-of-service attack by causing the system to allocate potentially unlimited amounts of memory. The second DoS attack can be triggered by sending combining characters, double-width text, an odd number of terminal columns, and GTK to the client’s terminal in output. In the third DoS attack, by sending width-2 characters used by Chinese, Japanese and Korean to the client, PuTTY’s terminal emulator can be forced to crash. If you use PuTTY, make sure you download and use the latest version of it.
Google announced some major changes for its Android mobile operating system in October after the European Commission hit the company with a record $5 billion antitrust fine for pre-installing its own apps and services on third-party Android phones. The European Commission accused Google of forcing Android phone manufacturers to “illegally” tie its proprietary apps and services—specifically, Chrome and Google Search as the default browsers—to Android, unfairly blocking competitors from reaching consumers. This rule led Google to change the way it licenses the Google mobile application suite to Android smartphone makers. Now, Google is further making some changes related to browser and search engine choice. In a blog post published Tuesday, Google announced that the company would prompt Android phone owners in Europe (new and existing ones) in the coming months to choose from a variety of web browsers and search engines for their devices as their default apps. “Now we will also do more to ensure that Android phone owners know about the wide choice of browsers and search engines available to download to their phones,” the company says. “This will involve asking users of existing and new Android devices in Europe which browser and search apps they would like to use.” Although Google did not specify, the prompt will likely appear during the phone setup phase. The move comes a few months after Google revealed its new paid licensing agreements for Google apps on third-party Android smartphones. The new licensing scheme applied only to Android devices in the European Economic Area (comprises the 28 EU countries along with Iceland, Liechtenstein, and Norway) and required phone makers to obtain separate, paid licenses if they want to include: Play Store, Maps, Gmail, and YouTube without Chrome, and Search Everything, including Chrome, and Search This change allowed smartphone makers in Europe to install any app they want to serve as alternatives to Google apps without being forced to bundle Google Search and Chrome. Google also said Android users have always been free to download any browser and search engine apps they want, “irrespective of what came pre-installed on the phone,” noting that “a typical Android phone user will usually install around 50 additional apps on their phone.” The company has likely come up with these latest changes to show the European Union its “continued commitment to operating in an open and principled way.” Not just for Google’s mobile operating system, but the European Union also fined Google $2.7 billion in June 2017 over abusing the way it prioritizes its own shopping results at the top of its search results at the expense of its rival products. In the latest blog post, the tech giant also announced some changes to Google Shopping, which includes providing “direct links to comparison shopping sites, alongside specific product offers from merchants.”
By Waqas The IT security researchers at Palo Alto Networks’ Unit 42 have discovered a malware that has been targeting Israeli cyberspace especially those dealing with technology and financial sector. Dubbed Cardinal RAT (remote access Trojan) by researchers; the malware is currently targeting two Israeli fintech companies developing forex and cryptocurrency trading related software. The malware has been around since April 2017 […] This is a post from HackRead.com Read the original post: Israeli fintech firms hit by Cardinal RAT malware
Our Standard Office Hours
Monday – Friday: 8:00AM – 5:00PM EDT
Saturday – Sunday: Closed
Where to Find Us
Data Privacy Notice
- – All product names, logos, and brands are property of their respective owners.
- – The use of these names, logos, and brands is for identification purposes only and does not imply endorsement.
- – Content syndication and aggregation of public information is solely for the purpose of identifying information security trends, all syndicated content contains source links to the content creator website. All content is owned by it’s respective content creators.
- – If you are an owner of some content and want it to be removed, please email firstname.lastname@example.org