Voxxed Days Athens - Securing the JVM - Neither for fun nor for profit, but do you have a choice?

•Download as PPTX, PDF•

0 likes•203 views

The Java API allows a lot: sending packets over the network, compiling code, etc. If you put an application in an production environment, you need to make sure it doesn’t do more than it’s supposed to do. Consider a Java application in a private banking system. A new network administrator is hired, and while going around, he notices that the app is making network calls to a unknown external endpoint. After some investigation, it’s found that this app has been sending for years confidential data to a competitor (or a state, or hackers, whatever). This is awkward. Especially since it could have been avoided. Code reviews are good to improve the hardening of an application, but what if the malicious code was planted purposely? Some code buried in a commit could extract code from binary content, compile it on the fly, and then execute the code in the same JVM run… By default, the JVM is not secured! Securing the JVM for a non-trivial application is complex and time-consuming but the risks of not securing it could be disastrous. In this talk, I’ll show some of the things you could do in an unsecured JVM. I’ll also explain the basics of securing it, and finally demo a working process on how to do it.

Software

HYBRIS, AN SAP COMPANY
@nicolas_frankel #jvm #security
3

REFLECTION API
@nicolas_frankel #jvm #security
5
Part of the JRE
• java.lang.reflect

USED BY A LOT OF
LANGUAGES/FRAMEWORKS
@nicolas_frankel #jvm #security
6
Dynamic languages
• Groovy
JPA frameworks
• Hibernate
• Others
Spring
Etc.

BUT EVERYTHING IS POSSIBLE
@nicolas_frankel #jvm #security
8
Make networks calls
Compile code on the fly
Execute code
Etc.

SAFEGUARDS?
@nicolas_frankel #jvm #security
9
Static analyzers
Byte-code analyzers
Code reviews
Security team
Etc.

STEGANOGRAPHY
@nicolas_frankel #jvm #security
10
”Steganography is the
practice of concealing a file,
message, image, or video
within another file, message,
image, or video”

A SIMPLE PROCESS
@nicolas_frankel #jvm #security
12
1. Publish a new library to central
• With hidden steganographic/compile/run
features
2. Add the library to your POM
3. Add an image with embedded code
4. Call the library
• Pretend to read the image
5. Enjoy

REMEMBER?
@nicolas_frankel #jvm #security
13

APPLETS
@nicolas_frankel #jvm #security
14
Meant to run on the client
machine
• Forbidden to do “dangerous”
stuff
• Run in a sandbox

AVAILABLE MODES
@nicolas_frankel #jvm #security
15
Standard mode
• a.k.a. “God Mode”
Sandbox mode
• Through a SecurityManager

ACTIVATING THE SECURITY MANAGER
@nicolas_frankel #jvm #security
16
On the command line
• java -Djava.security.manager …
Via the API
• System.setSecurityManager()

PERMISSIONS CONFIGURATION
@nicolas_frankel #jvm #security
17
Java 9
• conf/security/java.security
•  conf/security/java.policy
Java 8
• jre/lib/security/java.security
•  jre/lib/security/java.policy

ALTERNATIVE POLICY FILE
@nicolas_frankel #jvm #security
18
Setting the policy file
• -Djava.security.policy==my.policy
Adding additional permissions
• -Djava.security.policy=my.policy

PRINCIPLE OF LEAST PRIVILEGE
@nicolas_frankel #jvm #security
19
“Requires that in a
particular abstraction layer of a
computing environment, every
module must be able to access
only the information
and resources that are
necessary for its legitimate
purpose”

DEFAULT PERMISSIONS
@nicolas_frankel #jvm #security
20
Listen on ports
Read some System
properties

$PERMISSIONS ARE ENFORCED IN THE JDK! public class AccessibleObject implements AnnotatedElement { public void setAccessible(boolean flag) throws SecurityException { SecurityManager sm = System.getSecurityManager(); if (sm != null) sm.checkPermission(ACCESS_PERMISSION); setAccessible0(this, flag); } } @nicolas_frankel #jvm #security 21$

