joana&pedro

joana&pedro

Hackerhubb.blogspot.comRelated posts

joana&pedro

This file is an 32bits elf binary, compiled from go language (i guess ... coded by @nibble_ds ;)

The binary has some debugging symbols, which is very helpful to locate the functions and api calls.

GO source functions:

- main.main

- main.function.001

If the binary is executed with no params, it prints "Nope!", the bad guy message.

~/ncn$ ./inbincible

Nope!

Decompiling the main.main function I saw two things:

1. The Argument validation: Only one 16 bytes long argument is needed, otherwise the execution is finished.

2. The key IF, the decision to dexor and print byte by byte the "Nope!" string OR dexor and print "Yeah!"

The incoming channel will determine the final message.

Dexor and print each byte of the "Nope!" message.

This IF, checks 16 times if the go channel reception value is 0x01, in this case the app show the "Yeah!" message.

Go channels are a kind of thread-safe queue, a channel_send is like a push, and channel_receive is like a pop.

If we fake this IF the 16 times, we got the "Yeah!" message:

(gdb) b *0x8049118
(gdb) commands
>set {char *}0xf7edeef3 = 0x01
>c
>end

(gdb) r 1234567890123456
tarting program: /home/sha0/ncn/inbincible 1234567890123456
...
Yeah!

Ok, but the problem is not in main.main, is main.function.001 who must sent the 0x01 via channel.

This function xors byte by byte the input "1234567890123456" with a byte array xor key, and is compared with another byte array.

=> 0x8049456: xor %ebp,%ecx

This xor, encode the argument with a key byte by byte

The xor key can be dumped from memory but I prefer to use this macro:

(gdb) b *0x8049456
(gdb) commands
>i r ecx
>c
>end
(gdb) c

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x12 18

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x45 69

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x33 51

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x87 135

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x65 101

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x12 18

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x45 69

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x33 51

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x87 135

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x65 101

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x12 18

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x45 69

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x33 51

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x87 135

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x65 101

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x12 18

The result of the xor will compared with another array byte, each byte matched, a 0x01 will be sent.

The cmp of the xored argument byte,
will determine if the channel send 0 or 1

(gdb) b *0x0804946a
(gdb) commands
>i r al
>c
>end

At this point we have the byte array used to xor the argument, and the byte array to be compared with, if we provide an input that xored with the first byte array gets the second byte array, the code will send 0x01 by the channel the 16 times.

Now web have:

xorKey=[0x12,0x45,0x33,0x87,0x65,0x12,0x45,0x33,0x87,0x65,0x12,0x45,0x33,0x87,0x65,0x12]

mustGive=[0x55,0x75,0x44,0xb6,0x0b,0x33,0x06,0x03,0xe9,0x02,0x60,0x71,0x47,0xb2,0x44,0x33]

Xor is reversible, then we can get the input needed to dexor to the expected values in order to send 0x1 bytes through the go channel.

>>> x=''
>>> for i in range(len(xorKey)):
... x+= chr(xorKey[i] ^ mustGive[i])
...
>>> print x

G0w1n!C0ngr4t5!!

And that's the key :) let's try it:

~/ncn$ ./inbincible 'G0w1n!C0ngr4t5!!'
Yeah!

Got it!! thanx @nibble_ds for this funny crackme, programmed in the great go language. I'm also a golang lover.

More information

joana&pedro

In cooperation with the university Paderborn and Münster University of Applied Sciences, we discovered a new flaw in the specification of TLS. The vulnerability is called ALPACA and exploits a weakness in the authentication of TLS for cross-protocol attacks. The attack allows an attacker to steal cookies or perform cross-site-scripting (XSS) if the specific conditions for the attack are met.

TLS is an internet standard to secure the communication between servers and clients on the internet, for example that of web servers, FTP servers, and Email servers. This is possible because TLS was designed to be application layer independent, which allows its use in many diverse communication protocols.

ALPACA is an application layer protocol content confusion attack, exploiting TLS servers implementing different protocols but using compatible certificates, such as multi-domain or wildcard certificates. Attackers can redirect traffic from one subdomain to another, resulting in a valid TLS session. This breaks the authentication of TLS and cross-protocol attacks may be possible where the behavior of one protocol service may compromise the other at the application layer.

We investigate cross-protocol attacks on TLS in general and conducted a systematic case study on web servers, redirecting HTTPS requests from a victim's web browser to SMTP, IMAP, POP3, and FTP servers. We show that in realistic scenarios, the attacker can extract session cookies and other private user data or execute arbitrary JavaScript in the context of the vulnerable web server, therefore bypassing TLS and web application security.

We evaluated the real-world attack surface of web browsers and widely-deployed Email and FTP servers in lab experiments and with internet-wide scans. We find that 1.4M web servers are generally vulnerable to cross-protocol attacks, i.e., TLS application data confusion is possible. Of these, 114k web servers can be attacked using an exploitable application server. As a countermeasure, we propose the use of the Application Layer Protocol Negotiation (ALPN) and Server Name Indication (SNI) extensions in TLS to prevent these and other cross-protocol attacks.

Although this vulnerability is very situational and can be challenging to exploit, there are some configurations that are exploitable even by a pure web attacker. Furthermore, we could only analyze a limited number of protocols, and other attack scenarios may exist. Thus, we advise that administrators review their deployments and that application developers (client and server) implement countermeasures proactively for all protocols.

More information on ALPACA can be found on the website https://alpaca-attack.com/.

More information

joana&pedro

What is cyber security in hacking?

The term cyber security refers to the technologies and processes designed to defend computer system, software, networks & user data from unauthorized access, also from threats distributed through the internet by cybercriminals,terrorist groups of hacker.

Main types of cybersecurity are

Critical infrastructure security

Application security

Network Security

Cloud Security

Internet of things security.

These are the main types of cybersecurity used by cybersecurity expert to any organisation for safe and protect thier data from hack by a hacker.

Top Skills Required to become Cybersecurity Expert-

Problem Solving Skills

Communication Skill

Technical Strength & Aptitude

Desire to learn

Attention to Detail

Knowledge of security across various platforms

Knowledge of Hacking

Fundamental Computer Forensic Skill.

These skills are essential for become a cybersecurity expert.

Cyber cell and IT cell these are the department in our india which provide cybersecurity and looks into the matters related to cyber crimes to stop the crime because in this digitilization world cyber crime increasing day by day so our government of india also takes the immediate action to prevent the cybercrimes with the help of these departments and also arrest the victim and file a complain against him/her with the help of cyberlaw in our constitution.

More articles