Categories
Mobile Application Protection

Preventing Cyber Threats for Mobile Applications

Reading Time: 5 minutes

With the advent of new technologies and the rapid shift in consumer habits, applications on smartphones and tablets have become prevalent in our everyday lives. It has never been easier to access mobile banking than it is now, let alone to book flights or shop online. But with this ever-increasing dependence on our smartphones and tablets, we are also more exposed to cybercrime than ever before.

The myth that mobile apps are invulnerable to cyberattacks hasn’t withstood scrutiny. It’s true that mobile apps, on average, have fewer vulnerabilities than desktops or laptops, but their widespread use and application present hackers with a broad. and nearly irresistible, attack surface area.

The good news is that there are many steps the tech industry can take to protect itself from threats.

Mobile Application Breaches

Mobile devices are vulnerable because of their open architecture and their ability to connect to other devices and networks. Mobile apps are particularly at risk. Hackers can exploit bugs and errors, either in the code of the app or on the app store that hosts them.

The top vulnerability is unencrypted data transmission. Bad actors can easily intercept unencrypted data when it travels from one device to another. That often happens when a user goes online while using an unsecured network, like their coffee shop Wi-Fi network, and connects their device to it.

But there are other potential problems, especially in app development. Incorrect default credentials or failing to validate input parameters before storing them in memory can lead to serious vulnerabilities within the app itself.

In one major breach that just happened recently, cybercriminals uploaded a counterfeit crypto wallet to the iOS App Store. The unfortunate users who downloaded it and entered their credentials, thinking it was safe, were instantly deprived of their funds. And this while using iOS, often considered a safer alternative to Android! 

How Mobile Application Breaches Affect the Industry

Mobile devices have become an integral part of our lives and we depend on them for everything from banking transactions to social networking. They contain sensitive information, such as passwords and payment card data, which makes them especially vulnerable to security breaches. 40% of all data breaches were traceable in some way to a mobile device. 

These breaches create a lack of confidence among users and can cause them to question whether it’s safe to conduct transactions on their mobile device. As more people use mobile devices for financial transactions, the number of security breaches will probably continue increasing at an alarming rate.

The Industry Response

App developers must double down on their security practices during and after development. That includes investing in secure coding practices like encryption and making sure they’re using the latest version of any tools they use. They should also consider implementing application hardening tools, such as those that PreEmptive offers, that can help uncover any security threats before they become major problems.

The added expenditure into security means that the tech industry is spending more money on product development. After many painful lessons, industry leaders have learned to take the threat of mobile cyber attacks seriously, no matter the platform. This means that not only are companies creating more secure applications and platforms, but they are also investing in security tools that can help them identify vulnerabilities.

Mitigation Measures Within App Development 

The risks of launching untested applications are clear: potential data breaches and reputational harm. But how can companies mitigate these threats? There are several things to consider before releasing an application, including legal matters and security vulnerabilities. Here are some best practices for mitigating these risks:

  • Make sure developers understand the app’s purpose and requirements.
  • Conduct thorough testing before launch, including penetration testing, end-to-end testing, and user acceptance testing.
  • Make sure to have documented processes in place to handle any security issues that arise after launch.

App testing, for example, is the process of ensuring that an application meets its business requirements, functional requirements, and quality standards before being deployed for use by end users.

Software testers play an important role in ensuring that applications are free from defects and ready for release. They identify errors or defects in software requirements, design, code, and other elements of the software lifecycle. They also help ensure compliance with industry standards and regulations. Testers can work as part of a group or individually on specific projects within the organization.

Developers can also contract with third parties like PreEmptive to help them reduce security vulnerabilities in their apps. Third-party utilities can be used to scan the code for vulnerabilities, perhaps even finding some that would be otherwise missed by the developers themselves.

Building More Secure Mobile Apps

Given the threat of mobile breaches, there’s an ever-increasing need for developers to create more secure applications. App developers can start reducing their risk at multiple different levels:

  • Secure Coding Practices. Developers need to use secure coding practices that provide protection against common vulnerabilities like SQL injection, cross-site scripting and insecure data storage. These types of bugs can expose sensitive data to unauthorized parties or even allow attackers to take over an app.
  • Protecting Sensitive Data. Sensitive data includes credit card numbers, social security numbers, or other personal information. User data should always be encrypted and securely stored, whether on a company’s own server or a hardened server owned by a third-party.
  • User Authentication and Authorization. User authorization refers to restricting what resources each user can access at a given authorization level. An example is only allowing certain users to access specific features or functionality within the app based on their role within the organization.
  • Auditing, Testing, and Training. App developers can hire a team of experts to audit their apps, both internally and externally. They should also test their apps to make sure they work as intended. New security-oriented training procedures can be implemented across the entire organization as well.

Whether speaking about a corporate entity or an independent developer, mobile app security is a serious issue that can have disastrous implications if not approached carefully.

