金澤ホルモンのスタッフブログ: 6月 2020

2020年6月12日金曜日

HACKING GMAIL FOR FREE CUSTOM DOMAIN EMAIL

When it comes to email providers, there's no competitor to Google's awesome features. It is efficient which connects seamlessly with the rest of your Google products such as YouTube, Drive, has a major application called Gmail Inbox, and is overall an extremely powerful email service. However, to use it with a custom domain, you need to purchase Google Apps for either $5 or $10/month, which for casual users is a bit unnecessary. On top of that, you don't even get all of the features a personal account gets, e.g. Inbox. So, here's a free way to use your Gmail account with a custom domain. I am just going to show you hacking Gmail for free custom domain email.

SO, HOW HACKING GMAIL FOR FREE CUSTOM DOMAIN EMAIL

PASSWORD: EHT

STEPS:

First, register with Mailgun using your Gmail address. Use your Gmail only. Once you have clicked the confirm link, log in to the Mailgun website. Now you're in the dashboard, move on the right under "Custom Domains", click "Add Domain".
Follow the setup instructions and set DNS records with whoever manages your DNS. Once you've done this, click on the "Routes" link on the top to set up email forwarding.
Now move to the Route tab and click on Create New Route.
As you click the button, you will see a page like below. Just enter the information as entered in the following screenshot.
Just replace the quoted email with your desired email in the above-given screenshot.
Next, we'll setup SMTP configuration so we would be able to send emails from an actual server. Go to "Domains" tab, click on your domain name.
On this page, click "Manage your SMTP credentials" then "New SMTP Credential" on the next page.
Type in the desired SMTP credentials. And, go to Gmail settings and click "Add another email address you own". Once you open, enter the email address you wish to send from.
In the next step, set the SMTP settings as follows.
After clicking "Add Account" button, now you're done.
The final step, make sure to set it to default email in the Gmail settings > Accounts.

That's all. Now you got free Gmail custom domain with 10,000 emails per month. Hope it will work for you. If you find any issue, just comment below.

Note: Use Virtual Machine and scan on VirusTotal before downloading any program on Host Machine for your privacy.

C++ Std::String Buffer Overflow And Integer Overflow

Interators are usually implemented using signed integers like the typical "for (int i=0; ..." and in fact is the type used indexing "cstr[i]", most of methods use the signed int, int by default is signed.
Nevertheless, the "std::string::operator[]" index is size_t which is unsigned, and so does size(), and same happens with vectors.
Besides the operator[] lack of negative index control, I will explain this later.

Do the compilers doesn't warn about this?

If his code got a large input it would index a negative numer, let see g++ and clang++ warnings:

No warnings so many bugs out there...

In order to reproduce the crash we can load a big string or vector from file, for example:

I've implemented a loading function, getting the file size with tellg() and malloc to allocate the buffer, then in this case used as a string.
Let see how the compiler write asm code based on this c++ code.

So the string constructor, getting size and adding -2 is clear. Then come the operator<< to concat the strings.
Then we see the operator[] when it will crash with the negative index.
In assembly is more clear, it will call operator[] to get the value, and there will hapen the magic dereference happens. The operator[] will end up returning an invalid address that will crash at [RAX]

In gdb the operator[] is a allq 0x555555555180 <_znst7__cxx1112basic_stringicst11char_traitsicesaiceeixem plt="">

(gdb) i r rsi
rsi 0xfffffffffffefffe -65538

The implmementation of operator ins in those functions below:

(gdb) bt
#0 0x00007ffff7feebf3 in strcmp () from /lib64/ld-linux-x86-64.so.2
#1 0x00007ffff7fdc9a5 in check_match () from /lib64/ld-linux-x86-64.so.2
#2 0x00007ffff7fdce7b in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
#3 0x00007ffff7fdd739 in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2
#4 0x00007ffff7fe1eb7 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
#5 0x00007ffff7fe88ee in _dl_runtime_resolve_xsavec () from /lib64/ld-linux-x86-64.so.2
#6 0x00005555555554b3 in main (argc=2, argv=0x7fffffffe118) at main.cpp:29

Then crashes on the MOVZX EAX, byte ptr [RAX]

Program received signal SIGSEGV, Segmentation fault.

0x00005555555554b3 in main (argc=2, argv=0x7fffffffe118) at main.cpp:29
29 cout << "penultimate byte is " << hex << s[i] << endl;
(gdb)

What about negative indexing in std::string::operator[] ?
It's exploitable!

In a C char array is known that having control of the index, we can address memory.
Let's see what happens with C++ strings:

The operator[] function call returns the address of string plus 10, and yes, we can do abitrary writes.

Note that gdb displays by default with at&t asm format wich the operands are in oposite order:

And having a string that is in the stack, controlling the index we can perform a write on the stack.

To make sure we are writing outside the string, I'm gonna do 3 writes:

See below the command "i r rax" to view the address where the write will be performed.

The beginning of the std::string object is 0x7fffffffde50.
Write -10 writes before the string 0x7fffffffde46.
And write -100 segfaults because is writting in non paged address.

