Hariyono, S.T.

Some of you likely recall the talk back in 2016 or so of updating the OWASP Foundation website to not appear so much like a...well, a wiki. That talk was carried forward into 2017 and 2018 and, with each year, the proposal got pushed ahead as there were other, deeper projects to tackle. With the arrival of 2019 and a firm project plan under the guidance of Mike McCamon, Executive Director, we are finally moving toward a functioning, modern website that will be a whole lot less...wiki-like. The journey has been circuitous and, while we are not anywhere near complete, we have a set plan in place to bring it to fruition within the calendar year (second quarter of the year, actually).

TLDR: How Can You Help?

There are certainly ways in which you can get involved now. For instance, we are looking for a clean way to get wiki pages into GitHub markdown format for archival. I have done some work here but there are parsing issues with some of the tools. Do you know a good tool or have you done similar work? Also, are you or do you know a good designer, someone familiar with GitHub pages that can provide some useful help and feedback along the way? A Jekyll expert to help code a theme with a handful of templates would be a great addition. In addition, we could use website server admins who could help with assigning redirects to maintain search integrity. Finally, there will be a great many pages to move that we will also eventually need community involvement in.

So, What Have We Done?

Thus far we have researched various ideas for standing up a new site, including modifying the current wiki, spinning up our own web server, contracting a third party to host and build a new site, and also using existing infrastructure with our own content to launch a new face for OWASP. Our discussions led us to a familiar place, one that nearly every developer in the OWASP space is familiar with: GitHub.

In our conversations with GitHub, it became readily apparent that using the platform would be a win for the Foundation as well as GitHub. Nearly everyone who runs a project at OWASP (documentation or otherwise) uses GitHub. Because our target audience is also mostly developers we know that they are also very comfortable with the platform. And while GitHub has a number of high profile companies using their GitHub Pages, the use of the platform as the basis for the entire website of the number one non-profit foundation in the application security sector is a big draw.

We have run with that GitHub Pages idea and have spent internal manpower on a proof of concept. This proof of concept is less about the UX of the site than the functionality, the ability to utilize the authentication systems, and the ability to utilize automation to push out changes quickly.

Where Are We Now?

We are doing the final stages of website architecture. We are also planning what needs to be in the site, how the pieces will integrate with current projects and chapters, and how we might utilize the community to integrate the pieces so that we have a visually and functionally cohesive website that spans across multiple repositories.

What Is Next?

We will soon be looking for a modern website design that is responsive and clean. We will begin using the knowledge gained from our proof of concept to build out the internals of the website and then we will start implementing the highest traffic pages and administrative areas into the new platform. Once we have the big-ticket items moved we will start looking at what is left and moving over those pieces. The eventual goal would be to have a new, modern website for the future of OWASP while keeping the wiki as an archive of really useful information.

We hope you are as excited as we are about the future of the OWASP Foundation website and will join us as we move toward a modern web presence. If you have any questions or would like to volunteer your time, experience or knowledge, please contact me at harold.blankenship@owasp.com

More information

We found out that in contrast to public knowledge, the Pre-Shared Key (PSK) authentication method in main mode of IKEv1 is susceptible to offline dictionary attacks. This requires only a single active Man-in-the-Middle attack. Thus, if low entropy passwords are used as PSKs, this can easily be broken.

This week at the USENIX Security conference, Dennis Felsch will present our research paper on IPsec attacks: The Dangers of Key Reuse: Practical Attacks on IPsec IKE. [alternative link to the paper]

In his blog post, Dennis showed how to attack the public key encryption based authentication methods of IKEv1 (PKE & RPKE) and how to use this attack against IKEv2 signature based authentication method. In this blog post, I will focus on another interesting finding regarding IKEv1 and the Pre-Shared Key authentication.

IPsec and Internet Key Exchange (IKE)

IPsec enables cryptographic protection of IP packets. It is commonly used to build VPNs (Virtual Private Networks). For key establishment, the IKE protocol is used. IKE exists in two versions, each with different modes, different phases, several authentication methods, and conﬁguration options. Therefore, IKE is one of the most complex cryptographic protocols in use.

In version 1 of IKE (IKEv1), four authentication methods are available for Phase 1, in which initial authenticated keying material is established: Two public key encryption based methods, one signature based method, and a PSK (Pre-Shared Key) based method.

