Saturday, June 3, 2023

Top 5 Best TV Series Based On Hacking & Technology 2018

Top 5 Best TV Series Based On Hacking And Technology 2018

Well, if you are a tech fanatic then you will love watching TV shows which are based on hacking and technology. If you are a tech geek, then you will know that hacking stuff in movies/serials always generates glamor and mystery and adds that special oomph factor to the movie or Tv SHOW.

However, there are not much movies/ or TV serials made on hacking and technology. Technology is rapidly becoming the key point in human lives. The previous year we have seen how hackers had made their marks on giant companies. So, in this article, we are going to discuss top TV shows which have to hack as the central theme. So, have a look at the list.

#1 Mr. Robot

Mr. Robot: Best TV Series Based On Hacking & Technology 2018

Well, the reason why I listed Mr. Robot on the top is because this show has millions of followers and this is the first show that portrays an elite hacker. The elite hacker group uses computers, smartphones and many other technologies to penetrate secure network to take down evil corporation while being anonymous. The show displays the life of a young programmer named Elliot who works as a cyber-security engineer and a vigilante hacker by night.

#2 Silicon Valley

Silicon Valley

This TV series displays the tech and hacking with a bit of comic touch. The series shows the competition between techies in the high-tech gold rush of modern Silicon Valley. What's more interesting is the people who are more qualified are least successful whereas underdogs are making it big. This show is running successfully for three years now.

Read more;- How To Hack Any Game On Your Android Smartphones

#3 The IT Crowd

The IT Crowd

The IT Crowd is very popular series and is running successfully for eight years from 2006 to 2013. It is not like Mr.Robot it has its moments of hacks. The series shows the comedic adventures of a rag-tag group of technical support workers at a large corporation.

#4 Person Of Interest

Person Of Interest

It is one of the best TV series made till now. You will get to see the humor, twists, and lots of other things. In this show and intelligent programmer built and AI (Artificial intelligence) that helps to stop the crimes in the city. The show will definitely give you chills.

Read more;- Top 5 Free Online Courses To Learn Artificial Intelligence

#5 Chuck

Chuck: Best TV Series Based On Hacking & Technology 2018

The TV series was somehow popular and ran from 2007 to 2013. The show shows the character of a young hacker and nerd who accidentally downloads US Govt, secrets into his brain and there is where the story starts CIA and NSA agents protect him and at the same time exploit him.

More info

Web3 Smart Contract And Blockchain Hacking With Python Free Course Section 1

Below is the full playlist and the outline for Section 1 the Web3 Hacking in Python course.. This is the most in-depth python based web3 material I have seen anywhere online.

Section 1 is the foundational section of the course using python for web3 that covers the following topics and also assumes that you have already taken my smart contract hacking course from 2020.

Smart Contract and Blockchain Web3 Hacking in Python:

Section 1:

Smart Contract Interactions:

1. Simple Smart Contract Interactions

2. ERC20 Token Interactions

3. Wallet Interactions

4. Manual ByteCode Reversing

5. ByteCode Function BruteForce Automation

6. Automated Reversing and Disassembly

7. Transaction Signing

8. In Depth Manual Smart Contract Interactions

9. Asynchronous programming to monitor Contract Events

Homework Assignments

1. Uniswap Pair nested Contract Interactions

2. Attacking Smart Contract Pathways Manually with python

3. Analyze Bytecode and Determine what it Interactions

Network Interactions:

1. Blocks and transaction Filtering and Monitoring

2. Pending Transaction Subscriptions And Network Monitoring

3. Monitoring Smart Contract Mempool Transactions (Uniswap Routers)

Playlist:

https://www.youtube.com/watch?v=UBK2BoFv6Lo&list=PLCwnLq3tOElrubfUWHa1qKrJv1apO8Aag&index=1

Related word

Friday, June 2, 2023

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()

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.