Category: Security Recommendations

  • Keep Your Cookies in the Cookie Jar: HttpOnly and Secure Flags

    What are cookies, anyway?

    Cookies are a way to store information across multiple HTTP requests. HTTP is a stateless protocol, meaning each request is completely independent of subsequent requests. Cookies are set by the web server, and then stored in the user’s web browser. Each subsequent request to the domain specified in the cookie will then include the set cookies in the HTTP request headers, so the web server can continue to associate the following requests to that user. Some common use cases for cookies are authentication, analytics IDs, and user preferences.cook

    So, what are cookie flags, then?

    Cookie flags are attributes for a cookie that are set when the cookie is initialized. These attributes live for the duration of the cookie’s lifespan, so it’s important that they are set with secure attributes, especially for important cookies used for maintaining sessions or other sensitive user information. These attributes can quickly be seen by looking at a cookie in the browser, as shown below:

    Example of cookies set with Secure and HttpOnly flags
    HttpOnly Flag

    The HttpOnly flag prevents a cookie from being accessed from protocols other than HTTP. This flag is mostly used so that client-side JavaScript cannot access the cookie.

    Security Impact

    When the HttpOnly flag is not set, client-side JavaScript is able to access and use the cookie. From an attacker’s perspective, it means the cookie is vulnerable to being stolen or used during other client-side attacks, such as in a Cross-Site Scripting (XSS) attack. For example, in our recently discovered XSS Vulnerability in ManageEngine Applications Manager (CVE-2021-31813), cookies were accessed through the inserted JavaScript and reflected back to the screen, as shown below:

    Cookie accessed by inserted JavaScript in XSS vulnerability (CVE-2021-31813)

    In a real scenario, an attacker may send the cookie to themselves instead of reflecting it to the screen. However, if the HttpOnly flags had been set, the malicious JavaScript could not have accessed the application’s cookies in the first place.

    Secure Flag

    The Secure flag prevents a cookie from being sent over HTTP and enforces the cookie to only be sent over HTTPS. This flag is used to prevent attackers from stealing cookies by sniffing unencrypted HTTP traffic. Even though there is a high usage of HTTPS, cookies can still be sniffed on redirects and through other means without the Secure flag. 

    Security Impact

    When the Secure flag is not set, the user’s cookies will be sent over HTTP if a request is made to that website’s HTTP port. Most websites now support HTTPS, but there are still multiple ways for cookies to be sent over HTTP even when the server supports HTTPS. For example, if a website’s web server redirects HTTP requests to use HTTPS, it’s possible the initial web request will have sent cookies that are not using the Secure flag. Similarly, if a user clicks on a link (e.g., from a phishing email) that doesn’t have https:// appended to it, the initial request will send any cookies for that website that are not using the Secure flag. An attacker that is sniffing traffic would then be able to see the cookie’s value in cleartext. The Strict-Transport-Security header can help to mitigate some of this impact, but, to ensure cookies are never sent over an unencrypted channel, the Secure flag should always be used.

  • Hurricane Ida: Limiting the Damage

    As someone who has lived through several hurricanes and worked as a first responder for years, my heart breaks for our neighbors on the Gulf Coast and inland areas who are now assessing the damage from Hurricane Ida. For those who haven’t experienced it, devastation doesn’t begin to describe the aftermath of such a powerful storm.

    While we hope and pray for the people who were in the storm’s path, I want to offer a few tips from the cybersecurity career I’ve pursued since leaving emergency services work 16 years ago:

    • Scammers strike when we’re most vulnerable. Don’t let your guard down now.
    • Be mindful of what you post on social media. Giving too much personal information could lead to identity theft or give a criminal the location of your home you just evacuated. Provide personal information only to valid sources like FEMA, the Red Cross, and your insurance companies.
    • Be on high alert for phishing emails disguised as aid requests. Legitimate rescue personnel (volunteer or professional) will never ask for money. Donate to the Red Cross, Salvation Army, or a local organization you already know and trust.
    • Rely only on reputable sources for critical information. Social media is good for keeping up with friends and relatives, but it’s also full of misinformation and scams. Double-check important news by cross-referencing it on local, state, or federal government pages, or with reliable media. Also, remember that there are a lot of “fake” media pages.
    • If you’re in an area that is hard hit and don’t have cell phone service, turn off your phone. The phone will die more quickly if it’s searching for a cell tower. Turn it on later and see if cell service is restored. If not, turn it back off, and try again later.
    • Likewise, don’t send sensitive information over public WiFi. In the wake of a disaster, it’s all too easy for scammers to intercept traffic and collect passwords, credit card numbers, banking information, and other private data.

    We can’t prevent hurricanes, and it’s likely there will always be scammers and hackers among us. However, a little caution can help us avoid being victims of a man-made disaster at the same time we deal with nature’s worst destruction.

  • PRTG Network Monitor Stored Cross-Site Scripting Vulnerability (CVE-2021-29643)

    Vulnerability Summary

    Recently, I discovered a stored Cross-Site Scripting vulnerability in PRTG Network Monitor Version 21.1.66.1623+. The vulnerability exists in the email field of user details on the “User Accounts” page at /systemsetup.htm?tabid=5 when users are loaded from Active Directory. After the page loads, the email field is loaded with unescaped content, allowing malicious JavaScript to be reflected back to the user.

    Proof of Concept and Exploitation Details

    The vulnerability can be triggered by inserting HTML content, specifically script tags, into the email field of an Active Directory user. The following was inserted as a proof of concept to reflect the user’s cookie in an alert box:

    <script>alert(document.cookie)</script>

     An example of this on one such user can be seen in the image below:

    Stored XSS Payload

    After loading the list of users, the HTML is then presented unescaped on the web page, which allows the script tags to be loaded as valid JavaScript. The unescaped HTML, as it loads in the browser, is seen in the next image:

    Unescaped JavaScript Tags

    Once the page loads, the JavaScript executes, displaying the user’s cookie to the screen, as shown in this picture:

    XSS Payload Execution to Display User’s Cookie in an Alert Box
    Vulnerable Software Version

    Raxis discovered this vulnerability on PRTG Network Monitor version 21.1.66.1623+.

    Remediating the Vulnerability

    Upgrade PRTG Network Monitor to Version 21.3.69.1333 or later immediately. The release notes and upgrade instructions can be found here: https://www.paessler.com/prtg/history/stable#21.3.69.1333.

    Disclosure Timeline
    • March 22, 2021 – Vulnerability reported to Paessler Technologies.
    • March 25, 2021 – Vulnerability confirmed by Paessler Technologies.
    • April 12, 2021 – CVE-2021-29643 assigned to this vulnerability.
    • July 6, 2021 – Paessler releases version 21.3.69.1333 to address this vulnerability.
    CVE Links & More

     

     

  • Don’t Take the Smishbait

    Unwanted text messages are always annoying, but some can be dangerous. Smishing is a phishing attempt carried out via text and it can be more effective than you might think.

    Smish - A phish via text message

    We’ve all been there — waiting on an important text message, receiving a notification, and opening the phone only to see a message about our car’s warranty expiring.

    Isn’t that just the worst?

    As it turns out, no. Far more damaging are the ones that bring phishing and spear-phishing into the more personal, less-guarded world of SMS texting. You’ve probably heard the portmanteau “smishing” (SMS + phishing) to describe the practice, but you may wonder how and why it works. More importantly, you should know what you can do to make sure it doesn’t happen to you.

    The psychology of smishing

    At its essence, smishing is a form of social engineering that relies on the implied urgency and intimacy of a text message. Whereas most businesses have effective spam and virus filters in place, and we’re reminded often about the dangers of email, text messages often bypass company security. What’s more, they occupy a different place in our minds than standard business communications.

    If email reflects the type of discussion you might have in the conference room, texting is more like banter over drinks after work. In the former, we’re conscious about what we say and what we hear. In the latter, we’re more relaxed and trusting of those around us. And, like other forms of social engineering, that’s what hackers count on when they send a smish.

    Enabling technology

    There are several widely available consumer-grade apps that allow the user to spoof a phone number, display a fake name, and send a message directly to voicemail or text. In the name of privacy, they offer anonymity to the sender, making it extremely hard to trace. Though the phone companies are working to identify and warn users that such messages may be fake, more customizable and concealable apps are available for sale on the dark web.

    As with email, these provide scammers with the ability to deliver malicious phishing links to a broad audience. One click could download malware to your device or take you to a website that will attempt to harvest your credentials. But more troubling is the advanced spear-phishing abilities they provide. We might suspect a direct request for money (or gift certificates) or something obvious. However, consider the image above and ask yourself how many of your employees would immediately comply just to be helpful. If they do, it could render your multi-factor authentication meaningless.

    Protecting yourself and your company

    There are several other ways smishing can put your organization at risk, and there’s only so much technology can do to protect. With that in mind, here are several things you can do to make sure you and your organization don’t become smishing victims.

    • Remember that a legitimate person or company sending you a text message will want you to be wary and check.
    • Even if you recognize the company, think about other texts you’ve received from them. Most pay services, like Venmo and PayPal for example, include “we will never call or email you to request this PIN.” Most banks tell you to login to their site rather than include a URL in the text.
    • Even if the phone number looks correct, remember that numbers and names are easily spoofed. A strong phish may email, text, and call you so that you feel like someone has backed up the claim that it’s legit.
    • A true alert should provide a way for you to take the requested action without using the text. Login to a trusted URL that you have bookmarked. Call the number on the back of your credit card to confirm. Or, reach out in some other way that doesn’t rely on information provided by the same person or company.
    • Messaging apps often provide a way that you can report spam, scams, and phishes. Reporting them helps them block further attacks and makes it harder and more expensive for the hacker to continue.

    The bottom line is that any form of electronic communication is subject to compromise by a determined hacker and there is an ongoing “arms race” between hackers and the experts working to keep us safe. That’s why personal vigilance will always be the most important security measure in our cybersecurity toolkit.

  • ManageEngine Applications Manager Stored Cross-Site Scripting Vulnerability (CVE-2021-31813)

    I’m Matt Dunn, lead penetration tester here at Raxis.This is a summary of the third stored cross-site scripting vulnerability I discovered while testing several Zoho-owned ManageEngine products. This vulnerability exists in the Applications Manager product.

    Summary

    Recently I discovered a stored Cross-Site Scripting vulnerability in ManageEngine Applications Manager. The vulnerability exists in a users’ name fields when they are imported from Active Directory. This can be performed in any of the name fields and is executed when selecting the user for import on /admin/userconfiguration.do after fetching users from the domain. After the import loads and the user is selected, the user’s name is loaded with unescaped content, allowing malicious JavaScript to be reflected back to the user.

    Proof of Concept

    The vulnerability can be triggered by inserting html content, specifically script tags, into the first or last name of an Active Directory user. The following was inserted as a proof of concept to reflect the user’s cookie in an alert box:

    <script>alert(document.cookie)</script>

    An example of this in the Last Name field of one such user can be seen here:

    Stored XSS Payload

    After that user is selected and the details load on the “User Imported from Active Directory” page, the HTML is presented unescaped on the web page, which allows the script tags to be loaded as valid JavaScript. The unescaped HTML as loaded can be seen here:

    Unescaped JavaScript Tags

    After loading the selected user, the malicious content is executed, as shown below:

    JavaScript Execution to Display User's Cookie in an Alert Box

    Affected Versions

    Raxis discovered this vulnerability on Manage Engine Applications Manager 15, Build 15080.

    Remediation

    Upgrade ManageEngine Applications Manager to Version 15.1 Build 15130 or later immediately which can be found here:

    Disclosure Timeline

    • March 18, 2021 – Vulnerability reported to Zoho
    • March 18, 2021 – Zoho begins investigation into report
    • April 27, 2021 – Zoho releases fixed version 15.1 Build 15130
    • April 27, 2021 – CVE-2021-31813 is assigned to this vulnerability

    CVE Links

  • Why Mutual Assured Destruction is an Incomplete Cyber Defense Strategy

    “Like it or not, all of us are on the front lines in a cyberwar that is heating up with every day that passes.”

    Bonnie Smyre, Raxis Chief Operating Officer

    In the wake of the Colonial Pipeline breach, security analysts have discussed the idea that direct retribution might be an effective deterrent to the large-scale cyberattacks of the sort the US is experiencing ever more frequently nowadays. As someone with a strong background in Russian and Eastern European studies, I understand the historical precedent that drives this mindset. However, as a cybersecurity professional, I know that half-century-old strategy will not be nearly as effective against the challenges we face today.

    Some ‘MAD’ Background

    In the most dangerous days of the Cold War, US and Soviet leaders agreed to a counterintuitive policy that helped ensure neither side would launch a catastrophic nuclear first strike. Recognizing that stockpiles of atomic weapons were sufficient to destroy Earth many times over, the two superpowers agreed that the world was most secure when both sides maintained the ability to respond to a first strike with an equally devastating counterstrike.

    Though it sounds barbaric, the strategy of mutual assured destruction (MAD) was one reason a period of détente lasted long enough for both nations to de-escalate tensions and negotiate dramatic reductions in the size of their nuclear arsenals.

    The New Battlespace

    Though the Soviet Union fell apart in the early 1990s, and the US ‘normalized’ relations with China, the threat they posed to America never disappeared completely. Instead, it has evolved with new technology and shifted into cyberspace. Hackers with ties to Russia and China are widely believed to have been responsible for high-profile breaches of government agencies and contractors, meddling in US political campaigns, and sabotaging critical infrastructure.

    I say ‘widely believed’ because in the shadowy world of hackers it’s nearly impossible to prove an attack was state-sponsored. Malicious actors are very much cybercriminals without borders, and it’s not hard for hostile nations to contract out some of their dirtiest work.

    As for the weaponry, ransomware, like the type used in the Colonial Pipeline hack, can be a few lines of code, readily available for sale on the dark web. Some of the more helpful black hats even offer support for an additional fee.

    Where Deterrence Fails

    The simplicity and anonymity of cyberwarfare do more than give cover to state-sponsored actors. In the context of mutual assured destruction, a more dangerous possibility is that non-state actors could launch an attack that triggers a misdirected, full-scale state response. In that scenario, it’s easy to envision a rapid escalation leading to military action.

    An even bigger problem with the MAD concept, however, is its central tenet that the civilian population is purposely left exposed. In the case of nuclear war, there is a macabre logic behind that. Taking away the fallout shelters, civil defense infrastructure, and air raid drills made clear to everyone that a nuclear war between the superpowers would likely be the end of civilization. Entering the launch codes meant worldwide annihilation, plain and simple.

    In the case of cyberwarfare, there simply isn’t a clear delineation between military and civilian or even public and private sector targets. Colonial is a private company, as are many utilities and other organizations that are of vital importance to our national security. Was the recent ransomware attack a simple economic crime or a strategic strike on the Eastern Seaboard?

    Nor is there a foolproof way to gauge the severity of the attack. A small business might be hacked in order to reach a larger upstream supplier. And disrupting several municipalities could have the same strategic impact as an attack on the federal government.

    We are the Front Line

    From a practical perspective, what all this means is that, at most, deterrence can only be one part of a much larger strategy. And, unlike the Cold War, this new state of perpetual, persistent cyberwarfare can’t be waged solely by our military or managed by diplomats alone.

    We’re all in this together. As long as one business is at risk, all of our businesses are. If our businesses are at risk, so is our government. And if our government is at risk, so are our people – from all walks of life.

    Like it or not, all of us are on the front lines in a cyberwar that is heating up with every day that passes. The good news is that there are things we can do to protect ourselves and to become harder targets. As we do so, we raise the technological barriers, drive up the costs, and increase the risk to those who would attack us.

    Mutual assured destruction helped end the Cold War without nuclear confrontation. But the key to ending global cyberwarfare may well be mutual cooperation – among our government, our military, and our businesses of all sizes.

  • A High-Tech Take on an Old-Time Scam

    “There’s not much chance your customers are going to search for you and land on an Albanian copycat site.”

    Raxis VP of Engineering, Brian Tant

    If you get an email warning you that another (usually overseas) company is vying for your brand’s domain name with various country extensions – cn, .hk, .af, etc. – be assured it’s not someone aiming to help. Instead, they’re most likely scammers trying to convince you to send them money in order to secure your hold on yourbrand.nz before some evil corporation in Uzbekistan snatches it right out from under you.

    As you might expect, people do fall for it and spend hundreds and even thousands of dollars only to discover that a) there is an exhaustive list of domain extensions out there and b) the people they’ve paid won’t really secure any of them. Fortunately, that last part is mostly a nonissue. 

    The truth is, very few US-based companies have a need to own foreign domain extensions unless they have a physical presence in the country. Even then, it may not be necessary unless a competing brand is actively trying to damage your business, in which case most countries have laws in place to prevent such malicious activity.

    Search engines are sophisticated enough now to distinguish between legitimate, established domains and pop-up imitators, so there’s not much chance your customers are going to search for you and land on an Albanian copycat site. 

    Still, the emails can sound very convincing, and, believe it or not, they are really a modern update to a scam that flourished in the late ‘90s and early 2000s. That one involved the Yellow Pages and was made possible because AT&T never trademarked the name or the iconic walking fingers logo. 

    Here’s how it worked: Just days after a new company incorporated or applied for its licenses, an official-looking invoice would arrive from The Yellow Pages. No business wanted to be left out or forced to wait a year to be included, so many quickly filled out their information and sent a check. 

    Weeks later, unfortunate business owners would get another Yellow Pages invoice, this time the local version – the one people actually used. When they called the phone company to complain, they would learn that their first checks had gone to a group that published a perfectly useless national version of the yellow pages. It listed only those businesses that had fallen for the scam and was distributed only to them.

    Word about the faux yellow pages eventually got around and made it much harder to sell. We can only hope the same will be true of the domain name scam. Of course, the great irony here is that the internet has all but made the yellow pages irrelevant to modern businesses. At the same time, it has made possible a high-tech, international version of its most annoying racket

  • SonicWall Patches Three Zero-Day Vulnerabilities

    SonicWall has tested and published patches to mitigate three zero-day vulnerabilities in its email security products this week. Hackers are actively exploiting these vulnerabilities in the wild, and customers should patch them immediately.

    Affected Products

    The vulnerabilities affected the following versions of SonicWall’s email security and hosted email security products:

    • 10.0.1
    • 10.0.2
    • 10.0.3
    • 10.0.4-Present
    The Addressed Vulnerabilities

    The patches released by SonicWall mitigate three CVEs, listed below:

    More details from SonicWall can be found in its company advisory as well as in FireEye’s detail of how the exploits were being used. Here are links to both:

    Remediations

    SonicWall has patched its hosted email security product automatically, but customers will need to upgrade in-house email security products on their own, using the following versions:

    • (Windows) Email Security 10.0.9.6173
    • (Hardware & ESXi Virtual Appliance) Email Security 10.0.9.6173

    SonicWall also provides detailed instructions for upgrading in this advisory article: https://www.sonicwall.com/support/product-notification/security-notice-sonicwall-email-security-zero-day-vulnerabilities/210416112932360/

     

  • NSA, FBI, CISA Statement on Russian SVR Activity

    What does it mean for your business?

    Summary of the Statement

    Last week, the National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), and Federal Bureau of Investigation (FBI) released a joint statement on five different vulnerabilities that the Foreign Intelligence Service of the Russian Federation (SVR RF) is known to be exploiting currently.

    How does this affect your business?

    Even if your business is not a target of the SVR RF, other threat actors such as ransomware gangs, are taking advantage of the same vulnerabilities. Therefore, if you have been using any of the affected product versions, you should take them offline, upgrade to the most recent version, and begin an incident response process to verify your servers are not compromised. Additionally, Raxis recommends performing the same process on other recently exploited products such as SolarWinds Orion and Microsoft Exchange Server.

    Affected Product Versions & Associated CVEs

    Fortinet FortiGate VPN

    • Version: Fortinet FortiOS6.0.0 to 6.0.4, 5.6.3 to 5.6.7 and 5.4.6 to 5.4.12
    • CVE: CVE-2018-13379

    Synacor Zimbra Collaboration Suite

    • Version: Synacor Zimbra Collaboration Suite 8.7.x before 8.7.11p10
    • CVE: CVE-2019-9670

    Pulse Secure Pulse Connect Secure VPN

    • Version: Pulse Connect Secure (PCS) 8.2 before 8.2R12.1, 8.3 before 8.3R7.1, and 9.0 before 9.0R3.4
    • CVE: CVE-2019-11510

    Citrix Application Delivery Controller and Gateway

    • Version: CitrixADC and Gateway versions before 13.0.47.24, 12.1.55.18, 12.0.63.13, 11.1.63.15 and 10.5.70.12 and SD-WAN WANOP 4000-WO, 4100-WO, 5000-WO, and 5100-WO versions before 10.2.6b and 11.0.3b
    • CVE: CVE-2019-19781

    VMware Workspace ONE Access

    • Version: VMware One Access 20.01 and 20.10 on Linux, VMware Identity Manager 3.3.1 -3.3.3 on Linux, VMware Identity Manager Connector 3.3.1-3.3.3 and 19.03, VMware Cloud Foundation 4.0-4.1, and VMware Vrealize Suite Lifecycle Manager8.x
    • CVE: CVE-2020-4006

    Remediation

    If your business is running any of the aforementioned product versions, upgrade immediately to the most recent versions following the guides for each product below:

    Fortinet FortiGate VPN

    Synacor Zimbra Collaboration Suite

    Pulse Secure Pulse Connect Secure VPN

    Citrix Application Delivery Controller and Gateway

    VMware Workspace ONE Access

    Solarwinds Orion

    Microsoft Exchange

    Additionally, Raxis recommends beginning an incident response process on any servers exposed to the internet that are running these product versions, as they are actively being exploited in the wild.

    Associated Links

    NSA, FBI & CISA Statement: https://www.nsa.gov/News-Features/Feature-Stories/Article-View/Article/2573391/russian-foreign-intelligence-service-exploiting-five-publicly-known-vulnerabili/

    CVE Links:

  • Three Questions to Ask Before Connecting a Device to the Internet

    “In theory, even our refrigerators could turn against us and order low-fat ice cream instead of our Ben & Jerry’s.”

    Raxis Lead Penetration Tester, Scottie Cole

    I’m a gadget guy with a lot of IT experience, which of course makes me the pro bono tech troubleshooter for every friend and relative within 100 miles. It also means I’m the guy they call when they want to connect their latest gizmo to the Internet.

    I don’t usually mind helping, but I often find myself wondering if people are putting enough thought behind this race to connect to the Internet of Things (IoT). 

    Ha! Just kidding. I know for a fact that most aren’t putting any thought behind it.

    The allure of convenience, the snob appeal of being an early adopter, and the FOMO factor make it incredibly easy to sell these devices. But there’s no incentive to also talk about security issues – and that’s a big problem. 

    So, as a public service, I’m taking off my gadget-geek gear and putting on my professional hacker hoodie. Before you connect any device to the Internet, ask yourself these questions (and answer them honestly):

    Will I really use it as much as I think? This is about more than simply being frugal. The less you use a device or an associated app, the more likely you are to miss important updates and leave security patches uninstalled. You might not be paying attention, but hackers surely are. Which brings up a second question . . . 

    Can I secure it? Why don’t we pose that question to Alexa? Oh, wait. Can we trust her? Really, we only have a pinky swear from the company that she’s not spying on us. And that’s a potential problem with many devices. Even as a security professional, I can only control the security on my end. If it’s a centrally administered service, I have to also trust the company to protect access to the device as well. That’s why it pays to really read what they have to say about security. And that raises a third, even more important question . . . 

    What am I putting at risk if it’s hacked? One of the great IoT ironies is that some of the products sold under the guise of making us more secure are often the most vulnerable to attack. That means security cameras can turn into spy cameras. The ability to lock our doors remotely means they can be unlocked the same way. In theory, even our refrigerators could turn against us and order low-fat ice cream instead of our Ben & Jerry’s.

    A more urgent concern is that any device connected to your network can become a pathway for unauthorized access. If you think that’s unlikely, watch my colleague Scott Sailors hack a wireless mouse. From a practical perspective, that means you should segment your network so that, if your toaster is hacked, you’re not putting all your bank and credit card data at risk as well. 

    The reality is that connected devices are improving our lives dramatically and we haven’t even scratched the surface of their real capabilities. It’s exciting to realize that more and more devices are becoming smarter and more capable. In order to fully enjoy the advantages of being connected, we simply need to be realistic about our abilities, mindful of the risks we take, and diligent about mitigating them effectively.

    Companies hire the team here at Raxis to identify vulnerabilities and correct them before hackers can take advantage. As individuals, it’s up to us to do it ourselves.

    Of course, you can also call on a friend or relative to help. (Not me, though. I’m all booked up through the end of the year.)

  • Why Companies Shouldn’t Overlook Mobile Application Testing

    There are apps sold to the general public and ones that are made available by businesses to their customers, as well as proprietary apps used only within organizations. What all of these apps have in common is that, without proper security, they are all vulnerable to attack. And each of those 200 billion downloads represents an ever-expanding pool of potential hackers and victims.

    That’s why conducting penetration tests on mobile applications is one of the most important services we offer here at Raxis. We’ve tested apps for Apple, Android, and Windows phones, using up-to-date devices, jailbroken iPhones, and rooted Android devices, as well as emulators that allow further testing.

    Here are some of the most common issues we find:

    Jailbroken or Rooted Devices

    Ideally, apps should be setup so that they won’t even run on devices that are jailbroken or rooted. People often do that to their devices to have more control than the vendor intended, allowing them to download unauthorized apps from stores such as Cydia. The danger is that such apps that may allow nefarious activities or steal users’ data.

    Phones that have been jailbroken or rooted are also open to attacks on the operating system itself, possibly giving an attacker control of the device as well as control of legitimate applications. Our strong recommendation to developers is to build into apps the ability to recognize a device that has been compromised and to block its access until the device is updated correctly.

    No SSL Certificate Pinning

    We also find many mobile apps that don’t use SSL certificate pinning. SSL certificate pinning validates the authenticity of an SSL certificate. When an application fails to verify the certificate, it opens the door for a man-in-the-middle (MitM) attack, in which the attacker can insert himself into the encrypted traffic between the app and the server. This can be accomplished through name resolution poisoning, adding a proxy server, or a number of other ways.

    The attacker then can use his own certificate to impersonate the API server and decrypt the application traffic, read or manipulate it, re-encrypt it, and forward it onto the intended destination without detection. This type of attack not only allows an attacker to decrypt both incoming and outgoing traffic (such as credit card numbers and passwords), but also allows the attacker to change it. Using a typical bank transaction as an example, the hacker could transfer the funds to his account instead of yours.

    Shared Vulnerabilities

    Not all vulnerabilities are exclusive to mobile applications. We also find many, such as SQL injection (SQLi) attacks, that can be weak points within web applications as well. That’s why it’s important to test mobile apps separately from web apps. Even though they may use the same APIs and databases, and the user experience may feel nearly identical, the platform code and environment are different. Testing each one ensures that a hacker can’t exploit the app simply by changing platforms.

    Internal Apps

    Raxis has tested apps that are made available for customers as well as proprietary apps that are used within organizations, such as on flights for meal service. We’ve worked with companies that were less concerned with internal apps and proprietary devices because they were only available to employees. In those cases, we explain that personal and proprietary devices could fall into the wrong hands. If an internal mobile device or app runs on a production network, an attacker that gains access to the device is one step closer to accessing company data that may be on that network.

    What You Can Do

    Many of the companies that come to Raxis for mobile tests use that as a marketing tool. They are proud to show potential customers that they have a strong focus on securing their data. So, take a look at the apps on your mobile device. Do you know if they’ve been tested by a company like ours? It’s always a good idea to read the security and privacy data before you download.

    And remember, if you’re not sure, you can always ask – in public forums or user groups, or even directly to the app developers themselves. If they don’t currently conduct routine penetration testing, your questions might convince them they should.

    *SOURCE: Statista c. 2020