The relationship between IKEv1 Phase 1, Phase 2, and IPsec ESP. Multiple simultaneous Phase 2 connections can be established from a single Phase 1 connection. Grey parts are encrypted, either with IKE derived keys (light grey) or with IPsec keys (dark grey). The numbers at the curly brackets denote the number of messages to be exchanged in the protocol.

Pre-Shared Key authentication

As shown above, Pre-Shared Key authentication is one of three authentication methods in IKEv1. The authentication is based on the knowledge of a shared secret string. In reality, this is probably some sort of password.

The IKEv1 handshake for PSK authentication looks like the following (simplified version):

In the first two messages, the session identifier (inside HDR) and the cryptographic algorithms (proposals) are selected by initiator and responder.

In messages 3 and 4, they exchange ephemeral Diffie-Hellman shares and nonces. After that, they compute a key k by using their shared secret (PSK) in a PRF function (e.g. HMAC-SHA1) and the previously exchanged nonces. This key is used to derive additional keys (k_a, k_d, k_e). The key k_d is used to compute MAC_I over the session identifier and the shared diffie-hellman secret g^xy. Finally, the key k_e is used to encrypt ID_I (e.g. IPv4 address of the peer) and MAC_I.

Weaknesses of PSK authentication

It is well known that the aggressive mode of authentication in combination with PSK is insecure and vulnerable against off-line dictionary attacks, by simply eavesedropping the packets. For example, in strongSwan it is necessary to set the following configuration flag in order to use it:

charon.i_dont_care_about_security_and_use_aggressive_mode_psk=yes

For the main mode, we found a similar attack when doing some minor additional work. For that, the attacker needs to waits until a peer A (initiator) tries to connect to another peer B (responder). Then, the attacker acts as a man-in-the middle and behaves like the peer B would, but does not forward the packets to B.

From the picture above it should be clear that an attacker who acts as B can compute (g^xy) and receives the necessary public values session ID, n_I, n_R. However, the attacker does not know the PSK. In order to mount a dictionary attack against this value, he uses the nonces, and computes a candidate for k for every entry in the dictionary. It is necessary to make a key derivation for every k with the values of the session identifiers and shared Diffie-Hellmann secret the possible keys k_a, k_d and k_e. Then, the attacker uses k_e in order to decrypt the encrypted part of message 5. Due to ID_I often being an IP address plus some additional data of the initiator, the attacker can easily determine if the correct PSK has been found.

Who is affected?

This weakness exists in the IKEv1 standard (RFC 2409). Every software or hardware that is compliant to this standard is affected. Therefore, we encourage all vendors, companies, and developers to at least ensure that high-entropy Pre-Shared Keys are used in IKEv1 configurations.

In order to verify the attack, we tested the attack against strongSWAN 5.5.1.

Proof-of-Concept

We have implemented a PoC that runs a dictionary attack against a network capture (pcapng) of a IKEv1 main mode session. As input, it also requires the Diffie-Hellmann secret as described above. You can find the source code at github. We only tested the attack against strongSWAN 5.5.1. If you want to use the PoC against another implementation or session, you have to adjust the idHex value in main.py.

Responsible Disclosure

We reported our ﬁndings to the international CERT at July 6th, 2018. We were informed that they contacted over 250 parties about the weakness. The CVE ID for it is CVE-2018-5389 [cert entry].

Credits

On August 10th, 2018, we learned that this attack against IKEv1 main mode with PSKs was previously described by David McGrew in his blog post Great Cipher, But Where Did You Get That Key?. We would like to point out that neither we nor the USENIX reviewers nor the CERT were obviously aware of this.
On August 14th 2018, Graham Bartlett (Cisco) email us that he presented the weakness of PSK in IKEv2 in several public presentations and in his book.
On August 15th 2018, we were informed by Tamir Zegman that John Pliam described the attack on his web page in 1999.

FAQs

Do you have a name, logo, any merchandising for the attack?
No.
Have I been attacked?
We mentioned above that such an attack would require an active man-in-the-middle attack. In the logs this could look like a failed connection attempt or a session timed out. But this is a rather weak indication and no evidence for an attack.
What should I do?
If you do not have the option to switch to authentication with digital signatures, choose a Pre-Shared Key that resists dictionary attacks. If you want to achieve e.g. 128 bits of security, configure a PSK with at least 19 random ASCII characters. And do not use something that can be found in public databases.
Am I safe if I use PSKs with IKEv2?
No, interestingly the standard also mentions that IKEv2 does not prevent against off-line dictionary attacks.
Where can I learn more?
You can read the paper. [alternative link to the paper]
What else does the paper contain?
The paper contains a lot more details than this blogpost. It explains all authentication methods of IKEv1 and it gives message flow diagrams of the protocol. There, we describe a variant of the attack that uses the Bleichenbacher oracles to forge signatures to target IKEv2.