Companies should build their apps with security in mind from the start. PreEmptive is the leader in application security testing and analysis. We provide solutions that are easy to use, yet effective in preventing many types of vulnerabilities and defects in common mobile applications and systems. Contact us to learn more about how we can help you. 


Categories
101

How Important Is CI/CD in DevSecOps?

Reading Time: 4 minutes

There is no doubt that devsecops has become a critical component of application development and security. By integrating devops and security practices, devsecops can help organizations speed up their application delivery while ensuring that they build security into their process. Devsecops is defined as a set of practices that combine development and operations teams with security teams to secure the application development process from the beginning.

One of the critical components of devsecops is continuous integration/continuous delivery (CI/CD). CI/CD helps organizations  automate the application delivery process, from code development to product deployment. This can help organizations speed up the delivery of new features and fixes while reducing the risk of errors and security vulnerabilities.

This article will look at the importance of CI/CD in devsecops and things to watch out for in application development. It will also highlight reasons why developers should use CI/CD in devsecops, and how CI/CD can help organizations improve their applications’ security.

Why CI/CD Is Useful in DevSecOps?

CI/CD is a process that helps developers quickly build and test code changes, making it easier to integrate new features into applications. CI/CD is vital in devsecops because it helps organizations automate the application development process, from code development to product deployment.

The process also creates a feedback loop between developers and operations teams, helping them to identify and fix problems quickly. The ability to rapidly resolve problems helps reduce the chance of business-critical systems going down and can lead to improved customer satisfaction.

The overall process helps improve the quality of the code and speed up delivery times, making it an essential part of devsecops. There are three main reasons why CI/CD is so useful in devsecops:

  1. It helps organizations automate the application delivery process.
  2. It helps organizations improve the quality of their code.
  3. It helps organizations reduce the risk of errors and security vulnerabilities.

Automate the Application Delivery Process

One of the most significant benefits of CI/CD is that it helps organizations automate the application delivery process. By automating the process, organizations can save time and effort that would otherwise be spent on manual tasks. Automation can also help organizations improve the consistency and quality of their code and reduce the risk of errors and security vulnerabilities.

Automation further provides an opportunity for standardizing the development process across the organization, making it easier for developers to work together on code changes. By merging the testing and  deployment processes into a single automated pipeline, it is easier to manage and monitor the application development process.

Improve Code Quality 

Another significant benefit of CI/CD is that it helps organizations improve the  quality of their code. By  automating the testing and delivery process, organizations can ensure that their code is of a high quality before deploying it. Improving the quality leads to the development of better products and eventually better customer satisfaction.

High-quality code becomes easier to maintain and scale as the product evolves. The use of  in-app protection tools offered by PreEmptive can further secure the code base.

Reduce the Risk of Errors and Security Vulnerabilities

Finally, CI/CD can help organizations reduce the risk of errors and security vulnerabilities. Organizations can ensure that their code is tested and deployed quickly before any security vulnerabilities can be exploited. The use of devsecops tools and techniques can further help organizations secure their code and reduce the risk of errors. One such tool is static code analysis, which can help organizations identify and fix security vulnerabilities in their code before it is deployed. 

The use of  in-app protection tools can also help secure the code and reduce the risk of errors.  PreEmptive offers a variety of protection tools on a variety of platforms. The tools assist in protecting against intellectual property theft and data breaches while identifying potential attack vectors. PreEmptive protection tools are available for .NET, Java, and iOS. The tools apply a layered approach to security that includes code signing, tamper resistance, string encryption, and app-hardening.

Why Developers Should Use CI/CD in DevSecOps?

As devsecops teams have gained prominence in recent years, so has the need for better tools to help manage the security of code bases. CI/CD is one of the most important security tools in this space.

One of the most significant challenges in devsecops is that developers are often working on code that needs to be released quickly, which can lead to security vulnerabilities being introduced. CI/CD can help mitigate this risk by automating the process of checking the code for errors and potential vulnerabilities before it is released.

CI/CD helps developers  prioritize security, from one-off assessments to daily or weekly tests that are built into the development process. By automating these tasks, devsecops teams can save a significant amount of time that would otherwise be spent on manual code reviews.

What to Watch Out For!

While CI/CD can help organizations improve the security of their applications, there are a few things to watch out for. First, it is important for developers to ensure that their CI/CD pipeline is configured correctly. Otherwise, they may inadvertently introduce new security vulnerabilities into their code. Second, it is important to ensure that their code is properly tested before it is deployed. 

Thorough testing of the code before deployment is essential in detecting  security vulnerabilities. Finally, it is crucial for developers to monitor their CI/CD pipeline for any signs of abuse. If there’s suspicion that the CI/CD pipeline is being abused, it is vital to take action to secure it. PreEmptive can help developers secure their CI/CD pipeline and prevent abuse. 


Conclusion