PERMISSIONS
Permission Details
AllPermission 
PropertyPermission • Read
• Write
FilePermission • Read
• Write
• Execute
• Delete
ReflectPermission Suppress reflective access checks
RuntimePermission • More granular reflective access checks
• Security-related
• Class-loading related
• Exit Virtual Machine, shutdown hooks, etc.
@nicolas_frankel #jvm #security
22

PERMISSIONS (CONTINUED)
Permission Details
SocketPermission • accept
• connect
• listen
• resolve
SSLPermission • Get/set SSL context
• Set hostname verifier
AuthPermission
ServicePermission Kerberos-related
AWTPermission • Clipboard
• Tray
• Windows
• Pointer
• etc.
@nicolas_frankel #jvm #security
23

$STRUCTURE OF A POLICY FILE (SIMPLIFIED) grant codebase "file:myjar" { permission Foo "foo"; permission Bar "bar", "baz"; }; @nicolas_frankel #jvm #security 24$

Q&A
@nicolas_frankel #jvm #security
27
http://blog.frankel.ch/
@nicolas_frankel
https://blog.frankel.ch/jvm
-security/1/

Slides from 2018 MacAD.UK confernce Synopsis: https://www.macad.uk/speaker/henry-stamerjohann/ When tasked with (re)building a security baseline for macOS clients, where do you start? There’s obviously decisions to be made about what’s feasible in your organization (beyond if admin privileges should be the default). You need to weigh system stability and security with end-user productivity. Luckily for the macOS platform a rich ecosystem of tools exist to fill in the gaps and general guidance is available. The crucial part of making mindful and informed decisions is to first aggregate data from your IT environment. You can then decide what configurations to deploy and run recurring compliance checks based on an appropriate strategy. This session will cover fundamentals, highlight advanced considerations, and outline practical examples to apply when you’re conducting a (new) baseline for macOS clients.

Kali net hunter

Prashanth Sivarajan

Security Issues in Android Custom ROM

Anant Shrivastava

Elizabeth Lawler - Devops, security, and compliance working in unison

DevSecCon

The document discusses improving security, compliance, and risk management through a DevSecOps approach. It outlines steps such as mapping compliance controls to infrastructure components, categorizing risks, describing controls and mitigations, testing controls, and communicating controls to stakeholders. Automating compliance checks and integrating security practices into development workflows are presented as ways to improve security, compliance, and speed of delivery simultaneously.

Aleksei Dremin - Application Security Pipeline - phdays9

Alexey Dremin

This document discusses setting up an application security pipeline for continuous integration and delivery (CI/CD). It recommends using static application security testing (SAST) tools, dependency checkers, source code scanners, dynamic application security testing (DAST) tools, and integrating them with Jenkins. It also suggests managing vulnerabilities and results in DefectDojo and notifying stakeholders of new findings through integration with communication tools like Slack. The document stresses the importance of educating developers on security best practices.

Basic detection tests of McAfee ENS + MVISION Insights usage for SunBurst threat

Vladyslav Radetsky

On those slides I will show you 7 simple steps to test different McAfee ENS protection mechanism. And as a bonus I will show you how to use MVISION Insights to react on SunBurst threat. List of tests: - OAS AMCore detection - OAS GTI detection - Access Protection - Exploit Prevention - Real Protect (ATP-RP) - Dynamic Application Containment (ATP-DAC) - Credential Theft Protection (ATP-RP-CTP) All tests made for built-in rules and conducted without using real malware, so it is safe to repeat those steps in your environment. #McAfee #MVISION #Insights #SunBurst #SolarWinds #supplychain

CSW2017 chuanda ding_state of windows application security

CanSecWest

This document discusses shared libraries and security vulnerabilities in Windows applications. It describes a system called Project A'Tuin that can automatically install software, detect insecure behaviors, and identify shared libraries used. The system found over 4000 shared libraries in sample applications, including outdated versions of OpenSSL affected by known vulnerabilities. Future work includes expanding behavior detection across platforms and open sourcing the system.