Related word

Many of people want to start PHP programming embedded with MYSQL databases concepts. So i thought that I should start a series about PHP and MYSQL. So in this series of video tutorials you exactly got the content about PHP and MYSQL.

As PHP is server side scripting language. So it requires a server to get execute over the web browser. First of all you have to download and install a server that may be XAMPP, WAMPP or LAMPP. I'm using XAMPP server in the tutorials. So if you wanna follow me then download a XAMPP server. I'm using this because it has a good interface to work and it's really simple. XAMPP is compatible with windows, MAC and Linux operating as well. WAMPP is only for windows and LAMPP is used for MAC and Linux operating system. So i prefer XAMPP for this series.

How to create Database

Step 1:

Open Your XAMPP control panel and start Apache and Mysql services.

Step 2:

Go to your Web browser and type "localhost/phpmyadmin". It will open your databases area. If you have an error then your services are not in running state. If you have any error then comment below.

Step 3:

Click over the "new" to create a new database.

Step 4:

Write Database_Name and click over the Create button. For example Facebook, Students etc.

Step 5:

Write Table_Name like admin, users etc. your can increase and decrease the size of rows. Click over Save/Create button.

Step 6:

Write your Attribute_Names in first column like Username, Email, Passwords etc. In the next data type column you have to select the data type whether it is integer or string type etc. In the next column you have to set the length of string/words.

Step 7:

If you wanna go through with a Primary_Key. Then just you have to checked the Auto_Increment box as you will shown in the video. For further watch the video for better understanding.

Related posts

What is BurpSuite?
Burp Suite is a Java based Web Penetration Testing framework. It has become an industry standard suite of tools used by information security professionals. Burp Suite helps you identify vulnerabilities and verify attack vectors that are affecting web applications. Because of its popularity and breadth as well as depth of features, we have created this useful page as a collection of Burp Suite knowledge and information.

In its simplest form, Burp Suite can be classified as an Interception Proxy. While browsing their target application, a penetration tester can configure their internet browser to route traffic through the Burp Suite proxy server. Burp Suite then acts as a (sort of) Man In The Middle by capturing and analyzing each request to and from the target web application so that they can be analyzed.

Everyone has their favorite security tools, but when it comes to mobile and web applications I've always found myself looking BurpSuite . It always seems to have everything I need and for folks just getting started with web application testing it can be a challenge putting all of the pieces together. I'm just going to go through the installation to paint a good picture of how to get it up quickly.

BurpSuite is freely available with everything you need to get started and when you're ready to cut the leash, the professional version has some handy tools that can make the whole process a little bit easier. I'll also go through how to install FoxyProxy which makes it much easier to change your proxy setup, but we'll get into that a little later.

Requirements and assumptions:

Mozilla Firefox 3.1 or Later Knowledge of Firefox Add-ons and installation The Java Runtime Environment installed

Download BurpSuite from http://portswigger.net/burp/download.htmland make a note of where you save it.

on for Firefox from https://addons.mozilla.org/en-US/firefox/addon/foxyproxy-standard/

If this is your first time running the JAR file, it may take a minute or two to load, so be patient and wait.

Video for setup and installation.

You need to install compatible version of java , So that you can run BurpSuite.

Related posts

Hariyono, S.T.

Rabu, 31 Mei 2023

OWASP Web 2.0 Project Update

TLDR: How Can You Help?

So, What Have We Done?

Where Are We Now?

What Is Next?

More information

Practical Dictionary Attack On IPsec IKE

IPsec and Internet Key Exchange (IKE)

Pre-Shared Key authentication

Weaknesses of PSK authentication

Who is affected?

Proof-of-Concept

Responsible Disclosure

Credits

FAQs

How To Start PHP And MYSQL | The Best Server For PHP And MYSQL | Tutorial 1

How to create Database

Selasa, 30 Mei 2023

BurpSuite Introduction & Installation

Menu

Info Praktikum

Jadwal Praktikum

Pengganti/Tambahan

Arsip Blog