In conclusion, CI/CD is a critical part of any devsecops strategy.  PreEmptive offers high-quality, highly flexible,  smart application protection for a wide variety of industries. PreEmptive helps protect and secure applications for a broad range of platforms, including .NET, Java, Android, JavaScript, and iOS. 

PreEmptive’s solutions are backed by a world-class support team, which is available 24/7 to help developers get up and running quickly.  Review the wide range of products and services today, or  contact the team to learn more about how PreEmptive can help developers achieve their security goals.


Categories
Risk Management

3 Common Security Mistakes Developers Make in Their SDLC

Reading Time: 4 minutes

The systems development lifecycle (SDLC) is a process used by developers to create and deploy software applications. The SDLC provides a framework for security, quality assurance, and project management throughout the software development process. Security is of paramount importance in the SDLC, as developers must ensure that their applications are secure from attacks.

Quality assurance is also critical, as developers must ensure that their applications meet customers’ expectations. Project management is essential to the success of the SDLC, as it helps developers track their progress and ensure that they meet their deadlines. By following the SDLC, developers can create high-quality, secure software applications that meet customers’ expectations.

When it comes to developing software, the security of the final product should be a top priority. Unfortunately, this is not always the case. Security is often an afterthought, which can lead to vulnerabilities and exploits. 

3 Most Common Security Mistakes That Developers Make When It Comes to Cybersecurity

When it comes to developing software, the security of the final product should be a top priority. Security should be integrated into every stage of the SDLC, from initial planning to post-deployment. Here are three common mistakes developers make when it comes to security in their SDLC.

1. Not Using Software Security Tools to Prevent Cyberattacks

The first common mistake many developers make is failing to use the proper software security tools to prevent cyberattacks. They often try to develop their own tools or use free ones that are ineffective. This can lead to vulnerabilities in the code, which hackers can exploit.

Using software security tools can help developers find and fix vulnerabilities in their code, making it more difficult for hackers to capitalize on them. These tools can also help automate the process of checking and fixing vulnerabilities in the code, saving time and resources.

Different software security tools have varying roles in the SDLC. Some help identify potential security risks, some write secure code, and others test code for vulnerabilities. In-app protection tools assist in securing the app post-development. It is crucial to prioritize security at every stage of the SDLC to ensure that risks are appropriately mitigated and that the final product is secure.

There are many different software security tools available that can help prevent attacks. These tools can help find and fix vulnerabilities in the code. They can also help monitor the system for suspicious activity and block attacks.

PreEmptive offers a variety of  in-app protection tools that can be used throughout the software development lifecycle to secure code, aid in app hardening. and mitigate vulnerabilities. PreEmptive tools are designed to work with a variety of programming languages and platforms, making them versatile for developers. Whether a developer is looking to protect mobile apps, web apps, or desktop apps,  PreEmptive tools can help them secure the code and prevent vulnerabilities from arising.

2. Failing to Use Source-Code Analysis Tools

The second mistake developers often make is failing to use source-code analysis tools. These tools can help identify vulnerabilities in the code and provide recommendations for fixing them. Many developers are not  aware of these tools or do not use them properly. This can lead to serious security issues that could otherwise be avoided.

Source-code analysis tools can be used to find a variety of issues, including buffer overflows, SQL injection, and cross-site scripting. They can also help find vulnerabilities in third-party libraries. By using these tools, developers can find and fix vulnerabilities before hackers exploit them.

Source-code analysis aims to improve the security of an application by identifying potential vulnerabilities during the development process. Security issues can often be found in the code itself, so it makes sense to look for them early on.

Source-code analysis can be used at different stages of the SDLC. For example, it can be used to identify potential security risks during the requirements-gathering phase. During the design phase, it can also be used to ensure that security is built into the system, and it can be used during the testing phase to find any vulnerabilities that may have been introduced during development.

Once the source code is analyzed, the findings can be used to improve the security of the application. For example, if a potential vulnerability is found, the code can be fixed to prevent it from being exploited. Alternatively, if a security issue is found in a third-party library, the application can be redesigned to avoid using that library. The application can then be submitted to the  in-app software protection tools offered by PreEmptive for app hardening.

3. Not Doing Security Testing in All Phases of the SDLC

The third mistake that many developers make is not doing security testing in all phases of the SDLC. Security testing should be done throughout the entire process, from initial planning to post-deployment.  Security testing can help find and fix vulnerabilities in the code. It can also help ensure that the application is configured correctly and meets all security requirements.

Security testing can be done manually or with automated tools. Automated tools can help speed up the process and find more issues than manual testing. Security testing should be done regularly, even after the application has been deployed.

In most cases, security testing is treated as an afterthought, to be done right before the app goes live. Security testing in the earlier stages of development can help find and fix issues before they become a problem. Security testing should be done throughout the entire SDLC to ensure that the application is secure.


Conclusion