The document discusses security in software development. It outlines the typical software development life cycle of requirements, design, code, test, and deployment phases. For each phase, it notes that security is usually an afterthought rather than being integrated into the process from the beginning. It encourages improving security perceptions, work, and practices at each stage of development. The presenter is Renato Rodrigues, who wants to continue the security conversation on social media.

Перевірка роботи McAfee ENS. MVISION Insights SUNBURST.

Vladyslav Radetsky

Як проводити практичну перевірку роботи захисту ENS, та як MVISION Insights може стати у нагоді у світлі атак на FireEye та SolarWinds. На слайдах відображено наступні тести: - OAS AMCore detection - OAS GTI detection - Access Protection - Exploit Prevention - Real Protect (ATP-RP) - Dynamic Application Containment (ATP-DAC) - Credential Theft Protection (ATP-RP-CTP) Усі тести виконані на базі вбудованих правил та сигнатур _без_ використання реального шкідливого коду. #McAfee #MVISION #Insights #SunBurst #SolarWinds #supplychain

Vulnex app secusa2013

drewz lin

This document outlines a presentation given by Simón Roses Femerling on software security verification tools. It discusses BinSecSweeper, an open source tool created by VulnEx to scan binaries and check that security best practices were followed in development. The presentation covers using BinSecSweeper to verify in-house software, assess a company's software security posture, and compare the security of popular browsers. Examples of plugin checks and reports generated by BinSecSweeper are also provided.

DevSecCon London 2017: Hands-on secure software development from design to de...

DevSecCon

This document promotes secure software development practices and advertises an upcoming security conference. It discusses the speaker's background in security research and hacking competitions. It then outlines some common security issues like weak passwords, SQL injection, and open redirects. To demonstrate secure development, it proposes a hands-on exercise of attacking, fixing, and rewriting the codebase of a sample legacy online spaceflight booking application. The document emphasizes the importance of considering security throughout the entire software development lifecycle from design to deployment. It invites the reader to join the security conference conversation.

Mod Security

Abhishek Singh

ModSecurity is an open source web application firewall started in 2002 by Ivan Ristic. It can be embedded into web applications and servers to provide protection without introducing additional network components. As an embeddable WAF, ModSecurity offers low overhead, scalability, and avoids single points of failure. It monitors traffic in real-time, supports logging for auditing, and can help patch vulnerabilities without requiring application changes. ModSecurity works with Apache and other web servers, and a standalone version is in development.

Nick Drage & Fraser Scott - Epic battle devops vs security

DevSecCon

Fraser and Nick debate the relationship between DevOps and security. Nick argues security is too complex for DevOps approaches, while Fraser argues DevOps and security ultimately have the same goals of reducing risk and increasing value. They propose defining a "risk budget" to measure and manage risk like an "error budget", allowing more frequent deployments if risk is reduced through practices like testing and security engagement. Ultimately they agree DevOps and security need cooperation rather than separation, with security helping scale out practices while DevOps takes security responsibilities.

Nodevember 2015

Adam Baldwin

Node Security Experiments discusses security issues in the Node.js ecosystem. It covers topics like malicious modules hosted on NPM, insecure installation scripts, typosquatting vulnerabilities, password exposure, auditing packages for vulnerabilities, static analysis tools to detect security issues, and challenges of keeping up with the large number of packages. The document also mentions detecting and preventing specific security vulnerabilities, tools for auditing packages like NSP and Retire.js, potential bots in the ecosystem, and challenges with binary modules and exposing vulnerabilities in Node.js core.

Python Web Conference 2022 - Why should devs care about container security.pdf

Eric Smalling

https://2022.pythonwebconf.com/presentations/why-should-developers-care-about-container-security Container scanning tools, industry publications, and application security experts are constantly telling us about best practices for how to build our images and run our containers. Often these non-functional requirements seem abstract and are not described well enough for those of us that don't have an appsec background to fully understand why they are important. In this session, we will: go over several of the most common practices to best containerize Python applications show examples of how your application can be exploited in a container and most importantly, how to easily spot issues and fix your Dockerfiles and deployment manifests before you commit your code

