Humour In Verse: May 2020

BASICS OF METASPLOIT – BASIC COMMANDS OF METASPLOIT

Metasploit is an advanced hacking tool that comes itself with a complete lack of advanced penetration testing tools. Penetration testers and hackers are taking so much advantage of this tool. It's a complete hack pack for a hacker that he can play almost any attack with it. Here I am going to discuss the basics of Metasploit. I am not covering attacks in this article, as I am just making sure to share the basics of Metasploit and basic commands of Metasploit. So, we can get back to cover attacks of Metasploit in the next articles.

BASICS OF METASPLOIT

The Metasploit framework has three types of working environments.

msfconsole
msfcli interface
msfweb interface

However, the most preferred and used is the 'msfconsole'. It's a very efficient command-line interface that has its own set of commands and system's working environment.

First of all, it's most important to know and understand all the useful commands of Metasploit that are going to be used.

BASIC COMMANDS OF METASPLOIT

Metasploit have a huge number of command that we can use in different type of attacks, but I am just going to share the most used and useful commands here that a beginner can easily understand and follow 'em.

help (It will give the basic commands you need to launch an exploit.
search (Finds out the keywords in the selected attack method).
show exploits (Shows list of an available exploit in the selected option).
show payloads (It lists all the payloads available).
show options (It helps you to know all the options if you might have forgotten one).
info (This is used to get information about any exploit or payload).
use (It tells Metasploit to use the exploit with the specified name).
set RHOST (Sets the address of specified remote host).
set RPORT (Sets up a port that connects to on the remote host).
set PAYLOAD (It sets the payload that gives you a shell when a service is exploited).
set LPORT (Sets the port number that the payload will open on the server when an exploit is exploited).
exploit (It actually exploits the service).
rexploit (Reloads your exploit code and then executes the exploit without restarting the console).

These are the most used Metasploit commands which come in handy in most of the situations during any sort of attack. You must give all the commands a try and understand 'em how it works and then move to the next part of designing an attack.

Related posts

Osueta: A Simple Python Script To Exploit The OpenSSH User Enumeration Timing Attack

About Osueta?
Osueta it's a simple Python 2 script to exploit the OpenSSH User Enumeration Timing Attack, present in OpenSSH versions <= 7.2 and >= 5.*. The script has the ability to make variations of the username employed in the bruteforce attack, and the possibility to establish a DoS condition in the OpenSSH server.

Read more: OpenSSH User Enumeration Time-Based Attack

The bug was corrected in OpenSSH version 7.3.

Authors of Osueta:

c0r3dump3d: coredump@autistici.org
rofen: rofen@gmx.de

Osueta's Installation
For Linux users, open your Terminal and enter these commands:
If you're Windows users, follow these steps:

Install Python 2.7.x from Python.org first. On Install Python 2.7.x Setup, choose Add python.exe to Path.
Download Osueta-master zip file.
Then unzip it.
Open CMD or PowerShell window at the Osueta folder you have just unzipped and enter these commands:
pip install python-nmap paramiko IPy
python osueta.py -h

Advice: Like others offensive tools, the authors disclaims all responsibility in the use of this script.

Osueta help menu:

Osueta's examples:
A single user enumeration attempt with username variations:
python2 osueta.py -H 192.168.1.6 -p 22 -U root -d 30 -v yes

A single user enumeration attempt with no user variations a DoS attack:
python2 osueta.py -H 192.168.1.6 -p 22 -U root -d 30 -v no --dos yes

Scanning a C class network with only one user:
python2 osueta.py -H 192.168.1.0/24 -p 22 -U root -v no

Scanning a C class network with usernames from a file, delay time 15 seconds and a password of 50000 characters:
python2 osueta.py -H 192.168.1.0/24 -p 22 -L usernames.txt -v yes -d 15 -l 50

Download Osueta

Goddi (Go Dump Domain Info) - Dumps Active Directory Domain Information

Based on work from Scott Sutherland (@_nullbind), Antti Rantasaari, Eric Gruber (@egru), Will Schroeder (@harmj0y), and the PowerView authors.

Install
Use the executables in the releases section. If you want to build it yourself, make sure that your go environment is setup according to the Go setup doc. The goddi package also uses the below package.

go get gopkg.in/ldap.v2

Windows
Tested on Windows 10 and 8.1 (go1.10 windows/amd64).

Linux
Tested on Kali Linux (go1.10 linux/amd64).

umount, mount, and cifs-utils need to be installed for mapping a share for GetGPP

apt-get update
apt-get install -y mount cifs-utils

make sure nothing is mounted at /mnt/goddi/
make sure to run with sudo

Run
When run, will default to using TLS (tls.Client method) over 636. On Linux, make sure to run with sudo.

username: Target user. Required parameter.
password: Target user's password. Required parameter.
domain: Full domain name. Required parameter.
dc: DC to target. Can be either an IP or full hostname. Required parameter.
startTLS: Use to StartTLS over 389.
unsafe: Use for a plaintext connection.

PS C:\Users\Administrator\Desktop> .\godditest-windows-amd64.exe -username=testuser -password="testpass!" -domain="test.local" -dc="dc.test.local" -unsafe
[i] Begin PLAINTEXT LDAP connection to 'dc.test.local'...
[i] PLAINTEXT LDAP connection to 'dc.test.local' successful...
[i] Begin BIND...
[i] BIND with 'testuser' successful...
[i] Begin dump domain info...
[i] Domain Trusts: 1 found
[i] Domain Controllers: 1 found
[i] Users: 12 found
        [*] Warning: keyword 'pass' found!
        [*] Warning: keyword 'fall' found!
[i] Domain Admins: 4 users found
[i] Enterprise Admins: 1 users found
[i] Forest Admins: 0 users found
[i] Locked Users: 0 found
[i] Disabled Users: 2 found
[i] Groups: 45 found
[i] Domain Sites: 1 found
[i] Domain Subnets: 0 found
[i] Domain Computers: 17 found
[i] Deligated Users: 0 found
[i] Users with passwords not set to expire: 6 found
[i] Machine Accounts with passwords older than 45 days: 18 found
[i] Domain OUs: 8 found
[i] Domain Account Policy found
[i] Domain GPOs: 7 found
[i] FSMO Roles: 3 found
[i] SPNs: 122 found
[i] LAPS passwords: 0 found
[i] GPP enumeration starting. This can take a bit...
[i] GPP passwords: 7 found
[i] CSVs written to 'csv' directory in C:\Users\Administrator\Desktop
[i] Execution took 1.4217256s...
[i] Exiting...

Functionality
StartTLS and TLS (tls.Client func) connections supported. Connections over TLS are default. All output goes to CSVs and are created in /csv/ in the current working directory. Dumps:

Domain users. Also searches Description for keywords and prints to a seperate csv ex. "Password" was found in the domain user description.
Users in priveleged user groups (DA, EA, FA).
Users with passwords not set to expire.
User accounts that have been locked or disabled.
Machine accounts with passwords older than 45 days.
Domain Computers.
Domain Controllers.
Sites and Subnets.
SPNs and includes csv flag if domain admin (a flag to note SPNs that are DAs in the SPN CSV output).
Trusted domain relationships.
Domain Groups.
Domain OUs.
Domain Account Policy.
Domain deligation users.
Domain GPOs.
Domain FSMO roles.
LAPS passwords.
GPP passwords. On Windows, defaults to mapping Q. If used, will try another mapping until success R, S, etc... On Linux, /mnt/goddi is used.

Download Goddi

PKCE: What Can(Not) Be Protected

This post is about PKCE [RFC7636], a protection mechanism for OAuth and OpenIDConnect designed for public clients to detect the authorization code interception attack.

At the beginning of our research, we wrongly believed that PKCE protects mobile and native apps from the so called „App Impersonation" attacks. Considering our ideas and after a short discussion with the authors of the PKCE specification, we found out that PKCE does not address this issue.

In other words, the protection of PKCE can be bypassed on public clients (mobile and native apps) by using a maliciously acting app.

OAuth Code Flow

In Figure 1, we briefly introduce how the OAuth flow works on mobile apps and show show the reason why we do need PKCE.
In our example the user has two apps installed on the mobile phone: an Honest App and an Evil App. We assume that the Evil App is able to register the same handler as the Honest App and thus intercept messages sent to the Honest App. If you are more interested in this issue, you can find more information here [1].

Figure 1: An example of the "authorization code interception" attack on mobile devices.

Step 1: A user starts the Honest App and initiates the authentication via OpenID Connect or the authorization via OAuth. Consequentially, the Honest App generates an Auth Request containing the OpenID Connect/OAuth parameters: client_id, state, redirect_uri, scope, authorization_grant, nonce, ….

Step 2: The Browser is called and the Auth Request is sent to the Authorization Server (usually Facebook, Google, …).

The Honest App could use a Web View browser. However, the current specification clearly advice to use the operating system's default browser and avoid the usage of Web Views [2]. In addition, Google does not allow the usage of Web View browser since August 2016 [3].

Step 3: We asume that the user is authenticated and he authorizes the access to the requested resources. As a result, the Auth Response containing the code is sent back to the browser.

Step 4: Now, the browser calls the Honest App registered handler. However, the Evil App is registered on this handler too and receives the code.

Step 5: The Evil App sends the stolen code to the Authorization Server and receives the corresponding access_token in step 6. Now, the Evil App can access the authorized ressources.

Optionally, in step 5 the App can authenticate on the Authorization Server via client_id, client_secret. Since, Apps are public clients they do not have any protection mechanisms regarding the storage of this information. Thus, an attacker can easy get this information and add it to the Evil App.

Proof Key for Code Exchange - PKCE (RFC 7636)

Now, let's see how PKCE does prevent the attack. The basic idea of PKCE is to bind the Auth Request in Step 1 to the code redemption in Step 5. In other words, only the app generated the Auth Request is able to redeem the generated code.

Figure 2: PKCE - RFC 7636

Step 1: The Auth Request is generated as previosly described. Additionally, two parameters are added:

The Honest App generates a random string called code_verifier
The Honest App computes the code_challenge=SHA-256(code_verifier)
The Honest App specifies the challenge_method=SHA256

Step 2: The Authorization Server receives the Auth Request and binds the code to the received code_challenge and challenge_method.

Later in Step 5, the Authorzation Server expects to receive the code_verifier. By comparing the SHA-256(code_verifier) value with the recieved code_challenge, the Authorization Server verifies that the sender of the Auth Request ist the same as the sender of the code.

Step 3-4: The code leaks again to the Evil App.

Step 5: Now, Evil App must send the code_verifier together with the code. Unfortunatelly, the App does not have it and is not able to compute it. Thus, it cannot redeem the code.

PKCE Bypass via App Impersonation

Again, PKCE binds the Auth Request to the coderedemption.

The question rises, if an Evil App can build its own Auth Request with its own code_verifier, code_challenge and challenge_method.The short answer is – yes, it can.

Figure 3: Bypassing PKCE via the App Impersonation attack

Step 1: The Evil App generates an Auth Request. The Auth Request contains the client_id and redirect_uri of the Honest App. Thus, the User and the Authorization Server cannot recognize that the Evil App initiates this request.

Step 2-4: These steps do not deviate from the previous description in Figure 2.

Step 5: In Step 5 the Evil App sends the code_verifier used for the computation of the code_challenge. Thus, the stolen code can be successfully redeemed and the Evil App receives the access_token and id_token.

OAuth 2.0 for Native Apps

The attack cannot be prevented by PKCE. However, the IETF working group is currently working on a Draft describing recommendations for using OAuth 2.0 for native apps.

References

[1] http://mews.sv.cmu.edu/papers/ccs-14.pdf

[2] https://tools.ietf.org/html/draft-ietf-oauth-native-apps-06#section-8.1

[3] https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

Authors

Vladislav Mladenov
Christian Mainka (@CheariX)

More articles

How To Connect Database With PHP | Cool Interface Software | Tutorial 2

Welcome to my 2nd tutorial of PHP and MYSQL. In the previous video I've discussed How to download and install a server PHP and also How to create databases and How to create tables in the databases in the form of rows and columns.

In this video I've discussed multiple ways to connect database with PHP such as by using variables etc. First of all you have need to install a cool interface software for coding. I suggested you to download any one of them such as Dreamweaver, Notepad++, Sublime Text Editor and Atom etc. I'm using sublime text editor in this series of tutorial.

Syntax of PHP

<?php

//type here the code

?>

How to save the PHP file

You should save your PHP file in the root directory of the server. In XAMPP the "htdocs" is the root directory of the server. In WAMPP "www" is the root directory. Now how to save the file?

Step 1:

Press CTRL + S button to safe the file.

Step 2:

Go to the server location where it has been installed. By default it is installed in Local Disk C. Got C drive.

Step 3:

Go to XAMPP directory.

Step 4:

Go to htdocs diretory.

Step 5:

Save a file there with extension ".php". You can create a different folders for different projects in htdocs directory. So first create the folder in htdocs and then save your files in the folder.

How to Run PHP Script