Cybersecurity threats are increasing in number and sophistication every day. Developers who want to stay ahead of the curve need to use the latest software security tools to prevent cyberattacks. While developers can make many potential mistakes in their SDLC, we’ve highlighted the three most common ones. Implementing security within the SDLC is critical to protecting applications from cyberattacks and data breaches.

PreEmptive offers high-quality, highly flexible, smart application protection, including app hardening, to a wide variety of industries, protecting and securing applications for a broad range of platforms, including .NET, Java/Android, JavaScript, and iOS.  Take a look at PreEmptive’s solutions today and see how they can help improve the application security posture.


Categories
101

Budgeting for DevSecOps: Key Points To Keep in Mind In Cybersecurity

Reading Time: 5 minutes

Cybersecurity is one of the areas of business that should never be ignored. Experts expect that cyberattacks will cost the world an estimated $10.5 trillion dollars in losses by 2025, making it an urgent priority for companies across every sector to get right. Not only can cyberattacks have a devastating impact on a company’s bottom line by leading to data breaches and other problems, they can also damage an organization’s reputation beyond repair. If a business fails to take the necessary time to address cybersecurity needs in its budget, it takes a significant risk that could cost them significantly if something goes wrong. 

Knowing how to budget for cybersecurity isn’t always easy. There’s more that goes into it than just buying software and hardware. Training staff and developing a culture of security within an organization must also be included.

Read on to find out how companies can make sure their cybersecurity budget meets their needs.

Know the Threat Landscape

Knowing the threat landscape is about knowing one’s enemy. Understanding what types of attacks are being used and by whom can help businesses better plan their security strategy. As malware authors continually evolve their approach, it’s crucial to stay informed about new threats and how they are being used.

In practical terms, that means:

  • Proactively monitoring the latest cyber attacks, including those identified by researchers at leading cybersecurity firms
  • Learning about new hacking and attack methods and vulnerabilities as soon as possible after their discovery
  • Maintaining up-to-date cyber protection on all systems with an internet connection

Companies should develop an acute awareness of the different attack vectors and vulnerabilities likely to affect their organization. Good managers will place themselves in the mind of an attacker and war game ways to overcome their own defenses. Would they implant Trojan viruses, or could they instead target one of the system administrators with phishing emails?

The conclusions that emerge will determine where and how the budget should be prioritized.

Don’t Just Think of One Single Network Perimeter

The best defense is a good offense, and this is especially true when it comes to cybersecurity. Businesses need to be proactive. The hackers are always working on newer, more advanced methods of attack, so defenders should plan for the future as a whole, not just threat parameters across one single network. They need a multilayered approach that will keep their network protected from threats internal and external alike.

Many breaches happen because companies are far too complacent with their cybersecurity measures. They rely too much on one single aspect of DevSecOps. But cyber attackers are getting smarter by the day: Defenders need to be flexible and adaptive.

Avoid Going Overboard

The point here is that cybersecurity budgets, like any other budget, should be managed with care. In determining the right amount to spend on cybersecurity in your organization, think about:

  • Risk Assessment. How high is the risk? What assets are most critical to protecting? What could happen if they were lost or compromised?
  • Cost. How much would it cost to recover from a breach? The more severe the potential financial damage, the more money businesses should consider directing toward cybersecurity.
  • Existing Controls. What defenses are already in place? If a company already has an extensive network of firewalls and intrusion detection systems, it may not need as much investment in additional security measures as another company.

Don’t budget more than is actually needed. The goal is to ensure that the right security measures are place to protect the organization. They don’t have to be the most expensive or sophisticated engineering solutions available.  They just need to work.

Think About the Cost of Underinvesting

The average data breach costs around $4 million, and this is just for the costs incurred directly by the victim. The real cost takes into consideration lost revenue and reputational damage.

Depending on the severity of the breach, businesses may be left dealing with an immediate loss of customer trust and reputation or even litigation from customers. It can also cause them to lose out on future business if customers don’t trust them with their money or personal information anymore.

Needless to say, no company can afford to take DevSecOps lightly.

Cybersecurity Is a Process, Not a Product

Cybersecurity should be a team effort that involves many people and departments throughout an organization. From the executive level to IT professionals to customer support personnel, everyone needs to be involved in cybersecurity efforts for the entire organization  to succeed.

It’s not enough for a network security team to just deploy their solution. Everyone needs to know how those solutions work and how they should be implemented. This includes ensuring that all new hires are trained on how these security solutions operate, so that everyone at the company understands and emphasizes cybersecurity in every aspect of their jobs.

They don’t need to know minute technical details, but they do need to understand the culture of cybersecurity and why it matters for their specific role in the company.

Budgeting Thoughtfully for Cybersecurity