Csw2016 freingruber bypassing_application_whitelisting

CanSecWest

This document discusses bypassing application whitelisting, specifically McAfee Application Control. It presents several methods for bypassing the whitelisting protection, including abusing whitelisted applications like PowerShell to execute arbitrary code. PowerShell scripts from tools like PowerSploit are suggested, which allow executing shellcode and other malicious payloads even when script execution is disabled. The document aims to demonstrate how application whitelisting can be bypassed on Windows systems through leveraging pre-installed applications and applications installed by the whitelisting software itself.

DevOps or DevSecOps

Michelangelo van Dam

In 2009 Patrick Dubois coined the term "DevOps" when he organised the first "DevOpsDays" In Ghent, Belgium. Since then the term has become a term to explain the collaboration between all organisational stakeholders in IT projects (developers, operations, QA, marketing, security, legal, …) to deliver high quality, reliable solutions where issues are tackled early on in the value stream. But reality shows that many businesses that implement "DevOps" are actually talking about a collaboration between development, QA and operations (DQO). Solutions are being provided but lack the security and/or legal regulations causing hard-to-fix problems in production environments. In this talk I will explain how the original idea of Patrick to include all stakeholders got reduced to development, QA and operations and why it's so difficult to apply security or compliance improvements in this model. I will also talk about ways to make the DQO model welcoming for security experts and legal teams and why "DevSecOps" is now the term to be used to ensure security is no longer omitted from the value process. Finally we'll have a vote if we keep the term "DevOps" as an all-inclusive representation for all stakeholders or if we need to start using "DevSecOps" to ensure the business understands can no longer ignore the importance of security.

Browser exploit framework

Prashanth Sivarajan

BeEF (Browser Exploitation Framework) is a penetration testing tool that focuses on exploiting vulnerabilities within the web browser. It works by hooking one or more browsers and using them as entry points to launch attacks against the system from within the browser context. This allows penetration testers to assess the security of a target environment by exploiting client-side vectors rather than just focusing on the network perimeter or hardened systems. BeEF gathers information about hooked browsers and systems, performs network discovery, and has command modules for social engineering, exploits, and maintaining persistence within the browser.

Building Security Controls around Attack Models

SeniorStoryteller

This document discusses building security controls around attack models to enable continuous validation of defenses. It recommends modeling real attack techniques to automatically test each security control as assets are deployed. An example attack on Target is described across stages of initial breach, privilege escalation, access to data stores, and exfiltration. Metrics like detection time and prevention effectiveness are suggested to measure security control performance. Implementing controls informed by relevant attack models is advocated to minimize organizational risk through a data-driven, continuous validation approach.

Slides null puliya linux basics

Anant Shrivastava

This document provides an overview of Linux topics including: 1. It discusses various Linux distributions like Debian, Redhat and file system basics like directories and permissions. 2. It covers important commands like ls, grep, sed and editors like vim. It also summarizes installing software, automation with cronjobs and configuring services like SSH. 3. Finally, it touches on shell scripting basics like variables, conditions and loops to automate tasks. It provides examples of overloading commands and writing custom scripts.

Apache Struts2 CVE-2017-5638

Riyaz Walikar

This document discusses CVE-2017-5638, a remote code execution vulnerability in Apache Struts2. Nike Zheng reported that a bug in the Jakarta Multipart parser used by Struts2 could allow remote code execution by sending a crafted Content-Type header. The vulnerability lies in how Struts2 evaluates OGNL expressions in multipart requests, which can be exploited to execute system commands on the server.

Chaos engineering for cloud native security

Kennedy

