FireWall-1 has vulnerabilities in its authentication protocols that allow unauthorized commands to be issued. The protocols do not properly verify IP addresses or use strong authentication methods like cryptographic signatures. This allows attackers to bypass authentication by spoofing IP addresses or replaying captured authentication values. The document recommends configurations and protocols to strengthen authentication and prevent these attacks.
Cryptography Processing with 3rd Gen Intel Xeon Scalable ProcessorsDESMOND YUEN
Cryptographic operations are amongst the most compute intensive and critical operations applied to data as it is stored, moved, and processed. Comprehending Intel's cryptography processing acceleration is essential to optimizing overall platform workload, and service performance.
CCNA Security 210-260 Official CCNA Security 210-260 Official Cert Guide is a best Cisco exam study guide that focuses specifically on the objectives for the CCNA Security Implementing Cisco Network Security (IINS) 210-260 exam.https://www.pass4sureexam.com/210-260.html
By Nir Solomon, Yoav Francis and Liahav Eitan
Abstract:
One of greatest applicative benefits of SDN is enhancement of network security by making the network react to threats in real-time using data from all the switches in the network. For example, the OpenFlow Controller (OFC) can identify a DDoS attack on the network and divert or block traffic in an adaptive manner.
Unfortunately, OpenFlow also introduces a new threat to network security – attacks on the OFC itself, the “soft-belly” in regards to network security in SDN. The controller, by being responsible for multiple switches, is a `high-valued` target (a single point-of-failure), and we aim to understand better its vulnerability to DDoS attacks.
DDoS on the OFC can affect the entire network in several ways, depending on the OpenFlow Applications in the network and the level of dependency of the OF Switches on the OFC:
1. The entire network might be slowed down and suffer from packet-loss.
2. Some packets might be handled normally while others are mishandled by switches in the network, depending on the OpenFlow Applications that apply to these packets and whether they require communication with the OFC.
3. The entire network might stop functioning.
All of the above share a unique property that does not apply in ordinary DDoS attacks: even if only one or two switches are being flooded, the entire network can be affected.
Cryptography Processing with 3rd Gen Intel Xeon Scalable ProcessorsDESMOND YUEN
Cryptographic operations are amongst the most compute intensive and critical operations applied to data as it is stored, moved, and processed. Comprehending Intel's cryptography processing acceleration is essential to optimizing overall platform workload, and service performance.
CCNA Security 210-260 Official CCNA Security 210-260 Official Cert Guide is a best Cisco exam study guide that focuses specifically on the objectives for the CCNA Security Implementing Cisco Network Security (IINS) 210-260 exam.https://www.pass4sureexam.com/210-260.html
By Nir Solomon, Yoav Francis and Liahav Eitan
Abstract:
One of greatest applicative benefits of SDN is enhancement of network security by making the network react to threats in real-time using data from all the switches in the network. For example, the OpenFlow Controller (OFC) can identify a DDoS attack on the network and divert or block traffic in an adaptive manner.
Unfortunately, OpenFlow also introduces a new threat to network security – attacks on the OFC itself, the “soft-belly” in regards to network security in SDN. The controller, by being responsible for multiple switches, is a `high-valued` target (a single point-of-failure), and we aim to understand better its vulnerability to DDoS attacks.
DDoS on the OFC can affect the entire network in several ways, depending on the OpenFlow Applications in the network and the level of dependency of the OF Switches on the OFC:
1. The entire network might be slowed down and suffer from packet-loss.
2. Some packets might be handled normally while others are mishandled by switches in the network, depending on the OpenFlow Applications that apply to these packets and whether they require communication with the OFC.
3. The entire network might stop functioning.
All of the above share a unique property that does not apply in ordinary DDoS attacks: even if only one or two switches are being flooded, the entire network can be affected.
LAN to LAN VPN also known as Site to Site VPN is the most basic and the most simplest of all the VPN’s used on CISCO devices. It helps in connecting networks in different geographical location.
XPDDS17: Introduction to Intel SGX and SGX Virtualization - Kai Huang, IntelThe Linux Foundation
In era of cloud computing, security is becoming more and more critical for customers. In existing HW/SW architecture hypervisor does not protect tenants against the cloud provider and thus the supplied operating system and hardware. Intel Software Guard Extension (SGX) provides a mechanism that addresses this scenario. It aims at protecting user-level software from attacks from other processes, the operating system, and even physical attackers. Intel SGX makes such protection possible through the use of enclave, which is a protected area in userspace application where the code/data cannot be accessed directly by any software from outside. This presentation intends to give you an introduction of Intel SGX technology, including what it is, how it works, and the existing SW stack to enable SGX for customers, followed by introduction of our work to support SGX virtualization in Xen hypervisor, including the high-level design, current status and future plan.
IPsec provides the capability to secure communications across a LAN, across private and public WANs, and across the Internet. Examples of its use include:
Secure branch office connectivity over the Internet
Secure remote access over the Internet
Establishing extranet and intranet connectivity with partners
Enhancing electronic commerce security
The New Landscape of Airborne CyberattacksPriyanka Aash
A virus-like cyberattack spreading over the air may sound far-fetched, but new research proves the airborne attack surface is here. Join the Armis researchers who discovered the viral IoT vulnerability, BlueBorne, as they walk through the airborne threat landscape, its risks and tips for tackling them, and for a live demo of an attack using the BlueBorne vector.
Learning Objectives:
1: Understand the airborne attack vector, its threats and consequences of attacks.
2: Observe a live demo of an airborne attack and review existing exploits.
3: Obtain practical advice for reducing the airborne attack surface.
(Source: RSA Conference USA 2018)
Three new attacks are described. The first is a Denial of Service attack capable of halting all traffic for one minute by injecting only two frames. The second attack allows the injection of arbitrary many packets towards a client. It is shown that this can be used to perform a portscan on any TKIP-secured client. The third attack reset the internal state of the Michael algorithm, allowing an attack to append any (encrypted) TKIP packet with invalidating the MIC. This can be used to decrypt arbitrary packets sent towards the client.
LAN to LAN VPN also known as Site to Site VPN is the most basic and the most simplest of all the VPN’s used on CISCO devices. It helps in connecting networks in different geographical location.
XPDDS17: Introduction to Intel SGX and SGX Virtualization - Kai Huang, IntelThe Linux Foundation
In era of cloud computing, security is becoming more and more critical for customers. In existing HW/SW architecture hypervisor does not protect tenants against the cloud provider and thus the supplied operating system and hardware. Intel Software Guard Extension (SGX) provides a mechanism that addresses this scenario. It aims at protecting user-level software from attacks from other processes, the operating system, and even physical attackers. Intel SGX makes such protection possible through the use of enclave, which is a protected area in userspace application where the code/data cannot be accessed directly by any software from outside. This presentation intends to give you an introduction of Intel SGX technology, including what it is, how it works, and the existing SW stack to enable SGX for customers, followed by introduction of our work to support SGX virtualization in Xen hypervisor, including the high-level design, current status and future plan.
IPsec provides the capability to secure communications across a LAN, across private and public WANs, and across the Internet. Examples of its use include:
Secure branch office connectivity over the Internet
Secure remote access over the Internet
Establishing extranet and intranet connectivity with partners
Enhancing electronic commerce security
The New Landscape of Airborne CyberattacksPriyanka Aash
A virus-like cyberattack spreading over the air may sound far-fetched, but new research proves the airborne attack surface is here. Join the Armis researchers who discovered the viral IoT vulnerability, BlueBorne, as they walk through the airborne threat landscape, its risks and tips for tackling them, and for a live demo of an attack using the BlueBorne vector.
Learning Objectives:
1: Understand the airborne attack vector, its threats and consequences of attacks.
2: Observe a live demo of an airborne attack and review existing exploits.
3: Obtain practical advice for reducing the airborne attack surface.
(Source: RSA Conference USA 2018)
Three new attacks are described. The first is a Denial of Service attack capable of halting all traffic for one minute by injecting only two frames. The second attack allows the injection of arbitrary many packets towards a client. It is shown that this can be used to perform a portscan on any TKIP-secured client. The third attack reset the internal state of the Michael algorithm, allowing an attack to append any (encrypted) TKIP packet with invalidating the MIC. This can be used to decrypt arbitrary packets sent towards the client.
DEF CON 23: Internet of Things: Hacking 14 DevicesSynack
DEF CON 23
Internet of Things: Hacking 14 Devices
It is easy to find poorly designed devices with poor security, but how do the market leading devices stack up? Are they more secure than a Linux-powered rifle? This presentation documents our effort to assess the state of security of top selling Internet of Things Devices.
We procured 14 of the leading “connected home” IoT devices and tore them down, all the way from software to hardware and compared their relative security. This talk will demonstrate techniques useful for assessing any IoT device, while showing how they were applied across a wide range of devices.
Attend for stories of device rooting, SSL interception, firmware unpacking, mobile app vulnerabilities and more. Stay to find out why your favorite new gadget might just be a backdoor into your home. If you own (or are considering buying) one of the following devices, come and find out how secure it actually is!
Devices:
Dlink DCS-2132L
Dropcam Pro
Foscam FI9826W
Simplicam
Withings Baby Monitor
Ecobee
Hive
Honeywell Lyric
Nest Thermostat
Nest Protect
Control4 HC-250
Lowes Iris
Revolv
SmartThings
Samsung Smart Refrigerator (model RF28HMELBSR)
Samsung LED Smart TV (model UN32J5205AFXZA)
REASON:
The best thing about this talk is that it covers a large number of devices, all devices which are among the industry leaders for their category.
While we have published the high level findings from assessing these devices, this talk will include full technical details on how to attack each of these devices, and full tech details on any of the vulns which we found. Those details have not yet been released, and will be of interest to anyone who owns or wants to hack any of these devices.
Hack WiFi on windows,
Here all slides give you information about ho to hack WiFi step by step,
So please Like share and follow me for new hacking information for you.
Thank you
More and more IoT vulnerabilities are found and showcased at security events. From connected thermostats to power plants!
Insecurity became the favorite subject for creating catchy IoT headlines: "Connected killer toaster", "Fridges changed into spamming machines","Privacy concerns around connected home".
We will explore the five challenges one has to face when building a secure IoT solution:
- hardware security: how to avoid rogue firmwares and keep your security keys safe?
- upgrade strategy: you can't secure what you can't update!
- secure transport: no security without secure transports.
- security credentials distribution: how to distribute security keys to a fleet with millions of devices?
- cloud vulnerability mitigation, how to keep your fleet of devices safe from the next Heartbleed?
Current enterprise infrastructure provides solutions for handling application security but are they really matching the IoT challenge? Could running a PKI client on a low power wireless sensor node be an option?
Despite those difficulties, we will show how a modern IoT device management standard like Lightweight M2M with DTLS is the way for building a secur-first IoT solutions. It provides a solution for upgrading your device, distributing your security keys and comes with a full range of cryptography cipher suites, from PSK algorithm for very constrained devices to high level of security using X.509 certificates.
Furthermore for adding security to your solution we will present you ready to use opensource libraries for implementing secure IoT servers and devices. The way for quickly releasing your next catchy connected product.!
Ultimately we will showcase Wakaama and Leshan, the Eclipse IoT Lightweight M2M implementation maybe your next best friend in the troubled water of Internet-Of-Things security!
How to Hack WPA/WPA2 Wi Fi with Kali Linux. Kali Linux can be used for many things, but it probably is best known for its ability to penetration test, or “hack,” WPA and WPA2 networks.
Warning..!! WIFI hacking is illegal. "This ppt is only for educational purposes. I am not responsible for any consequences."
My keynote on hacker culture, from a personal perspective. Updated in 2014.
Presented at MHacks, the world's largest student hackathon, hosted at the University of Michigan in 2013.
Keynote for the national HKN (Eta-Kappa-Nu) Student Leadership Conference in Feb 2016, discussing the ethics of responsibility in engineering, from my personal history in information security.
Duo fan mail from the front desk of the Marriott Residence Inn in Ann Arbor, Feb 2018
The MLK Day email she references: https://docs.google.com/document/d/e/2PACX-1vTgcpb2rtY316jKfkJk_2fkSPRZ_EQETgPrLUdjkKNtIOS4uy3U8JRdXHBa-vzpQK8uDlX8rxn4ekax/pub
Nidsbench - Network Intrusion Detection Test SuiteDug Song
nidsbench - A network intrusion detection system test suite - RAID99 Conference
Nidsbench is a lightweight portable toolkit for testing network intrusion detection systems. It implements several well-known attacks against passive network monitoring and allows for the instrumentation of trace-driven network attack simulations.
Ann Arbor Startup Community Development H1'09Dug Song
a review of the last 6 months of grassroots tech / startup community organizing in Ann Arbor, MI.
from the July 2009 Ann Arbor New Tech Meetup http://a2newtech.org/calendar/10715802/
cover photo: http://www.flickr.com/photos/mightyboybrian/3596888010/
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
To Graph or Not to Graph Knowledge Graph Architectures and LLMs
A Stateful Inspection of Firewall-1 (2000)
1. A Stateful Inspection of FireWall-1
Thomas Lopatic, John McDonald
TUV data protect GmbH
{tl,jm}@dataprotect.com
Dug Song
Center for Information Technology Integration
University of Michigan
dugsong@monkey.org
August 15, 2000
1 Introduction however, SecuRemote clients use port 264/tcp, with
access to 256/tcp restricted.
At the Black Hat Briefings 2000, we presented an While only the management console is able to is-
analysis of Check Point FireWall-1 vulnerabilities sue unload commands, the binary load (bload) com-
resulting from protocol design flaws, problems in mand is enabled by default for any IP address that
stateful inspection, common or default misconfig- the filter module knows an authentication secret for.
urations, and minor implementation errors discov- We were able to verify this under version 4.0 by
ered over the past few months in the lab, and veri- using binary load to upload an “allow all” policy.
fied in real-world penetration tests. Our attacks bypass authentication to issue an un-
In this advisory, we summarize our findings and load command, which is easier to implement, and
provide some recommendations for safe configura- more portable between versions.
tion. It is intended to complement our presentation
slides and source code, available at:
2.1 IP Address Verification
http://www.dataprotect.com/bh2000/ In the inter-module authentication protocol, a filter
module does not verify the source IP address of an
Our research was conducted against a Nokia IP440 authenticating management module by checking the
running FireWall-1 version 4.0 Service Pack 5. peer address of a connection – it examines a list of IP
Check Point later provided us with version 4.1 Ser- addresses handed to it. A common misconfiguration
vice Pack 1, which was still vulnerable to most of is to put
our attacks, but came with a much safer default
configuration. Check Point has since released ser- 127.0.0.1: */none
vice packs for all supported versions of FireWall-1 to
specifically address the vulnerabilities documented in the control.map file, to ease local administra-
here. tion. An attacker only needs to send 127.0.0.1 as
her IP address to bypass authentication completely,
as demonstrated by our “fw1none” program.
2 Authentication After exchanging version and IP address informa-
tion, the filter module replies with the authentica-
In the examination of any security product, the ad- tion it wants to be performed. Upon successful au-
ministrative control channels are often the weakest thentication, the management module transmits the
link – and the most security critical. Indeed, we arguments for the command to be executed. Finally
found that FireWall-1, in a typical distributed de- the filter module returns a status code to indicate
ployment, was susceptible to several trivial attacks whether or not command execution was successful.
against its inter-module authentication protocols. The protocol is in general not strictly syn-
Our attacks assume that the attacker has access chronous. In particular, the exchange of IP ad-
to port 256/tcp on the filter module, and knows the dresses happens asynchronously, i.e. the manage-
IP address of either a management module or any ment module does not have to send its IP addresses
peer for which a shared authentication secret has first. It could just wait for the filter module to send
been configured using “fw putkey.” In version 4.0, all IP addresses and then transmit its own. In this
this port is exposed to the world by default, as it way, an attacker acting as a management module
is also used by SecuRemote clients. In version 4.1, may learn all IP addresses of the firewall without
1
2. actually authenticating. This is useful for the en- knows K, is able to verify the signature by calculat-
capsulation attacks discussed later, or in discovery ing the same keyed hash.
of a management module’s IP address. The original value for K is set using “fw
If we present an IP address to the filter module putkey.” However, after the first authentication, a
that does not correspond to a management module Diffie-Hellman key exchange is initiated, resulting
– or more generally speaking, an IP address that in a new shared 1024 bit secret K for authentication.
it does not have an authentication secret for – it
will simply refuse to authenticate. Hence we can The FWN1 protocol works as follows:
scan for the correct IP address of the management
module by connecting repeatedly, giving a different 1. The filter module generates a random number
IP address (or list of IP addresses) each time. R1.
2. The filter module signs R1. The signature S1
2.2 S/Key = Hash(R1 + K), where ’+’ denotes concate-
S/Key authentication [Ha95] is used when commu- nation.
nicating with embedded FireWall-1 devices. It is 3. R1 and S1 are sent to the management module.
also the fallback for version 4.0 filter modules that
do not have an encryption license and thus do not 4. The management module verifies S1.
support FWA1.
The problem with Check Point’s S/Key imple- 5. The management module generates a random
mentation is that after a shared secret has been used number R2.
for 99 iterations, the management module gener- 6. The management module calculates the corre-
ates a new authentication secret using time(). The sponding signature S2 = Hash(R1 + K), where
time() function has a resolution of seconds. There- ’+’ is concatenation again.
fore, there are only 24 * 3600 = 86400 different pos-
sibilities for secrets generated on a single day. Even 7. R2 and S2 are sent to the filter module.
worse, if the status of the filter module is polled pe-
riodically every 10 seconds, 99 authentications will 8. The filter module verifies S2.
be performed in a maximum 990 seconds. Working
This protocol is trivially defeated by a simple replay
back from current time, we just have to try each
attack. Instead of generating our own R2, we can
of the 990 possible values in the period from now
just reuse the value R1 sent by the filter module.
to 990 seconds ago, because we can be sure that a
Then, we can also reuse the signature S1, instead of
new shared secret has been generated at least once
having to generate our own S2.
during this period.
Our “fw1fwn” utility implements the unload com-
With our S/Key brute forcing program “fw1bf,”
mand with FWN1 authentication.
we are able to perform about 50 guesses per second
There is no encryption with FWN1 authentica-
against FireWall-1 4.0 by using parallel connections,
tion. Neither are there any provisions for data in-
covering a whole day of possible authentication se-
tegrity. Internal threats like TCP connection hi-
crets in less than half an hour. Version 4.1 does not
jacking apply [Be89].
support as many parallel connections, reducing our
effective rate by an order of magnitude.
The S/Key authentication secret, once recovered, 2.4 FWA1
may be used with our “fw1skey” tool to issue an FWA1 is similar to FWN1, with the addition of en-
unload command to the filter module. cryption to the communication between the mod-
There is no encryption with S/Key authentica- ules. This is the default mechanism used in version
tion. Neither are there any provisions for data in- 4.1, and for most commands in version 4.0 when an
tegrity. Internal threats like TCP connection hi- encryption license is present.
jacking apply [Be89]. Again, there is a shared secret K, initially
set using “fw putkey.” After the first successful
2.3 FWN1 authentication, it is replaced by a 1024 bit value
resulting from a Diffie-Hellman key exchange.
FWN1 is an alternative to S/Key, sometimes used at
sites lacking an encryption license for version 4.0 fil-
The FWA1 protocol works as follows:
ter modules. It is the default authentication method
for OPSEC in version 4.0 and version 4.1. 1. The filter module generates a random number
Authentication is based on a shared secret K. This R1.
secret is needed to sign data using a keyed hash. K
is appended to the data and the result is fed to a 2. The filter module signs R1. The signature S1
cryptographically secure hash function. The result- = Hash(R1 + K), where ’+’ denotes concate-
ing digest is used as a signature. The peer, who also nation.
2
3. 3. R1 and S1 are sent to the management module. a connection between two modules by simply XOR-
ing the ciphertext C with a corresponding bit mask
4. The management module verifies S1. X, since the decrypted plaintext P = C ˆ K, where
5. The management module generates a random K is the key stream and ’ˆ’ denotes XOR. Decryp-
number R2. tion of C ˆ X would thus yield (C ˆ X) ˆ K = (C ˆ
K) ˆ X = P ˆ X.
6. The management module calculates R3 = R1
ˆ R2, where ’ˆ’ denotes XOR.
7. The management module calculates the corre-
3 Packet Filtering
sponding signature S2 = Hash(R3 + K), where Static packet filtering is perhaps the simplest mech-
’+’ is concatenation again. anism for network access control, but also decep-
8. R2 and S2 are sent to the filter module. tively hard to implement correctly [Ch92]. We
found FireWall-1 to be susceptible to a number of
9. The filter module verifies S2. attacks based on incomplete input verification, in-
cluding some that allowed for attacks against state-
Hence, the only change from FWN1 authentication ful inspection as well.
is that instead of signing R2, the management mod-
ule signs R3 = R1 ˆ R2. Again, this protocol is
trivially defeated with a simple replay attack. We 3.1 TCP Fastmode
just choose R2 to be zero. In this way R3 = R1 ˆ
FireWall-1 provides a mechanism known as “fast-
R2 will yield R3 = R1 and we can again reuse the
mode” to allow an administrator to designate cer-
filter module’s signature.
tain services as being performance critical. The
The “fw1fwa” utility implements FWA1 authen-
FireWall-1 kernel module simply passes packets that
tication. However, the unload command cannot be
have a source or destination port of a fastmode ser-
issued, as encryption is used to protect the commu-
vice without any additional connection or rule base
nication channel.
checking.
We have simplified our presentation of the FWN1
and FWA1 authentication algorithms a bit for the Additionally, in fastmode, only SYN packets are
sake of clarity. In practice, only 64 of the 128 bits verified. This allows an attacker to pass non-SYN
of the signature are transmitted. In FWA1 the re- TCP packets through the firewall to map the net-
maining 64 bits of S1 and S2 are concatenated to work by setting the source port of her packets to
form the 128 bit encryption key. Since S1 = S2 that of the fastmode service. We demonstrated
in our attack, we would have to guess the 64 bit mapping a network using the -g and -sF options
encryption key to successfully issue an unload com- in nmap [Fy97].
mand. There may still be a more sophisticated and
practical way which has yet to be investigated. 3.2 FWZ Encapsulation
If the shared 1024 bit secret generated by the
Diffie-Hellman key exchange turned out to be guess- FireWall-1’s simple tunneling protocol for SecuRe-
able by a practical brute force attack because of a mote connections proves extremely useful in boot-
lack of entropy, we would perhaps be able to find strapping insertion attacks against stateful inspec-
a relatively small set of candidate values for K by tion. This protocol (FWZ tunnelling via IP protocol
brute forcing based on R1 and S1. Then we could 94) is decapsulated at the very beginning of pre-
try all candidate values for K to find the real K. To inspection, before any real analysis is performed.
identify the real K, we could use the known plain- The decapsulated packet is then fed through the in-
text of the “authentication successful” reply that we spection process. It is not necessary to authenticate
receive, which is already encrypted. or encrypt packets in order to use this encapsulation
To date, we have not come up with a practical protocol. Furthermore, we could find no way to dis-
attack on the complete FWA1 protocol, including able this functionality, short of filtering IP protocol
encryption. Still, the authentication mechanism is 94 with another device.
seriously broken. An ordinary IP packet is FWZ encapsulated as
FWA1 uses the proprietary stream cipher FWZ1, follows: the original destination IP address and pro-
recently posted anonymously to the Usenet sci.crypt tocol are appended as a trailer to the end of the
newsgroup. Unfortunately, even a simple command packet, and replaced in the original header by the
like unload needs at least 18 bytes of arguments. target IP address (one of the firewall’s interfaces)
Moreover, a different key is used in either direction, and IP protocol 94. The trailer, five bytes in length,
confounding any known plaintext attack against the is obfuscated via XOR with a keyed hash on the
“authentication successful” reply. IP ID. While we didn’t recover the key used in the
There are no provisions for data integrity in hash, our tools cheat by fixing the IP ID to one and
FWA1. Internal attackers are able to flip bits in XORing against a static hash.
3
4. In this manner, FWZ encapsulation may be used 4.1 FTP Data Connections
to send packets through the firewall that would oth-
4.1.1 FTP PORT
erwise be unroutable, such as packets from the DMZ
or intranet to the Internet, packets destined for a FireWall-1’s FTP processing tries to restrict the
multicast address, or packets to addresses behind destination of FTP data connections to the FTP
NAT or on RFC 1918 private networks. client associated with the control connection, pre-
venting the classic FTP bounce attack. In previous
versions of FireWall-1, this was trivially bypassed
3.3 IP Spoofing Protection by splitting up the PORT command over multiple
IP spoofing protection on FireWall-1 is configured packets, or even by spelling “PoRT” in mixed case
per network object at the interface level. Several for version 3.0. However, with the latest checks im-
options are possible, but the typical configuration posed by FireWall-1 to restrict one FTP command
looks something like this: to a packet, bypassing this becomes a little more
difficult.
1. DMZ and intranet interfaces set to “This Net” In our presentation, we demonstrated an ambigu-
ity in the parsing of the PORT command that allows
or perhaps “This Net +”, restricting valid
source IP addresses on the interface to those us to bypass this restriction. FireWall-1 takes each
directly on its network, or routable to its net- octet of the presented IP address as a long integer,
work. shifts it the appropriate number of bits and then
adds it to its notion of the IP address. However,
2. External interface set to “Others”, disallowing the FTP server we targeted on Solaris 2.6 interprets
packets purporting to originate from any of the each octet of the IP address modulo 256. This dif-
DMZ or intranet networks. ference allows us to trick the firewall into believing
the connection is destined for the correct client IP,
while the FTP server believes the connection is des-
While this configuration seems simple enough, it
tined for itself.
leaves out spoofing protection for one important IP
The attack we demonstrated was against the
address – the external interface of the firewall. De-
ToolTalk RPC daemon. We uploaded two files to
nial of spoofed packets coming from firewall inter-
the FTP server in a publicly writable directory, and
faces is apparently enabled by default in all versions
then instructed the FTP daemon to upload those
of FireWall-1 other than version 4.1 Service Pack
files to its own ToolTalk daemon port with a care-
1. Coupled with the default rule to allow ISAKMP
fully crafted PORT command. The first file was nec-
packets, this hole allows an attacker to send any
essary to kill the daemon, and the second file was
UDP datagram to the external firewall interface.
the buffer overflow, as generated by the ToolTalk
Another possibility for evading IP spoofing pro-
exploit by apk.
tection is to use the all-hosts multicast address
We also demonstrated utilizing FWZ encapsu-
(224.0.0.1) as a mechanism for delivering packets
lation to spoof a FTP control connection packet
to the underlying operating system of the firewall.
from our victim machine to our attacking computer.
For our demonstration, we used FWZ encapsulation
The payload of this packet was a PORT command,
to spoof a packet from the multicast address to our
which the firewall’s FTP stateful inspection mod-
attack host, allowing us to respond with a packet
ule interpreted as a legitimate data connection that
sent to the multicast address, passed on to the fire-
needed to be passed through the firewall.
wall itself. This attack can also be performed with
broadcast addresses.
4.1.2 FTP PASV
We originally intended to disclose this attack at our
4 Stateful Inspection presentation, but it was independently discovered
and published by Mikael Olsson to VULN-DEV.
Stateful inspection firewalls try to enforce certain This vulnerability can be referenced under CVE-
semantics in the traffic they relay. The mechanisms 2000-0150 [CBHM99].
used to accomplish this, however, are often incom- FireWall-1 violates a basic layering abstraction in
plete or subject to simple insertion or evasion, bear- its inspection of TCP application data within dis-
ing some similarity to the problems encountered in crete IP packets, allowing for a simple insertion at-
passive network monitoring [PN98]. tack. We can leverage the quoting of client input
FireWall-1’s stateful inspection is vulnerable in in an FTP server’s error messages and the client-
a number of ways related to layering violations in side configuration of TCP connection parameters to
inspection, and ambiguity in end-to-end semantics. trick the firewall into allowing arbitrary data con-
Many of these attacks rely on misconfiguration of nections for PASV replies we generate ourselves.
IP spoofing protection, or leveraging other mecha- To demonstrate, we used our “ftp-ozone” tool to
nisms, such as FWZ encapsulation, for insertion. open up a direct connection to the ToolTalk daemon
4
5. on the FTP server, allowing us to execute a buffer pending table is replaced with a new one, contain-
overflow attack. ing the source IP address, the error port (extracted
from the TCP payload), the destination IP address,
4.2 Simplex TCP Connections the same magic number, and the IP protocol. Upon
intercepting the first SYN for an error connection,
A connection in FireWall-1’s connection table may the firewall checks its parameters against the entry
be flagged to restrict data flow to one direction in the pending table, and adds the connection to the
(One-Way versus Either-Way). The first packet connections table.
containing TCP data establishes the direction of An exploitable collision exists in the use of the
the connection, and any data travelling in the other pending table. If we provide an initial sequence
direction will cause the connection to be dropped number of five, it is incremented to six in the pend-
from the connections table. In versions of FireWall- ing table – identical to the entry created by the first-
1 prior to 4.1, the check for data only considered packet handling code. Thus, by spoofing a SYN
the first fragment in a series of fragmented pack- from an intranet or DMZ machine with an ISN of
ets. Thus, it was possible to bypass this restriction five, with the source port of the host that we wish
by sending a TCP data packet in two IP fragments to access, the destination IP address of our attack-
– the first containing the TCP header, the second ing machine, and the destination port of the RSH
containing data (a variation on the tiny fragment service, an entry is added to the connections ta-
attack against static packet filters [ZRT95]). ble allowing us to connect from our machine to the
Check Point corrected this in the latest version, “RSH client” on whatever port we specify.
but there is still another way to bypass it. It is im- In version 4.1, the problem is not exploitable due
portant to note that the firewall does not attempt to the fact that the initial SYN packet is not passed,
to tear down the connection; it only removes its as certain additional flags are missing from our man-
entry in the connection table and drops any subse- ufactured pending table entry.
quent packets. As FireWall-1 doesn’t verify TCP se-
quence numbers [Ro00], it is possible to re-establish
the connection with the same source and destina- 4.4 UDP Replies
tion parameters, allowing for retransmission of the A default installation of FireWall-1 4.0 allows DNS
previously dropped TCP data to set a new direction traffic between all hosts. When combined with lax
for the connection, passing the data back through IP spoofing protection, this rule allows us to spoof
the firewall. To exploit this, a small program run- UDP datagrams from the DMZ or intranet to our
ning in an infinite loop that constantly re-opens the attacking machine. If UDP responses are allowed,
FTP data connection can be used to leak the return we can reply to those packets – in effect allowing us
data through, although somewhat inefficiently. to talk to any UDP service behind the firewall.
Our demonstration consisted of an attack against
4.3 RSH stderr the SNMP daemon on the target Solaris 2.6 ma-
chine. Using the “tun” tool, we sent an FWZ en-
RSH is another protocol that permits an insertion capsulated datagram to the external interface of
attack to allow back-connections through the fire- the firewall, which upon decapsulation, appeared to
wall, in the same manner as the previous FTP originate from the SNMP service on the internal vic-
PORT exploit. This requires a legitimate RSH tim, destined for our attacking host’s port 53/udp.
client inside the firewall, with the firewall config-
This allowed us to respond to our “DNS request”
ured to allow RSH/REXEC stderr connections (a
with arbitrary packets destined for the target’s port
simple policy box check, without any rules required
161/udp. It would follow that our source port
for RSH in the rulebase).
should be 53/udp, but this isn’t actually necessary
RSH stderr connection handling also presents a
because of the way UDP replies are implemented.
problem in its management of connection state. Al-
though we are unable to exploit this vulnerability
in versions 4.1 and later, we decided to leave discus- 5 Recommendations
sion of it in our presentation as it nicely illustrates
some of the state-tracking mechanisms FireWall-1 5.1 Non-reliance on NAT
uses internally.
When FireWall-1 sees the first SYN of an RSH or As mentioned above, FWZ encapsulation can be
REXEC connection, it records the source address, used to send packets through the firewall that would
source port, destination address, a magic number, otherwise be unroutable. This includes packets des-
and the TCP sequence number + 1 into the pend- tined to addresses behind NAT or on RFC 1918 pri-
ing table. It records this information so that it can vate networks. For instance, in FireWall-1’s default
recognize the first packet of the connection that con- configuration, an attacker can access DNS servers
tains data. When the first data packet of the RSH in the intranet or DMZ directly, due to the “allow
connection is passed by the firewall, its entry in the all port 53” rule. If the ICMP “allow all” rule is
5
6. enabled, an attacker can map any intranet or DMZ [CBHM99] S. Christey, D. Baker, W. Hill, D.
subnets. Mann. “The Development of a Common
NAT and non-routable addresses do not necessar- Vulnerabilities and Exposures List”. 2nd
ily provide any inherent security. While FWZ en- International Workshop on Recent Ad-
capsulation is specific to FireWall-1, similar attacks vances in Intrusion Detection, Septem-
using other VPN encapsulation techniques may be ber 1999.
more widely applicable – GRE, IP protocols re-
served for IPsec, and even IPv6 tunnelling in IPv4 [Ha00] J. Hagino. “Possible Abuse Against
[Ha00]. IPv6 Transition Technologies”. Inter-
net Draft draft-itojun-ipv6-transition-
abuse-00a.txt (work-in-progress), Inter-
5.2 Configuration net Engineering Task Force, March
A few simple rules of thumb: 2000.
1. Be sure to run the latest version of FireWall-1 [Fy97] Fyodor, “The Art of Port Scanning”.
possible. Phrack Magazine 7:51, article 11,
September 1997.
2. Disable implicit rules, including those for DNS,
administrative control connections, and ICMP. [Ha95] N. Haller. “The S/KEY One-Time Pass-
word System”. RFC 1760, Internet En-
3. Be as specific as possible in defining rules – no gineering Task Force, February 1995.
“any” source or destination IP addresses, deny
multicast / broadcast addresses, etc. [ZRT95] G. Ziemba, D. Reed, P. Traina. “Secu-
rity Considerations for IP Fragment Fil-
4. Enable IP spoofing protection on all interfaces. tering”. RFC 1858, Internet Engineering
Task Force, October 1995.
5. Pre-filter IP protocol 94 (e.g. with IP Filter or
some other mechanism). [PN98] T. Ptacek, T. Newsham. “Insertion,
Evasion, and Denial of Service: Elud-
6. Separate virtual IP addresses for public ser-
ing Network Intrusion Detection”. Se-
vices.
cure Networks, Inc., January 1998.
7. Use only FWA1 authentication for now.
[Ro00] G. van Rooij. “Real Stateful TCP
Packet Filtering in IP Filter”. 2nd In-
5.3 Patches ternational SANE Conference, March
Check Point released patches to address these prob- 2000.
lems in time for our presentation at the Black Hat
Briefings. Current service packs, hotfixes, and alerts
are available at:
http://www.checkpoint.com/techsupport/
6 Acknowledgments
We would like to thank Check Point for their timely,
thorough response to our independent security re-
view, and for their exceptional professionalism in
dealing with these issues.
References
[Be89] S. Bellovin, “Security Problems in the
TCP/IP Protocol Suite”. Computer
Communications Review 2:19, pp. 32-
48, April 1989.
[Ch92] D. Brent Chapman. “Network
(In)Security Through IP Packet
Filtering”. 3rd USENIX Security
Symposium, September 1992.
6