Cybersecurity is a complex and ever-evolving field. To protect a business from cyber threats, cybersecurity defenders need to stay up to date on the latest security trends and technologies. But implementing good data hygiene practices takes time. There’s no quick fix for making sure all files have been properly encrypted or deleted.

  • Treat cybersecurity as a long-term investment. Cybersecurity isn’t something that can be put off until later — it’s an investment that can save businesses money long-term, but it’s also important to be thoughtful about how much it will cost and how best to spend that money.
  • Think beyond traditional IT solutions. Cybersecurity requires different skills than traditional IT, so don’t expect an existing IT staff to handle everything on their own. Businesses will also want someone who understands how human behavior affects security to help design processes that reduce the risk of someone inadvertently doing something that puts the company at risk.

Finding the Right Solution

One way for businesses to make sure their budgeting is on track is to work with someone who understands what kinds of threats exist and can give them realistic timelines for deploying effective solutions — and at what price point.


PreEmptive is committed to helping companies like yours protect their applications and networks from hackers, as well as ensuring that you are able to take control of your data. We offer free demos so you can see what we have to offer, and if you decide that our products are right for your business needs, we’ll be happy to work with you on a plan that fits within your budget.


Categories
Support Corner

How to Leverage Incremental Obfuscation when Protecting Large Applications

Reading Time: 2 minutes

In the previous Support Corner article, we discussed the significance of Cross-Assembly Obfuscation when configuring Dotfuscator.  Cross-Assembly Obfuscation ensures that classes, methods, properties and their references are automatically renamed uniformly across all Dotfuscator inputs.

Separated Assemblies Obfuscated

When related assemblies are obfuscated separately, they’re processed in Library Mode by default.  Library Mode does not rename public and protected types and members so that they can still be called by assemblies not included in that Dotfuscator project.  (Obfuscation transforms like Control Flow, String Encryption, and Tamper detection will be performed regardless of access modifier).

What if the different components of our app must be obfuscated as separate projects, but we still want to fully rename public types and members? This can be achieved by using Incremental obfuscation.

Incremental obfuscation

Incremental obfuscation uses Dotfuscator’s Rename Map file to maintain consistent identifier renaming across Dotfuscator builds.  It was created to enable patching a subset of assemblies for an obfuscated app already in production.  It can also be used to rename serializable types, so that full Renaming can still be performed on apps that persist serializable types to file. 

Along these same lines, Incremental Obfuscation can be used to maximize renaming when separating components of an app into multiple Dotfuscator projects.  

Example:

Consider the following example: a company maintains a set of common assemblies used by several different projects.  Each project has completely different sprints and release cycles.  In this scenario, the team maintaining the common assemblies uses Dotfuscator to fully obfuscate and rename publics.  They store the Rename Map file with their build artifacts.  Any team creating a front-end app will use that map file to rename references to the shared assemblies in their Dotfuscator project.  Only the map file is needed – they do not need to re-obfuscate the common assemblies.  When it’s time to deploy to production, all public and protected types and members for the full application will be renamed.

A simple example illustrating this concept can be downloaded here.


If you have feedback on this topic or other topics you would like us to discuss in the Support Corner, please feel free to contact our Support Department.


Categories
101

PreEmptive – JSDefender 101

Reading Time: 3 minutes

Did you know JavaScript is used by 13.8 million developers worldwide? This means that 53% of developers either use or have used JavaScript at some point throughout their career. Making this the most popular coding language in web and cloud development. As programming languages are an essential tool, they are a critical security & quality priority that all developers are focused on. And since programming languages are also opportunities for attack, it is essential to implement obfuscation protection as preventative measures to protect your work from being copied, attacked or leveraged to cause further damage.

Just like in our previous 101’s for Dofuscator for .NET, in this article we explain how JSDefender for JavaScript can help secure and protect your work using obfuscation techniques with additional layered security.

What is the Product used for?

Similar to Dotfuscator for .NET, JSDefender is primarily used to protect and harden your applications that are composed of JavaScript. It encrypts your projects through a layered approach. Javascript is commonly used and as the risks of hacking continue to expand, it’s more proficient to implement code security at the early stages of development. In other words, by not using some sort of cybersecurity, it is like leaving your phone on the table and unlocked for the world to see what you’re up to. But, on this scale it is not just your data that is exposed, but the entirety of your users data and product IP.

How does JSDefender work?

JavaScript apps are typically distributed in source form, meaning your code can easily be visible to anyone with access to a browser. If a project isn’t protected, a hacker can conveniently use a debugger (that is built in their browser) along with other sophisticated tools to analyze your code for vulnerabilities – which highlights the path of hijacking your project. JSDefender uses a layered approach that is applied to the binary code using obfuscation, encryption, tamper detection, domain locks, debugger removal, function recording and more, basically scrambling the source code making this very difficult for the average hacker.

When should you use JSDefender?

Anyone who is developing an IoT (internet of things), mobile/desktop application, SaaS (software as a service), or any system software program using JavaScript as your language of development, should be using JSDefender. It’s widely known that investing in DevSecOps (development security operations) is of increasing importance for not only companies, but freelancers as well. There is not an industry that has not been affected by a data breach, and any company who uses or has built a website should know the importance of investing in DevSecOps. We did a case study of GlobalMed who used JSDefender in order to protect their advanced virtual health platform and now they have become the world’s number one telemedicine company!