Human errors and misconfiguration-based vulnerabilities have become a major cause of data breaches and other forms of security attacks in cloud-native infrastructure (CNI). The dynamic and complex nature of CNI and the underlying distributed systems further complicate these challenges. Hence, novel security mechanisms are imperative to overcome these challenges. Such mechanisms must be customer-centric, continuous, not focused on traditional security paradigms like intrusion detection. We tackle these security challenges via Risk-driven Fault Injection (RDFI), a novel application of cyber security to chaos engineering. Chaos engineering concepts (e.g. Netflix’s Chaos Monkey) have become popular since they increase confidence in distributed systems by injecting non-malicious faults (essentially addressing availability concerns) via experimentation techniques. RDFI goes further by adopting security-focused approaches by injecting security faults that trigger security failures which impact on integrity, confidentiality, and availability. Safety measures are also employed such that impacted environments can be reversed to secure states. Therefore, RDFI improves security and resilience drastically, in a continuous and efficient manner and extends the benefts of chaos engineering to cyber security. We have researched and implemented a proof-of-concept for RDFI that targets multi-cloud enterprise environments deployed on AWS and Google cloud platform.

DevSecCon London 2017: when good containers go bad by Tim Mackey

DevSecCon

This document summarizes Tim Mackey's presentation at DevSecCon. It discusses the importance of security driven development practices like using trusted components, continuous integration processes that include security testing, and digitally signing container images. It warns that while infrastructure teams aim to provide security, vulnerabilities can still exist, and advocates continually evaluating the trust of components used. The document predicts disclosure of security issues will increase and outlines penalties for data breaches under new regulations like GDPR. It emphasizes automating awareness of open source dependencies to keep pace with DevOps.

Testing Android Security Codemotion Amsterdam edition

Jose Manuel Ortega Candel

This document outlines an agenda for testing Android security. It discusses various stages of the development cycle and security testing approaches, including static and dynamic analysis, component security, and best practices. Automatic and hybrid tools are presented for analyzing apps through decompilation, emulation, and network traffic inspection. Specific tools are explained like Android Lint, QARK, Drozer, and SQLCipher. The document concludes with recommendations around permissions, encryption, input validation, and references.

The Dark Side of PowerShell by George Dobrea

EC-Council

PowerShell is now a ‘mandatory-to-use’ tool for IT professionals in order to automate administration of the Windows OS and applications, including Azure and Nano Server. Unfortunately, threat actors have recently taken advantage of this powerful scripting language just because PowerShell it’s already installed on your Windows machines, trusted by Admins and most AntiVirus tools! The session presents the steps that should get you starting on (Ethical) Hacking and Pen Testing with PowerShell and some new techniques like JEA (Just Enough Administration) that a defender can use in order to limit the effectiveness of PowerShell attacks.

Eliz seminar

henelpj

This document provides an introduction and overview of the Kali Linux operating system and the Armitage tool. It discusses how Kali Linux is a Debian-based distribution for penetration testing and security auditing. It then describes Armitage as a scriptable red team collaboration tool for Metasploit that visualizes targets, recommends exploits, and exposes post-exploitation features. Finally, it provides steps for initializing and implementing Armitage in Kali Linux.

DevSecCon Tel Aviv 2018 - End2End containers SSDLC by Vitaly Davidoff

DevSecCon

This document discusses securing the software development lifecycle (SDLC) when using containers. It begins with an introduction to SDLC models like waterfall and agile. It then covers challenges in applying application security with containers, including unclear boundaries and responsibilities. The main body details how to apply security practices at each phase of the SDLC for containers: requirements, design, implementation, testing, and operations. Key practices include threat modeling, secure coding, image validation, and monitoring. It concludes with emphasizing the importance of involving security champions throughout the process.

JUG Saxony Day - Securing the JVM, not for fun not for profit but what choice...

Voxxed Days Athens - Securing the JVM - Neither for fun nor for profit, but do you have a choice?

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Voxxed Days Athens - Securing the JVM - Neither for fun nor for profit, but do you have a choice?

Similar to Voxxed Days Athens - Securing the JVM - Neither for fun nor for profit, but do you have a choice? (20)

More from Nicolas Fränkel

More from Nicolas Fränkel (20)

Recently uploaded

Recently uploaded (20)

Voxxed Days Athens - Securing the JVM - Neither for fun nor for profit, but do you have a choice?