TW Cell Phones

Tammy Worcester

"OpenVAS stands for Open Vulnerability Assessment System and is a network security scanner with associated tools like a graphical user front-end. The core is a server component with a set of network vulnerability tests (NVTs) to detect security problems in remote systems and applications." read more...

Website: http://www.openvas.org

More articles

Tammy Worcester

What is the terminologies in ethical hacking?

Here are a few key terms that you will hear in discussion about hackers and what they do:

1-Backdoor-A secret pathway a hacker uses to gain entry to a computer system.

2-Adware-It is the softw-are designed to force pre-chosen ads to display on your system.

3-Attack-That action performs by a attacker on a system to gain unauthorized access.

4-Buffer Overflow-It is the process of attack where the hacker delivers malicious commands to a system by overrunning an application buffer.

5-Denial-of-Service attack (DOS)-A attack designed to cripple the victim's system by preventing it from handling its normal traffic,usally by flooding it with false traffic.

6-Email Warm-A virus-laden script or mini-program sent to an unsuspecting victim through a normal-looking email message.

7-Bruteforce Attack-It is an automated and simplest kind of method to gain access to a system or website. It tries different combination of usernames and passwords,again & again until it gets in from bruteforce dictionary.

8-Root Access-The highest level of access to a computer system,which can give them complete control over the system.

9-Root Kit-A set of tools used by an intruder to expand and disguise his control of the system.It is the stealthy type of software used for gain access to a computer system.

10-Session Hijacking- When a hacker is able to insert malicious data packets right into an actual data transmission over the internet connection.

11-Phreaker-Phreakers are considered the original computer hackers who break into the telephone network illegally, typically to make free longdistance phone calls or to tap lines.

12-Trojan Horse-It is a malicious program that tricks the computer user into opening it.There designed with an intention to destroy files,alter information,steal password or other information.

13-Virus-It is piece of code or malicious program which is capable of copying itself has a detrimental effect such as corrupting the system od destroying data. Antivirus is used to protect the system from viruses.

14-Worms-It is a self reflicating virus that does not alter files but resides in the active memory and duplicate itself.

15-Vulnerability-It is a weakness which allows a hacker to compromise the security of a computer or network system to gain unauthorized access.

16-Threat-A threat is a possible danger that can exploit an existing bug or vulnerability to comprise the security of a computer or network system. Threat is of two types-physical & non physical.

17-Cross-site Scripting-(XSS) It is a type of computer security vulnerability found in web application.It enables attacker to inject client side script into web pages viwed by other users.

18-Botnet-It is also known as Zombie Army is a group of computers controlled without their owner's knowledge.It is used to send spam or make denial of service attacks.

19-Bot- A bot is a program that automates an action so that it can be done repeatedly at a much higher rate for a period than a human operator could do it.Example-Sending HTTP, FTP oe Telnet at a higer rate or calling script to creat objects at a higher rate.

20-Firewall-It is a designed to keep unwanted intruder outside a computer system or network for safe communication b/w system and users on the inside of the firewall.

21-Spam-A spam is unsolicited email or junk email sent to a large numbers of receipients without their consent.

22-Zombie Drone-It is defined as a hi-jacked computer that is being used anonymously as a soldier or drone for malicious activity.ExDistributing Unwanted Spam Emails.

23-Logic Bomb-It is a type of virus upload in to a system that triggers a malicious action when certain conditions are met.The most common version is Time Bomb.

24-Shrink Wrap code-The process of attack for exploiting the holes in unpatched or poorly configured software.

25-Malware-It is an umbrella term used to refer a variety of intrusive software, including computer viruses,worms,Trojan Horses,Ransomeware,spyware,adware, scareware and other malicious program.

Follow me on instagram-anoymous_adi

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.

More information

Tammy Worcester

Research: SentinelOne, Tim Strazzere Hiding in plain sight?
Sample credit: Tim Strazzere

List of files

9f7ead4a7e9412225be540c30e04bf98dbd69f62b8910877f0f33057ca153b65 malware
d507119f6684c2d978129542f632346774fa2e96cf76fa77f377d130463e9c2c malware
fddb36800fbd0a9c9bfffb22ce7eacbccecd1c26b0d3fb3560da5e9ed97ec14c script.decompiled-pretty
ec5d4f90c91273b3794814be6b6257523d5300c28a492093e4fa1743291858dc script.decompiled-raw
4d46893167464852455fce9829d4f9fcf3cce171c6f1a9c70ee133f225444d37 script.dumped

malware_a3dad000efa7d14c236c8018ad110144
malware fcbfb234b912c84e052a4a393c516c78
script.decompiled-pretty aab8ea012eafddabcdeee115ecc0e9b5
script.decompiled-raw ae0ea319de60dae6d3e0e58265e0cfcc
script.dumped b30df2e63bd4f35a32f9ea9b23a6f9e7

Download

Download. Email me if you need the password