Where does JSDefender work?

JSDefender is injected directly into your source code. You can specify your own configuration file or use command line options to set up protection attributes. It takes minutes to set up and seconds to begin securing your source file. We have developed a demo so that you can visually see how this works in real time!

JSDefender demo

Why should you use PreEmptive JSDefender?

By using JSDefender you are taking action against any type of attacks to your JavaScript projects by obscuring and managing your vulnerabilities directly in your code within a matter of seconds. We know time is of the essence in development, but implementing security in the beginning of the SDLC saves you time, money and protects your reputation in the long-run. Waiting until the end to scan for vulnerabilities will only prolong the development cycle and you will end up running into issues that could have been avoided if security was part of the process early on. JavaScript is here to stay and as the world of tech advances, so will hackers. So if you feel that your DevSecOps isn’t up to par or stressed about being hacked, download a free trial by visiting our product page and start protecting your intellectual property today!


For more information on how to get started or need further help, we encourage you to use our resources, found in our navigation bar. We hope this blog has guided you to better understand JSDefender for JavaScript. Be on the lookout for our upcoming 101’s! 


Categories
Support Corner

Understanding Cross-Assembly obfuscation

Reading Time: 2 minutes

Enterprise application development involves several moving parts.  There may be different teams working on different components: server-side, client-side, GUI, API, database, etc.  Each component may have a completely different release cycle, and each team may be working completely independent of one another.  But however the work is divided, all these components must come together to work properly at runtime. Any professional application protection tool should have the ability to handle these complex scenarios without disrupting the development process.  

Dotfuscator’s Runtime

Dotfuscator is designed with that at the center. The tool allows users to get up and running quickly, while providing full control to adjust for specific project requirements.  Cross-Assembly Obfuscation is just one example of the many ways it provides us this flexibility. 

Dotfuscator treats its inputs as a set of related assemblies.  It examines all internal and external references, traverses the full inheritance hierarchy.  It then performs “Cross-Assembly Obfuscation” meaning classes, methods, properties and their references are renamed uniformly across all input assemblies.

Dotfuscator Flexibility

If it’s not feasible to obfuscate and deploy our entire application at the same time, this is not a problem for Dotfuscator.  It can be approached a few different ways, but the easiest to maintain is to build with Library Mode enabled for each project.  In Library Mode, Dotfuscator preserves public and protected types and member names and signatures.  Only private and internal types and members will be renamed.  Obfuscation transforms like Control Flow, String Encryption, and Tamper detection will be performed regardless of access modifier.  This ensures that calls to the obfuscated assemblies work properly whether the calling assembly has been obfuscated in the same project or not.  

Cross Assembly Obfuscation Example

A simple example can be downloaded here.  This shows the same set of assemblies (two dll’s referenced by one main exe) obfuscated two different ways.  In the first scenario, all assembly files are included in one Dotfuscator project.  In the second scenario, each assembly is obfuscated separately, with Library Mode enabled to preserve references between them.  In both scenarios, the obfuscated binaries come together to work properly at runtime. 


Stay tuned for our continuation article, we will examine other strategies for approaching obfuscation spanning different teams.  If you have feedback on this topic or other topics you would like us to discuss in the Support Corner, please feel free to contact our Support Department.


Categories
Risk Management

The Risks Of Not Using In-App Protection

Reading Time: 4 minutes

Businesses of all types rely on applications, in fact they have become the central way the majority of us live our lives. From online banking, to filing your taxes on your phone or attending a virtual doctor’s appointment. Every element of our lives is navigated by a mobile or desktop application

It’s not just users, companies are also reliant on applications. Using them to manage central operations, production, fulfillment and marketing. Organizations use applications in a myriad of fashions, by the same token every application adds further risk. 

Businesses are shifting online to meet emerging needs but are also being faced by an emerging risk landscape with expanding risk across the Internet of Things. Application protection as such is an essential component to protect every element of your organization. IP Theft, application attacks or data leakage can all have material impacts on the organization, reputation and adherence to regulations. The impact of failures in this regard can be expensive. In 2018 it was estimated that IP targeted cyber crime accounted for $50 to $60 Billion of global losses. The payment industry has established fines of up to $500K per incident for security breaches according to UCSC failure to comply for companies is clearly expensive. 

With that noted, it is important to examine the tacit consequences and long term impacts of not using in app protection:

Risk of Unauthorized Access

Unauthorized Access is a critical risk for the majority of industries that handle private information, specifically personally identifiable information. If a person who is not allowed to make use of your application starts making use of it then there are more chances that the individual will commit fraud. It is hard to predict the behavior or intentions of anyone but it is essential to take every proactive step to avoid unauthorized access. 