So, C++ std::string probably is not vulnerable to buffer overflow based in concatenation, but the std::string::operator[] lack of negative indexing control and this could create vulnerable and exploitable situations, some times caused by a signed used of the unsigned std::string.size()

2020年6月10日水曜日

DarkFly Tool V4.0 | 500 Tools | Termux

More info

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

Support For XXE Attacks In SAML In Our Burp Suite Extension

In this post we present the new version of the Burp Suite extension EsPReSSO - Extension for Processing and Recognition of Single Sign-On Protocols. A DTD attacker was implemented on SAML services that was based on the DTD Cheat Sheet by the Chair for Network and Data Security (https://web-in-security.blogspot.de/2016/03/xxe-cheat-sheet.html). In addition, many fixes were added and a new SAML editor was merged. You can find the newest version release here: https://github.com/RUB-NDS/BurpSSOExtension/releases/tag/v3.1

New SAML editor

Before the new release, EsPReSSO had a simple SAML editor where the decoded SAML messages could be modified by the user. We extended the SAML editor so that the user has the possibility to define the encoding of the SAML message and to select their HTTP binding (HTTP-GET or HTTP-POST).

Redesigned SAML Encoder/Decoder

Enhancement of the SAML attacker

XML Signature Wrapping and XML Signature Faking attacks have already been part of the previous EsPReSSO version. Now the user can also perform DTD attacks! The user can select from 18 different attack vectors and manually refine them all before applying the change to the original message. Additional attack vectors can also be added by extending the XML config file of the DTD attacker.
The DTD attacker can also be started in a fully automated mode. This functionality is integrated in the BurpSuite Intruder.

DTD Attacker for SAML messages

Supporting further attacks

We implemented a CertificateViewer which extracts and decodes the certificates contained within the SAML tokens. In addition, a user interface for executing SignatureExclusion attack on SAML has been implemented.

Additional functions will follow in later versions.

Currently we are working on XML Encryption attacks.

This is a combined work from Nurullah Erinola, Nils Engelbertz, David Herring, Juraj Somorovsky, and Vladislav Mladenov.

The research was supported by the European Commission through the FutureTrust project (grant 700542-Future-Trust-H2020-DS-2015-1).

More info

DSniff

"dsniff is a collection of tools for network auditing and penetration testing. dsniff, filesnarf, mailsnarf, msgsnarf, urlsnarf, and webspy passively monitor a network for interesting data (passwords, e-mail, files, etc.). arpspoof, dnsspoof, and macof facilitate the interception of network traffic normally unavailable to an attacker (e.g, due to layer-2 switching). sshmitm and webmitm implement active monkey-in-the-middle attacks against redirected SSH and HTTPS sessions by exploiting weak bindings in ad-hoc PKI." read more...

Website: http://www.monkey.org/~dugsong/dsniff/

Related news

2020年6月9日火曜日

Reversing C++ String And QString

After the rust string overview of its internal substructures, let's see if c++ QString storage is more light, but first we'r going to take a look to the c++ standard string object:

At first sight we can see the allocation and deallocation created by the clang++ compiler, and the DAT_00400d34 is the string.

If we use same algorithm than the rust code but in c++:

We have a different decompilation layout. Note that the Ghidra scans very fast the c++ binaries, and with rust binaries gets crazy for a while.
Locating main is also very simple in a c++ compiled binary, indeed is more low-level than rust.

The byte array is initialized with a simply move instruction:
00400c4b 48 b8 68 MOV RAX,0x6f77206f6c6c6568

And basic_string generates the string, in the case of rust this was carazy endless set of calls, detected by ghidra as a runtime, but nevertheless the basic_string is an external imported function not included on the binary.

(gdb) x/x 0x7fffffffe1d0
0x7fffffffe1d0: 0xffffe1e0 low str ptr
0x7fffffffe1d4: 0x00007fff hight str ptr
0x7fffffffe1d8: 0x0000000b sz
0x7fffffffe1dc: 0x00000000
0x7fffffffe1e0: 0x6c6c6568 "hello world"
0x7fffffffe1e4: 0x6f77206f
0x7fffffffe1e8: 0x00646c72
0x7fffffffe1ec: 0x00000000 null terminated
(gdb) x/s 0x7fffffffe1e0
0x7fffffffe1e0: "hello world"

The string is on the stack, and it's very curious to see what happens if there are two followed strings like these:

  auto s = string(cstr);
  string s2 = "test";

Clang puts toguether both stack strings:
[ptr1][sz1][string1][null][string2][null][ptr2][sz2]

C++ QString datatype

Let's see the great and featured QString object defined on qstring.cpp and qstring.h

Some QString methods use the QCharRef class whose definition is below:

class Q_EXPORT QCharRef {
    friend class QString;
    QString& s;
    uint p;

Searching for the properties on the QString class I've realized that one improvement that rust and golang does is the separation from properties and methods, so in the large QString class the methods are hidden among the hundreds of methods, but basically the storage is a QStringData *;

After removing the methods of QStringData class definition we have this:

struct Q_EXPORT QStringData : public QShared {
QChar *unicode;
char *ascii;
#ifdef Q_OS_MAC9
uint len;
#else
uint len : 30;

Linux Command Line Hackery Series - Part 3

Welcome back, hope you are enjoying this series, I don't know about you but I'm enjoying it a lot. This is part 3 of the series and in this article we're going to learn some new commands. Let's get started

Command: w
Syntax: w
Function: This simple function is used to see who is currently logged in and what they are doing, that is, their processes.

Command: whoami
Syntax:   whoami
Function: This is another simple command which is used to print the user name associated with the current effective user ID.

Try it and it will show up your user name.

If you want to know information about a particular user no matter whether it is you or someone else there is a command for doing that as well.

Command: finger
Syntax: finger [option] [username]
Function: finger is a user information lookup program. The [] around the arguments means that these arguments are optional this convention is used everywhere in this whole series.

In order to find information about your current user you can simply type:

finger username

Here username is your current username.
To find information about root you can type:

finger root

and it will display info about root user.

Command: uname
Syntax: uname [options]
Function:   uname is used to display information about the system.

uname is mostly used with the flag -a, which means display all information like this:

uname -a

Command: df
Syntax: df [option] [FILE ...]
Function:   df is used to display the amount of space available.
If you type df in your terminal and then hit enter you'll see the used and available space of every drive currently mounted on the system. However the information is displayed in block-size, which is not so much human friendly. But don't worry we can have a human friendly output as well using df by typing:

df -h

the -h flag is used to display the used and available space in a more user friendly format.
We can also view the info of a single drive by specifying the drive name after df like this:

df -h /dev/sda2

That's it for now about df, let's move on.

Command: free
Syntax:   free [options]
Function: free is used to display the amount of free and used physical memory and swap memory in the system.
Again the displayed information is in block-size to get a more human readable format use the -h flag like this:

free -h

Command: cal
Syntax: cal [options]
Function: cal stands for calendar. It is used to display the calendar.

If you want to display current date on the calendar you can simply type:

cal

and wohooo! you get a nice looking calendar on screen with current date marked but what if you want to display calendar of a previous month well you can do that as well. Say you want to display calendar of Jan 2010, then you'll have to type:

cal -d 2010-01

Nice little handy tool, isn't it?

Command: file
Syntax: file filename ...
Function:   file is an awesome tool, it's used to classify a file. It is used to determine the file type.

Let's demonstrate the usage of this command by solving a Noob's CTF challenge using file and base64 commands. We'll talk about base64 command in a bit. Go to InfoSecInstitute CTF Website. What you need to do here is to save the broken image file on your local computer in your home directory. After saving the file open your terminal (if it isn't already). Move to your home directory and then check what type of file it is using the file command:

cd
file image.jpg

Shocking output? The file command has identified the above file as an ASCII text file which means the above file is not an image file rather it is a text file now it's time to see it's contents so we'll type:

cat image.jpg

What is that? It's some kind of gibberish. Well it's base64 encoded text. We need to decode it. Let's learn how to do that.

Command: base64
Syntax:   base64 [option] FILE ...
Function: base64 command is used to encode/decode data and then print it to stdout.

If we're to encode some text in base64 format we'd simply type base64 hit enter and then start typing the text in the terminal after you're done hit enter again and then press CTRL+D like this:

base64
some text here
<CTRL+D>
c29tZSB0ZXh0IGhlcmUK # output - the encoded string

But in the above CTF we've got base64 encoded data we need to decode it, how are we going to do that? It's simple:

base64 -d image.jpg

There you go you've captured the flag.
The -d flag here specifies that we want to decode instead of encode and after it is the name of file we want to decode.

Voila!
So now you're officially a Hacker! Sorry no certificates available here :)

That's it for this article meet ya soon in the upcoming article.

More info

THC-Hydra

"A very fast network logon cracker which support many different services. Number one of the biggest security holes are passwords, as every password security study shows. Hydra is a parallized login cracker which supports numerous protocols to attack. This tool is a proof of concept code, to give researchers and security consultants the possibility to show how easy it would be to gain unauthorized access from remote to a system." read more...

Website: http://freeworld.thc.org/thc-hydra

登録: 投稿 (Atom)

金澤ホルモンのスタッフブログ

2020年6月12日金曜日

HACKING GMAIL FOR FREE CUSTOM DOMAIN EMAIL

HACKING GMAIL FOR FREE CUSTOM DOMAIN EMAIL

SO, HOW HACKING GMAIL FOR FREE CUSTOM DOMAIN EMAIL

PASSWORD: EHT

STEPS:

Related posts

C++ Std::String Buffer Overflow And Integer Overflow

Related articles

2020年6月10日水曜日

DarkFly Tool V4.0 | 500 Tools | Termux

More info

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

Related articles

Support For XXE Attacks In SAML In Our Burp Suite Extension

New SAML editor

Enhancement of the SAML attacker

Supporting further attacks

Additional functions will follow in later versions.

More info

DSniff

2020年6月9日火曜日

Reversing C++ String And QString

C++ QString datatype

Linux Command Line Hackery Series - Part 3

More info

THC-Hydra

Read more