Vulnerabilities like Broken Authentication expose your applications to hackers gaining access and then committing fraud. Session management or credential management issues can easily enable hackers to gain access and commit fraud against your application. The worst part… these attacks often go unnoticed without in app protection or runtime checks. As we know the cost of breaches only goes up over time: A breach identified in 100 days costs approximately $5.99 Million, while a breach that takes longer can cost upwards of $8.7 Million. 

Hackers can also use access to your application to expose sensitive datam putting end users at risk of losing their personal data or facing the downstream risks of identity theft, data leaking and doxing. All of which present a tangible threat and will likely result in financial obligations for the organization, due to negligence and failure to protect their customers. It can also be as simple as privilege escalation, a user enabling additional privileges allowing them to control aspects of the application that should not be externally leveraged. A recent example is the 2017 Accenture attack.

Risk Of Fines & Financial loss

There is a reason that the top software companies like 1Password, Google & Adobe pay over $100,000 for researchers that identify vulnerabilities within their toolsets. The bug bounty is in fact a rapidly growing industry and entire organizations exist around identifying these vulnerabilities. A recent research report from IBM identified that finance security professionals detect just 56% of incoming attacks, managing 53% of these attacks and only preventing 31% of attacks completely. Organizations don’t have a comprehensive ability to mitigate risk, even if you are using SAST / DAST / IAST and penetration testing risks can still slip through the gaps. 

The average cost of vulnerabilities for all industries is approximately $13 Million. This combines the cost of paying for fines corresponding to regulation violations, the cost of remediating the risky vulnerabilities, the expense to prevent data from being leaked and the potential cost of IP being leaked. Then let’s lay on the cost of reputation damage, Security Magazine reports that 80% of customers will not continue to leverage a bank’s services if their information is compromised… this is probably justified. Organizations are equally skeptical of services following attacks and they will follow the example of customers.  But, reputation isn’t singular, organizations can also face the impact of loss of goodwill. It will impact your brand image and can prevent customers from even acknowledging the validity of your organization.

Risk of IP Loss

Intellectual property loss is likely the most pernicious risk of not using In App protection. It is often the case that applications include some form of intellectual property which could encourage competitors to copy, steal or leverage in their own applications. 

Reverse engineering is a significant issue for organizations, by enabling capabilities on the client side, users and hackers can gain access to and expose more functionality through the server siege of the application. Not obfuscating code enables these users to easily interpret the intended functionality of the application and identify how to replicate this operability. One recent example is American Superconductor, a U.S based provider of clean energy solutions. In 2011 their largest customer Sinovel ignored their contract and refused to pay millions of dollars owed. The company then obtained the source code for all of the electronic components and were able to install a pirated version into their wind turbines. The violation of the IP rights and loss of revenue can incur as much as $200 Million a year in losses. Without possibility for legal resources or ability to prevent continued leverage. 

IP trade theft costs organizations as much as 3% of Annual U.S. GDP.

But, what can be done to prevent these risks? 

Obfuscation, PreEmptive provides a layered approach that clings to the deployed application and helps to ensure any unidentified vulnerabilities that are hidden. Reducing the likelihood of hackers identifying and leveraging them. Obfuscation also protects your IP concealing the framework and structure of your application from corporate spying and ensuring your competitors can’t repurpose your sweat equity.

For more information about in-app security, visit our products page and start protecting your apps today!


Categories
Support Corner

Remove Log4J calls with DashO’s Method Call Removal

Reading Time: 3 minutes

As we all know Log4j is a ubiquitous piece of software used to record activities in a wide range of systems found in consumer facing products and services. The discovery of the recent vulnerability in the Java logging package (CVE-2021-4428) This risk posed a severe threat to millions of consumer products from enterprise software to web applications. It presents risk of loss, or breach of personal information, financial loss and irreversible reputation harm. Currently, the FTC is taking action to require organizations to settle any associated risk caused by the known vulnerabilities. The FTC is now noted as using its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposures. 

A recent example of this negligence came on the back of a complaint in regards to Equifax’s failure to patch a known vulnerability which irreversibly exposed the personal identifiable information of 147 million consumers. This resulted in Equifax paying $700 million to settle the actions taken by the FTC and the consumer financial protection bureau. The risk for businesses is therefore clear, take actionable steps to remediate the vulnerability, or face litigation, breach risk and reputation damage.

In this guide, we will walk you through how you can use Method Call Removal to mitigate this vulnerability.

Method Call Removal

Method Call Removal has been available since our DashO 6.11 release.  It is mostly used for removing logging statements, but it can be used to strip any method calls we’d prefer not to have in our production release.  The only caveat is that the method definition must also be in DashO’s input.

Let’s assume Log4j is used for our application’s logging.  We might want to remove all log statements from production builds, then create special debug builds with logging enabled as needed.  Or, we might want to remove Info, Warn, and Debug messages, but retain Error or Fatal message in our production build.  This can be done using DashO’s Method Call Removal feature, without needing to adjust the Log4j configuration.

Please consider the following example:

This application logs informational messages when the app starts, and when it shuts down.  

The Log4J configuration has been organized into a global logging class:

In our DashO project, I’ll select the “LogInfo” method for method call removal:

Graphical user interface, text, application
Description automatically generated

After doing so, the application runs normally, but informational messages are no longer logged to console or written to log file.

After the app has been in production, I may need to create an obfuscated debug build for troubleshooting an issue with a specific client.  If so, I can run DashO without Method Call Removal to preserve logging calls in my debug build.

The above example can be downloaded here.


If you have any feedback on this topic or other topics you would like us to discuss in the Support Corner, please feel free to contact our Support Department.


Categories
101

Dotfuscator 101

Reading Time: 4 minutes

In this blog we will dive into Dotfuscator  as part of our 101 series – we walk you through what Dofuscator for .NET does and how this can help protect your projects. 

For those of you who are in the industry and know how this product protects your code, we appreciate the loyalty! If you are not tech savvy, but want to know a little bit more about this product, here’s our summary:

What is Dotfuscator for .NET?

Dotfuscator – by definition is a multi-functional tool that combines obfuscation, optimization while shrinking your source code, on .NET, Xamarin and Windows Platform Apps. Basically this jumbles, encrypts your code, hardening it to prevent theft. 

How does Dotfuscator work?

PreEmptive Dotfuscator for .Net provides many layers of protection for .NET users with multiple forms of obfuscation. We like to describe this as constructing the perfect sandwich.

  • First we start with the bread, in this case we will call it Renaming. Renaming obfuscation alters the variables and methods making it difficult to read or scan over to gain access to the certain parts of your source code. However, we go a little further by making things extra difficult for the typical hacker by utilizing Overload Induction™. This renames as many methods as possible to the same name instead of changing one variable one by one. To say this least – this is what makes the “bread” harden at surface level.
  • Then add the veggies: lettuce (Control Flow) and tomato (String Encryption). Control Flow uses advanced obfuscation by falsifying conditional statements. Basically it destroys the code patterns that decompilers use to recreate source code resulting in spaghetti logic to confuse anyone who tries to crack the code. Adding the tomato to this (String Encryption), hides all the strings that are present in the user’s assembly. To better explain, the typical hacker will locate string references inside the binary. Usually if the application is time sensitive, a message will pop up when time has expired – this is exactly what hackers search for inside the decompiled output indicating that they are VERY close to stealing your algorithm. Dotfuscator directly addresses this issue by allowing the user to encrypt strings in the most vulnerable part of the source code. 
  • Now comes the choice of meat (Watermarking, Pruning, Linking-Assembly Merging). Watermarking helps track unauthorized copies of the user’s project by embedding copyright information directly into .NET applications without jeopardizing runtime behavior. Pruning takes the work out for you by removing unused types, methods, fields, debugging information and non-essential metadata from a MSIL file all while processing. Dotfuscator Linking-Assembly Merger combines multiple input assemblies into one or more output assemblies – meaning it shrinks your application down alongside pruning and renaming. 
  • Next is the cheese (Tamper Detection & Defense). Dotfuscator injects code that verifies your application’s integrity during runtime and if it detects tampering, it will shut down the application, invoking random crashes. Now that’s an excellent choice of cheese! 
  • Last but not least are the condiments: mayo (Debug Detection) and mustard (Defense Using Checks). These two are prebuilt into Dotfuscator and can be injected into the .NET apps. This allows your app to detect any unauthorized uses such as debugging or tampering of any sort. Don’t be fooled, checks can do more than just the average scanning, they can react too, for example – exiting the app when tampering is found. 
  • For those who like a little extra to the sandwich, (Shelf Life) is the pickle! Shelf Life is an inventory management function that allows you to embed an expiration date, de-activation, and notification logic to your code! Now this is what we call the ultimate sandwich! 

When should you use Dotfuscator?

Whether you’re a start-up company, freelancer or an organization developing projects using .NET software, you should be using this in the development process – preferably in the beginning stages even after launches. Data breaches are no longer part of the “new normal” they are part of everyday scenarios. If you don’t protect your code from the beginning…you will likely become another data breach statistic.

Where does Dotfuscator work?

Dotfuscator is injected directly into your source code, providing a multi-layered approach by way of in-app hardening; assessing and securing where your code is vulnerable.  

Why should you use PreEmptive Dotfuscator?

PreEmptive Dotfuscator has paved the way in In-App security since 2003, that’s 19 years in the biz! Our clients range from small to large enterprises including many Fortune 500 companies of different industries from medical to government agencies. But if you still need a little more convincing, check out our client list here

For more information on how to get started, download our free trial or need further help, we encourage you to use our resources, found in our navigation bar. We hope this blog has helped you better understand Dotfuscator for .NET. We look forward to our next 101!