Temos o brasileiro honesto e o brasileiro desonesto, mas a criatividade,
é uma coisa inerente ao povo como um todo.
E, assim como os brasileiros de bem, que têm uma certa visão, buscaram
formas de inovar ante essa crise. (conheço alguns que resolveram fazer
máscaras, e por aí vai...)
Dessa mesma forma, temos visto os brasileiros desonestos que também se
renovaram e saíram em busca de novas formas de ampliar o seu leque de
receita.
Não ignorando é claro, que dos brasileiros de bem, vimos muitos que
deram um jeito e passaram a repartir daquilo, que não lhes sobrava, ao
contrário disso, tiraram do seu próprio sustento para ajudar a outros.
No entanto, vemos aqueles que estavam acostumados a desviar a merenda
escolar, e tudo onde quer que eles pudessem meter a mão e tirar um naco
para si, aconteceu.
O Brasil é maravilhoso, tem um terreno muito fértil, como vemos até
pelos nomes dos escândalos que assolaram a nossa nação e suas origens:
- Escândalo das passagens aéreas;
- Escândalo do dossiê;
- Escândalo do Renangate;
- Escândalo dos Correios;
- Escândalo dos sanguessugas;
- Escândalo do mensalão;
- Operação Lava Jato;
- Operação Zelotes;
- Escândalo dos bingos;
- Agropecuária Capemi;
- Alexandre Romano;
- Apagão aéreo de 2006;
- Caso Delfin;
- Caso Erenice Guerra;
- Caso Gamecorp;
- Caso Lutfalla;
- Caso Proconsult;
- Crise dos vazamentos de maio de 2016;
- Denúncias contra Michel Temer pela Procuradoria-Geral da República;
- Dossiê Cayman;
- Escândalo da eletrificação da Estrada de Ferro Central do Brasil;
- Escândalo da parabólica;
- Escândalo do caso Alstom;
- Escândalo dos atos secretos;
- Escândalo da Nossa Caixa;
- Escândalo da quebra do sigilo bancário do caseiro Francenildo Costa;
- Escândalo dos sanguessugas;
- Escândalo do grampo do BNDES;
- Inquérito dos Portos;
- Mensalão tucano;
- Operação Acrônimo;
- Operação Carne Fraca;
- Operação Catilinárias;
- Operação Confraria;
- Operação Gabiru;
- Operação Mar de Lama;
- Operação Monte Carlo;
- Operação Saqueador;
- Operação Satiagraha;
- Operação Veiculação;
- Ronald Levinsohn;
- PTrolão;
E agora, tcham, tcham, tcham, tcham, que rufem os tambores, porque
finalmente, fica criado o grande e estrondoso Covidão.
Por conta disto o ilustre Ministro da Justiça, Sérgio Fernando Moro
registra em seu twitter a deflagração da primeira Operação contra o
COVIDÃO no Brasil.
Esta Operação foi, digamos assim, inaugurada na Paraíba, possivelmente
porque as primeiras investigações, provavelmente apontam para a Paraíba
como um dos celeiros, pelo menos, iniciais de políticos corruptos, que
resolveram fazer um "caixinha" dos recursos destinados ao enfrentamento
ao combate ao "Vírus Chinês.
Registrou o Ministro Sérgio Moro em sua conta de twitter oficial, no dia
23/04/2020: "Uma primeira Operação, realizada em conjunto com a CGU,
sobre possíveis desvios do emprego de recursos destinados ao combate do
novo coronavírus".
As quadrilhas criminosas que tomaram conta do País, tiveram apenas que
se travestir de políticos e de apaniguados, para conseguir meter a mão
no cofre público.
Não importa a eles se estarão tirando dinheiro da:
- Saúde (hospitais, medicamentos, enfim... principalmente com o
superfaturamento);
- Educação (merenda, material escolar, etc...);
- Segurança (superfaturamento de armas, ou mesmo, a compra de
equipamentos de quinta categoria, como já se viu de casos de coletes à
prova de balas, que segurava, talvez, a bala de yogurte lançada contra
ele; ou mesmo a compra de armas totalmente imprestáveis, que mascam ao
primeiro disparo...)
O objetivo dos quadrilheiros é apenas e tão somente, o desvio de
recursos destinados à preservação e ao bom andamento do tecido social em
seu perfeito funcionamento.
E foi dessa forma, que Roberto Jefferson durante a Ação Penal 470, ou,
"Mensalão", como ficou conhecida, disse ao ministro chefe da Casa Civil:
"Sai daí Zé"!
Bem, o Augusto Nunes perguntou sabiamente ao Roberto se ele diria essa
frase, ao Nhonho, ao Amigo do Amigo de meu Pai, ou ao Alcolumbre, ao que
ele respondeu que diria o mesmo aos três.
"Eu faço essa frase aos três...
Porque eles estão impedindo que o Regime Democrático do
Presidencialismo, que é Constitucional, que o Presidente da República
exerça, na sua plenitude, os poderes a ele conferidos pelo povo.
"Todo poder emana do povo e em seu nome é exercido!"
Esses três senhores, presidente do Senado, presidente da Câmara e
Presidente do STF, estão impedindo o Presidente da República de exercer
plenamente suas prerrogativas constitucionais."
(ap. Ely Silmar Vidal - Teólogo, Psicanalista, Jornalista e presidente
do CIEP - Clube de Imprensa Estado do Paraná)
Contato:
(41) 98514-8333 (OI)
(41) 99109-8374 (Vivo)
(41) 99821-2381 (WhatsApp)
Mensagem 23042020 - Vale a Pena Rememorar - (imagens da internet)
Que o Espírito Santo do Senhor nos oriente a todos para que possamos
iluminar um pouquinho mais o caminho de nossos irmãos, por isso contamos
contigo.
Se esta mensagem te foi útil, e achas que poderá ser útil a mais alguém,
ajude-nos:
(ficaremos muito gratos que, ao replicar o e-mail, seja preservada a fonte)
leia este texto completo e outros em:
[youtube=http://youtu.be/kBBI_HOYxIw]
http://www.portaldaradio.com
@elyvidal @radiocrista @pastorelyvidal @conipsip @CiepClube
#FalaPortaldaRadio #conipsi #cojae #dojae
sexta-feira, 24 de abril de 2020
quinta-feira, 23 de abril de 2020
CTF: FluxFingers4Future - Evil Corp Solution
For this years hack.lu CTF I felt like creating a challenge. Since I work a lot with TLS it was only natural for me to create a TLS challenge. I was informed that TLS challenges are quite uncommon but nevertheless I thought it would be nice to spice the competition up with something "unusual". The challenge mostly requires you to know a lot of details on how the TLS record layer and the key derivation works. The challenge was only solved by one team (0ops from China) during the CTF. Good job!
So let me introduce the challenge first.
You were called by the incident response team of Evil-Corp, the urgently need your help. Somebody broke into the main server of the company, bricked the device and stole all the files! Nothing is left! This should have been impossible. The hacker used some secret backdoor to bypass authentication. Without the knowledge of the secret backdoor other servers are at risk as well! The incident response team has a full packet capture of the incident and performed an emergency cold boot attack on the server to retrieve the contents of the memory (its a really important server, Evil Corp is always ready for such kinds of incidents). However they were unable to retrieve much information from the RAM, what's left is only some parts of the "key_block" of the TLS server. Can you help Evil-Corp to analyze the exploit the attacker used?
(Flag is inside of the attackers' secret message).
TT = Could not recover
key_block:
6B 4F 93 6A TT TT TT TT TT TT 00 D9 F2 9B 4C B0
2D 88 36 CF B0 CB F1 A6 7B 53 B2 00 B6 D9 DC EF
66 E6 2C 33 5D 89 6A 92 ED D9 7C 07 49 57 AD E1
TT TT TT TT TT TT TT TT 56 C6 D8 3A TT TT TT TT
TT TT TT TT TT TT TT TT 94 TT 0C EB 50 8D 81 C4
E4 40 B6 26 DF E3 40 9A 6C F3 95 84 E6 C5 86 40
49 FD 4E F2 A0 A3 01 06
So looking at the IP address and TCP ports we see that the attacker/client was 127.0.0.1:36674 and was talking with the Server 127.0.0.1:4433. When looking at the individual messages we can see that the message exchange looked something like this:
ENC HS MESSAGE .... ENC HS MESSAGE ->
<- SERVER HELLO, CERTIFICATE, SERVER HELLO DONE
ENC HS MESSAGE .... ENC HS MESSAGE CCS ENC HS MESSAGE, ENC HS MESSAGE ->
<-CCS, ENC HS MESSAGE
ENC HEARTBEAT ->
<- ENC HEARTBEAT
-> ENC APPLICATION DATA
<- INTERNAL ERROR ... INTERNAL ERROR
So this message exchange appears weird. Usually the client is supposed to send a ClientHello in the beginning of the connection, and not encrypted handshake messages. The same is true for the second flight of the client. Usually it transmits its ClientKeyExchange message here, then a ChangeCipherSpec message and finally its Finished message. If we click at the first flight of the client, we can also see some ASCII text fragments in its messages.
Furthermore we can assume that the message sent after the ChangeCipherSpec from the server is actually a TLS Finished message.
Since we cannot read a lot from the messages the client is sending (in Wireshark at least), we can look at the messages the server is sending to get a better hold of what is going on. In the ServerHello message the server selects the parameters for the connection. This reveals that this is indeed a TLS 1.1 connection with TLS_RSA_WITH_AES_256_CBC_SHA , no compression and the Heartbeat Extension negotiated. We can also see that the ServerRandom is: 1023047c60b420bb3321d9d47acb933dbe70399bf6c92da33af01d4fb770e98c (note that it is always 32 bytes long, the UNIX time is part of the ServerRandom).
Looking at the certificate the server sent we can see that the server used a self-signed certificate for Evil.corp.com with an 800-bit RSA modulus:
00ad87f086a4e1acd255d1d77324a05ea7d250f285f3a6de35b9f07c5d083add5166677425b8335328255e7b562f944d55c56ff084f4316fdc9e3f5b009fefd65015a5ca228c94e3fd35c6aba83ea4e20800a34548aa36a5d40e3c7496c65bdbc864e8f161
and the public exponent 65537.
If you pay very close attention to the handshake you can see another weird thing. The size of the exchanged HeartbeatMessages is highly uneven. The client/attacker sent 3500 bytes, the server is supposed to decrypt these messages, and reflect the contents of them. However, the Server sent ~64000 bytes instead. The heartbeat extension became surprisingly well known in 2014, due to the Heartbleed bug in OpenSSL. The bug causes a buffer over-read on the server, causing it to reflect parts of its memory content in return to malicious heartbeat requests. This is a good indicator that this bug might play a role in this challenge.
But what is this key_block thing we got from the incident response team? TLS 1.1 CBC uses 4 symmetric keys in total. Both parties derive these keys from the "master secret" as the key_block. This key_block is then chunked into the individual keys. You can imagine the key_block as some PRF output and both parties knowing which parts of the output to use for which individual key. In TLS 1.1 CBC the key_block is chunked as follows: The first N bytes are the client_write_MAC key, the next N bytes are the server_write_MAC key, the next P bytes are the client_write key and the last P bytes are the server_write key. N is the length of the HMAC key (which is at the time of writing for all cipher suites the length of the HMAC) and P is the length of the key for the block cipher.
In the present handshake AES-256 was negotiated as the block cipher and SHA (SHA-1) was negotiated for the HMAC. This means that N is 20 (SHA-1 is 20 bytes) and P is 32 (AES-256 requires 32 bytes of key material).
Looking at the given key_block we can chunk it into the individual keys:
client_write_MAC = 6B4F936ATTTTTTTTTTTT00D9F29B4CB02D8836CF
server_write_MAC = B0CBF1A67B53B200B6D9DCEF66E62C335D896A92
client_write = EDD97C074957ADE1TTTTTTTTTTTTTTTT56C6D83ATTTTTTTTTTTTTTTTTTTTTTTT
server_write = 94TT0CEB508D81C4E440B626DFE3409A6CF39584E6C5864049FD4EF2A0A30106
Since not all parts of the key_block are present, we can see that we actually have 14/20 bytes of the client_write_MAC key, the whole server_write_MAC key, 12/32 bytes of the client_write key and 31/32 bytes of the server_write key.
The client_write_MAC key is used in the HMAC computations from the client to the server (the server uses the same key to verify the HMAC),
The server_write_MAC key is used in the HMAC computations from the server to the client (the client uses the same key to verify the HMAC),
The client_write key is used to encrypt messages from the client to the server, while the server_write key is used to encrypt messages from the server to the client.
So looking at the keys we could compute HMAC's from the client if we could guess the remaining 6 bytes. We could compute HMAC's from the server directly, we have not enough key material to decrypt the client messages, but we could decrypt server messages if we brute-forced one byte of the server_write key. But how would you brute force this byte? When do we know when we got the correct key? Lets look at how the TLS record layer works to find out :)
This means, that if we want to decrypt a message we know that if we used the correct key the message should always have a correct padding. If we are unsure we could even check the HMAC with the server_write_MAC key.
In TLS 1.0 - TLS 1.2 the padding looks like this:
1 byte padding : 00
2 bytes padding: 01 01
3 bytes padding: 02 02 02
4 bytes padding: 03 03 03 03
...
So if we guessed the correct key we know that the plaintext has to have valid padding.
An ideal candidate for our brute force attack is the server Finished message. So lets use that to check our key guesses.
The ciphertext looks like this:
0325f41d3ebaf8986da712c82bcd4d55c3bb45c1bc2eacd79e2ea13041fc66990e217bdfe4f6c25023381bab9ddc8749535973bd4cacc7a4140a14d78cc9bddd
The first 16 bytes of the ciphertext are the IV:
IV: 0325f41d3ebaf8986da712c82bcd4d55
Therefore the actual ciphertext is:
Ciphertext: c3bb45c1bc2eacd79e2ea13041fc66990e217bdfe4f6c25023381bab9ddc8749535973bd4cacc7a4140a14d78cc9bddd
The 256 key candidates are quick to check, and it is revealed that 0xDC was the missing byte.
(The plaintext of the Finished is 1400000C455379AAA141E1B9410B413320C435DEC948BFA451C64E4F30FE5F6928B816CA0B0B0B0B0B0B0B0B0B0B0B0B)
Now that we have the full server_write key we can use it to decrypt the heartbeat records.
This is done in the same way as with the Finished. Looking at the decrypted heartbeat messages we can see a lot of structured data, which is an indicator that we are actually dealing
with the Heartbleed bug. If we convert the content of the heartbeat messages to ASCII we can actually see that the private key of the server is PEM encoded in the first heartbeat message.
Note: This is different to a real heartbeat exploit. Here you don't usually get the private key nicely encoded but have to extract it using the coppersmith's attack or similar things. I did not want to make this challenge even harder so I was so nice to write it to the memory for you :)
The private key within the Heartbeat messages looks like this:
-----BEGIN RSA PRIVATE KEY-----
MIIB3gIBAAJlAK2H8Iak4azSVdHXcySgXqfSUPKF86beNbnwfF0IOt1RZmd0Jbgz
UyglXntWL5RNVcVv8IT0MW/cnj9bAJ/v1lAVpcoijJTj/TXGq6g+pOIIAKNFSKo2
pdQOPHSWxlvbyGTo8WECAwEAAQJkJj95P2QmLb5qlgbj5SXH1zufBeWKb7Q4qVQd
RTAkMVXYuWK7UZ9Wa9nYulyjvg9RoWOO+SaDNqhiTWKosQ+ZrvG3A1TDMcVZSkPx
bXCuhhRpp4j0T9levQi0s8tR1YuFzVFi8QIzANNLrgK2YOJiDlyu78t/eVbBey4m
uh2xaxvEd8xGX4bIBlTuWlKIqwPNxE8fygmv4uHFAjMA0j7Uk1ThY+UCYdeCm4/P
eVqkPYu7jNTHG2TGr/B6hstxyFpXBlq6MJQ/qPdRXLkLFu0CMwCf/OLCTQPpBiQn
y5HoPRpMNW4m0M4F46vdN5MaCoMUU+pvbpbXfYI3/BrTapeZZCNfnQIzAJ7XzW9K
j8cTPIuDcS/qpQvAiZneOmKaV5vAtcQzYb75cgu3BUzNuyH8v2P/Br+RJmm5AjMA
jp9N+xdEm4dW51lyUp6boVU6fxZimfYRfYANU2bVFmbsSAU9jzjWb0BuXexKKcX7
XGo=
-----END RSA PRIVATE KEY-----
We should store it in a file and decode it with OpenSSL to get the actual key material.
>> openssl rsa -in key.pem -text -noout
RSA Private-Key: (800 bit, 2 primes)
modulus:
00:ad:87:f0:86:a4:e1:ac:d2:55:d1:d7:73:24:a0:
5e:a7:d2:50:f2:85:f3:a6:de:35:b9:f0:7c:5d:08:
3a:dd:51:66:67:74:25:b8:33:53:28:25:5e:7b:56:
2f:94:4d:55:c5:6f:f0:84:f4:31:6f:dc:9e:3f:5b:
00:9f:ef:d6:50:15:a5:ca:22:8c:94:e3:fd:35:c6:
ab:a8:3e:a4:e2:08:00:a3:45:48:aa:36:a5:d4:0e:
3c:74:96:c6:5b:db:c8:64:e8:f1:61
publicExponent: 65537 (0x10001)
privateExponent:
26:3f:79:3f:64:26:2d:be:6a:96:06:e3:e5:25:c7:
d7:3b:9f:05:e5:8a:6f:b4:38:a9:54:1d:45:30:24:
31:55:d8:b9:62:bb:51:9f:56:6b:d9:d8:ba:5c:a3:
be:0f:51:a1:63:8e:f9:26:83:36:a8:62:4d:62:a8:
b1:0f:99:ae:f1:b7:03:54:c3:31:c5:59:4a:43:f1:
6d:70:ae:86:14:69:a7:88:f4:4f:d9:5e:bd:08:b4:
b3:cb:51:d5:8b:85:cd:51:62:f1
prime1:
00:d3:4b:ae:02:b6:60:e2:62:0e:5c:ae:ef:cb:7f:
79:56:c1:7b:2e:26:ba:1d:b1:6b:1b:c4:77:cc:46:
5f:86:c8:06:54:ee:5a:52:88:ab:03:cd:c4:4f:1f:
ca:09:af:e2:e1:c5
prime2:
00:d2:3e:d4:93:54:e1:63:e5:02:61:d7:82:9b:8f:
cf:79:5a:a4:3d:8b:bb:8c:d4:c7:1b:64:c6:af:f0:
7a:86:cb:71:c8:5a:57:06:5a:ba:30:94:3f:a8:f7:
51:5c:b9:0b:16:ed
exponent1:
00:9f:fc:e2:c2:4d:03:e9:06:24:27:cb:91:e8:3d:
1a:4c:35:6e:26:d0:ce:05:e3:ab:dd:37:93:1a:0a:
83:14:53:ea:6f:6e:96:d7:7d:82:37:fc:1a:d3:6a:
97:99:64:23:5f:9d
exponent2:
00:9e:d7:cd:6f:4a:8f:c7:13:3c:8b:83:71:2f:ea:
a5:0b:c0:89:99:de:3a:62:9a:57:9b:c0:b5:c4:33:
61:be:f9:72:0b:b7:05:4c:cd:bb:21:fc:bf:63:ff:
06:bf:91:26:69:b9
coefficient:
00:8e:9f:4d:fb:17:44:9b:87:56:e7:59:72:52:9e:
9b:a1:55:3a:7f:16:62:99:f6:11:7d:80:0d:53:66:
d5:16:66:ec:48:05:3d:8f:38:d6:6f:40:6e:5d:ec:
4a:29:c5:fb:5c:6a
So now we got the private key. But what do we do with it? Since this is an RSA handshake we should be able to decrypt the whole session (RSA is not perfect forward secure). Loading it into Wireshark does not work, as Wireshark is unable to read the messages sent by the client. What is going on there?
So if you do not yet have a good idea of what the record layer is for, you can imagine it like envelops. If someone wants to send some bytes, you have to put them in an envelop and transmit them. Usually implementations use one big envelop for every message, however you can also send a single message in multiple envelops.
The attacker did exactly that. He fragmented its messages into multiple records. This is not very common for handshake messages but fine according to the specification and accepted by almost all implementations. However, Wireshark is unable to decode these kinds of messages and therefore unable to use our private key to decrypt the connection. So we have to do this step manually.
So each record has the following fields:
Type | Version | Length | Data
If we want to reconstruct the ClientHello message we have to get all the data fields of the records of the first flight and decode them.
This is simply done by clicking on each record in Wireshark and concatenating the data fields. This step is at least on my Wireshark version (3.0.5) not very easy as the copying is actually buggy, and Wireshark is not copying the correct bytes.
As you can see in the image, the record is supposed to have a length of 8 bytes, but Wireshark is only copying 4 bytes. I am not sure if this bug is actually only in my version or affects all Wireshark versions. Instead of copying the records individually I therefore copied the whole TCP payload and chunked it manually into the individual records.
16030200080100009e03020000
160302000800000000004e6f62
16030200086f64796b6e6f7773
1603020008696d616361740000
16030200080000000000002053
1603020008746f70206c6f6f6b
1603020008696e67206e6f7468
1603020008696e6720746f2066
1603020008696e646865726500
16030200080200350100005300
16030200080f00010113370015
16030200084576696c436f7270
1603020008206b696c6c732070
1603020008656f706c65000d00
16030200082c002a0102020203
16030200080204020502060201
16030200080102010301040105
16030200080106010103020303
160302000803040305030603ed
1603020008edeeeeefefff0100
16030200020100
If we structure this data it looks like this:
Type Version Length Payload
16 0302 0008 0100009e03020000
16 0302 0008 00000000004e6f62
16 0302 0008 6f64796b6e6f7773
16 0302 0008 696d616361740000
16 0302 0008 0000000000002053
16 0302 0008 746f70206c6f6f6b
16 0302 0008 696e67206e6f7468
16 0302 0008 696e6720746f2066
16 0302 0008 696e646865726500
16 0302 0008 0200350100005300
16 0302 0008 0f00010113370015
16 0302 0008 4576696c436f7270
16 0302 0008 206b696c6c732070
16 0302 0008 656f706c65000d00
16 0302 0008 2c002a0102020203
16 0302 0008 0204020502060201
16 0302 0008 0102010301040105
16 0302 0008 0106010103020303
16 0302 0008 03040305030603ed
16 0302 0008 edeeeeefefff0100
16 0302 0002 0100
The actual message is the concatenation of the record payloads:
0100009e0302000000000000004e6f626f64796b6e6f7773696d6163617400000000000000002053746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e64686572650002003501000053000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100
So what is left is to parse this message. There is an easy way on how to do this an a labor intensive manual way. Lets do the manual process first :) .
We know from the record header that his message is in fact a handshake message (0x16).
According to the specification handshake messages look like this:
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
This is RFC speak for: Each handshake message starts with a type field which says which handshake message this is, followed by a 3 byte length field which determines the length of rest of the handshake message.
So in our case the msg_type is 0x01 , followed by a 3 Byte length field (0x00009e, 158[base10]). 0x01 means ClientHello (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-7). This means we have to parse the bytes after the length field as a ClientHello.
{
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello;
This means: The next 2 bytes are the ProtocolVersion, the next 32 bytes are the ClientRandom, the next byte is the SessionID Length, the next SessionID Length many bytes are the SessionID, the next 2 bytes are the CipherSuite Length bytes, followed by CipherSuite Length many CipherSuites, followed by a 1 byte Compression Length field, followed by Compression Length many CompressionBytes followed by a 2 byte Extension Length field followed by extension length many ExtensionBytes. So lets try to parse this:
Handshakye Type : 01
Handshake Length : 00009e
ProtocolVersion : 0302
ClientRandom : 000000000000004e6f626f64796b6e6f7773696d616361740000000000000000
SessionID Length : 20
SessionID : 53746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e6468657265
CipherSuite Length: 0002
CipherSuites : 0035
Compression Length: 01
CompressionBytes : 00
Extension Length : 0053
ExtensionBytes: : 000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100
This is manual parsing is the slow method of dealing with this. Instead of looking at the specification to parse this message we could also compare the message structure to another ClientHello. This eases this process a lot. What we could also do is record the transmission of this message as a de-fragmented message to something and let Wireshark decode it for us. To send the de-fragmented message we need to create a new record header ourselves. The record should look like this:
Type : 16
Version: 0302
Length : 00A2
Payload: 0100009e0302000000000000004e6f626f64796b6e6f7773696d6163617400000000000000002053746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e64686572650002003501000053000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100
To send this record we can simply use netcat:
echo '16030200A20100009e0302000000000000004e6f626f64796b6e6f7773696d6163617400000000000000002053746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e64686572650002003501000053000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100' | xxd -r -p | nc localhost 4433
Now we can use Wireshark to parse this message. As we can see now, the weired ASCII fragments we could see in the previous version are actually the ClientRandom, the SessionID, and a custom extension from the attacker. Now that we have de-fragmented the message, we know the ClientRandom: 000000000000004e6f626f64796b6e6f7773696d616361740000000000000000
Now that we have de-fragmented the first flight from the attacker, we can de-fragment the second flight from the client. We can do this in the same fashion as we de-fragmented the ClientHello.
16 0302 0008 1000006600645de1
16 0302 0008 66a6d3669bf21936
16 0302 0008 5ef3d35410c50283
16 0302 0008 c4dd038a1b6fedf5
16 0302 0008 26d5b193453d796f
16 0302 0008 6e63c144bbda6276
16 0302 0008 3740468e21891641
16 0302 0008 0671318e83da3c2a
16 0302 0008 de5f6da6482b09fc
16 0302 0008 a5c823eb4d9933fe
16 0302 0008 ae17d165a6db0e94
16 0302 0008 bb09574fc1f7b8ed
16 0302 0008 cfbcf9e9696b6173
16 0302 0002 f4b6
14 0302 0001 01
16 0302 0030 cbe6bf1ae7f2bc40a49709a06c0e3149a65b8cd93c2525b5bfa8f696e29880d3447aef3dc9a996ca2aff8be99b1a4157
16 0302 0030 9bf02969ca42d203e566bcc696de08fa80e0bfdf44b1b315aed17fe867aed6d0d600c73de59c14beb74b0328eacadcf9
Note that his time we have 3 record groups. First there is chain of handshake records, followed by a ChangeCipherSpec record, followed by 2 more handshake records. The TLS specification forbids that records of different types are interleaved. This means that the first few records a probably forming a group of messages. The ChangeCipherSpec record is telling the server that subsequent messages are encrypted. This seems to be true, since the following records do not appear to be plaintext handshake messages.
So lets de-fragment the first group of records by concatenating their payloads:
1000006600645de166a6d3669bf219365ef3d35410c50283c4dd038a1b6fedf526d5b193453d796f6e63c144bbda62763740468e218916410671318e83da3c2ade5f6da6482b09fca5c823eb4d9933feae17d165a6db0e94bb09574fc1f7b8edcfbcf9e9696b6173f4b6
Since this is a handshake message, we know that the first byte should tell us which handshake message this is. 0x10 means this is a ClientKeyExchange message. Since we already know that TLS_RSA_WITH_AES_256_CBC_SHA was negotiated for this connection, we know that this is an RSA ClientKeyExchange message.
These messages are supposed to look like this (I will spare you the lengthy RFC definition):
Type (0x10)
Length (Length of the content) (3 bytes)
EncryptedPMS Length(Length of the encrypted PMS) (2 bytes)
EncrpytedPMS (EncryptedPMS Length many bytes)
For our message this should look like this:
Type: 10
Length: 000066
Encrypted PMS Length: 0064
Encrypted PMS: 5de166a6d3669bf219365ef3d35410c50283c4dd038a1b6fedf526d5b193453d796f6e63c144bbda62763740468e218916410671318e83da3c2ade5f6da6482b09fca5c823eb4d9933feae17d165a6db0e94bb09574fc1f7b8edcfbcf9e9696b6173f4b6
Now that we got the Encrypted PMS we can decrypt it with the private key. Since the connection negotiated RSA as the key exchange algorithm this is done with:
encPMS^privKey mod modulus = plainPMS
We can solve this equation with the private key from the leaked PEM file.
2445298227328938658090475430796587247849533931395726514458166123599560640691186073871766111778498132903314547451268864032761115999716779282639547079095457185023600638251088359459150271827705392301109265654638212139757207501494756926838535350 ^ 996241568615939319506903357646514527421543094912647981212056826138382708603915022492738949955085789668243947380114192578398909946764789724993340852568712934975428447805093957315585432465710754275221903967417599121549904545874609387437384433 mod 4519950410687629988405948449295924027942240900746985859791939647949545695657651701565014369207785212702506305257912346076285925743737740481250261638791708483082426162177210620191963762755634733255455674225810981506935192783436252402225312097
Solving this equation gives us:
204742908894949049937193473353729060739551644014729690547520028508481967333831905155391804994508783506773012994170720979080285416764402813364718099379387561201299457228993584122400808905739026823578773289385773545222916543755807247900961
in hexadecimal this is:
00020325f41d3ebaf8986da712c82bcd4d554bf0b54023c29b624de9ef9c2f931efc580f9afb081b12e107b1e805f2b4f5f0f1000302476574204861636b6564204e6f6f622c20796f752077696c6c206e65766572206361746368206d65212121212121
The PMS is PKCS#1.5 encoded. This means that it is supposed to start with 0x0002 followed by a padding which contains no 0x00 bytes, followed by a separator 0x00 byte followed by a payload. In TLS, the payload has to be exactly 48 bytes long and has to start with the highest proposed protocol version of the client. We can see that this is indeed the case for our decrypted payload. The whole decrypted payload is the PMS for the connection.
This results in the PMS: 0302476574204861636b6564204e6f6f622c20796f752077696c6c206e65766572206361746368206d65212121212121 (which besides the protocol version is also ASCII :) )
Now that we have the PMS its time to revisit the key scheduling in TLS. We already briefly touched it but here is a overview:
As you can see, we first have to compute the master secret. With the master secret we can reconstruct the key_block. If we have computed the key_block, we can finally get the client_write key and decrypt the message from the attacker.
master secret = PRF ( PMS, "master secret", ClientRandom | ServerRandom)
key_block = PRF (master_secret, "key expansion", ServerRandom | ClientRandom )
Where "master secret" and "key expansion" are literally ASCII Strings.
Note that in the key_block computation ClientRandom and ServerRandom are exchanged.
To do this computation we can either implement the PRF ourselfs, or easier, steal it from somewhere. The PRF in TLS 1.1 is the same as in TLS 1.0. Good places to steal from are for example openssl (C/C++), the scapy project (python), the TLS-Attacker project (java) or your favourite TLS library. The master secret is exactly 48 bytes long. The length of the key_block varies depending on the selected cipher suite and protocol version. In our case we need 2 * 20 bytes (for the 2 HMAC keys) + 2 * 32 bytes (for the 2 AES keys) = 104 bytes.
I will use the TLS-Attacker framework for this computation. The code will look like this:
This results in the following master secret: 292EABADCF7EFFC495825AED17EE7EA575E02DF0BAB7213EC1B246BE23B2E0912DA2B99C752A1F8BD3D833E8331D649F And the following key_block:
6B4F936ADE9B4010393B00D9F29B4CB02D8836CFB0CBF1A67B53B200B6D9DCEF66E62C335D896A92EDD97C074957ADE136D6BAE74AE8193D56C6D83ACDE6A3B365679C5604312A1994DC0CEB508D81C4E440B626DFE3409A6CF39584E6C5864049FD4EF2A0A30106
Now we can chunk our resulting key_block into its individual parts. This is done analogously to the beginning of the challenge.
client_write_mac key = 6B4F936ADE9B4010393B00D9F29B4CB02D8836CF
server_write_mac key = B0CBF1A67B53B200B6D9DCEF66E62C335D896A92
client_write key = EDD97C074957ADE136D6BAE74AE8193D56C6D83ACDE6A3B365679C5604312A19
server_write key = 94DC0CEB508D81C4E440B626DFE3409A6CF39584E6C5864049FD4EF2A0A30106
Now that we have the full client_write key we can use that key to decrypt the application data messages. But these messages are also fragmented. But since the messages are now encrypted, we cannot simply concatenate the payloads of the records, but we have to decrypt them individually and only concatenate the resulting plaintext.
Analogue to the decryption of the heartbeat message, the first 16 bytes of each encrypted record payload are used as an IV
IV, Ciphertext Plaintext
6297cb6d9afba63ec4c0dd7ac0184570 a9c605307eb5f8ccbe8bbc210ff1ff14943873906fad3eca017f49af8feaec87 557365723A20726FB181CF546350A88ACBE8D0248D6FF07675D1514E03030303
063c60d43e08c4315f261f8a4f06169a cdb5818d80075143afe83c79b570ab0b349b2e8748f8b767c54c0133331fb886 6F743B0A50617373D6F734D45FB99850CCAF32DF113914FC412C523603030303
cd839b95954fcadf1e60ee983cbe5c21 ac6f6e1fe34ae4b1214cded895db4746b8e38d7960d7d45cb001aab8e18c7fc7 3A20726F6F743B0A937048A265327642BD5626E00E4BC79618F9A95C03030303
8092d75f72b16cb23a856b00c4c39898 8df099441e10dca5e850398e616e4597170796b7202e2a8726862cd760ebacdf 6563686F20224F7769EACFBEEB5EE5D1F0B72306F8C78AD86CB4835003030303
8e9f83b015fce7f9c925b8b64abee426 224a5fbd2d9b8fc6ded34222a943ec0e8e973bcf125b81f918e391a22b4b0e65 6E6564206279204061736E93BFDC5103C8C2FE8C543A72B924212E8403030303
0e24ba11e41bfcf66452dc80221288ce a66fb3aed9bdc7e08a31a0e7f14e11ce0983ec3d20dd47c179425243b14b08c9 6963306E7A31223B84A3CAFA7980B461DE0A6410D6251551AE401DD903030303
0465fdb05b121cdc08fa01cdacb2c8f4 eff59402f4dbf35a85cc91a6d1264a895cd1b3d2014c91fbba03ec4c85d058c9 0A7375646F20726DB97422D8B30C54CC672FFEC3E9D771D4743D96B903030303
e2ddbbb83fe8318c41c26d57a5813fab 89549a874ff74d83e182de34ecf55fff1a57008afd3a29ef0d839b991143cd2a 202F202D72663B0A996F3F1789CB9B671223E73C66A0BA578D0C0F3203030303
524f5210190f73c984bd6a59b9cf424c b7f30fafe5ea3ac51b6757c51911e86b0aa1a6bbf4861c961f8463154acea315 0A666C61677B436868BF764B01D2CDCB2C06EA0DFC5443DABB6EC9AE03030303
32765985e2e594cddca3d0f45bd21f49 a5edfe89fdb3782e2af978585c0e27ba3ef90eb658304716237297f97e4e72bc 696D696368616E67FBF32127FA3AF2F97770DE5B9C6D376A254EF51E03030303
e0ae69b1fa54785dc971221fd92215fb 14e918a9e6e37139153be8cb9c16d2a787385746f9a80d0596580ba22eaf254e 61467233346B7D8BE8B903A167C44945E7676BF99D888A4B86FA8E0404040404
The plaintext then has to be de-padded and de-MACed.
Data HMAC Pad:
557365723A20726F B181CF546350A88ACBE8D0248D6FF07675D1514E 03030303
6F743B0A50617373 D6F734D45FB99850CCAF32DF113914FC412C5236 03030303
3A20726F6F743B0A 937048A265327642BD5626E00E4BC79618F9A95C 03030303
6563686F20224F77 69EACFBEEB5EE5D1F0B72306F8C78AD86CB48350 03030303
6E65642062792040 61736E93BFDC5103C8C2FE8C543A72B924212E84 03030303
6963306E7A31223B 84A3CAFA7980B461DE0A6410D6251551AE401DD9 03030303
0A7375646F20726D B97422D8B30C54CC672FFEC3E9D771D4743D96B9 03030303
202F202D72663B0A 996F3F1789CB9B671223E73C66A0BA578D0C0F32 03030303
0A666C61677B4368 68BF764B01D2CDCB2C06EA0DFC5443DABB6EC9AE 03030303
696D696368616E67 FBF32127FA3AF2F97770DE5B9C6D376A254EF51E 03030303
61467233346B7D 8BE8B903A167C44945E7676BF99D888A4B86FA8E 0404040404
This then results in the following data:
Data:
557365723A20726F6F743B0A506173733A20726F6F743B0A6563686F20224F776E656420627920406963306E7A31223B0A7375646F20726D202F202D72663B0A0A666C61677B4368696D696368616E6761467233346B7D8B
Which is ASCII for:
User: root;
Pass: root;
echo "Owned by @ic0nz1";
sudo rm / -rf;
flag{ChimichangaFr34k}
Honestly this was quite a journey. But this presented solution is the tedious manual way. There is also a shortcut with which you can skip most of the manual cryptographic operations.
ClientHello
0100009e0302000000000000004e6f626f64796b6e6f7773696d6163617400000000000000002053746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e64686572650002003501000053000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100
ClientKeyExchange:
1000006600645de166a6d3669bf219365ef3d35410c50283c4dd038a1b6fedf526d5b193453d796f6e63c144bbda62763740468e218916410671318e83da3c2ade5f6da6482b09fca5c823eb4d9933feae17d165a6db0e94bb09574fc1f7b8edcfbcf9e9696b6173f4b6
We should now add new (not fragmented) record header to the previously fragmented message. The messages sent from the server can stay as they are. The ApplicationData from the client can also stay the same. The messages should now look like this
ClientHello
16030200A20100009e0302000000000000004e6f626f64796b6e6f7773696d6163617400000000000000002053746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e64686572650002003501000053000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100
ServerHello / Certificate / ServerHelloDone
160302006A1000006600645de166a6d3669bf219365ef3d35410c50283c4dd038a1b6fedf526d5b193453d796f6e63c144bbda62763740468e218916410671318e83da3c2ade5f6da6482b09fca5c823eb4d9933feae17d165a6db0e94bb09574fc1f7b8edcfbcf9e9696b6173f4b61403020001011603020030cbe6bf1ae7f2bc40a49709a06c0e3149a65b8cd93c2525b5bfa8f696e29880d3447aef3dc9a996ca2aff8be99b1a415716030200309bf02969ca42d203e566bcc696de08fa80e0bfdf44b1b315aed17fe867aed6d0d600c73de59c14beb74b0328eacadcf9
ClientKeyExchange / ChangeCipherSpec / Finished
160302006A1000006600645de166a6d3669bf219365ef3d35410c50283c4dd038a1b6fedf526d5b193453d796f6e63c144bbda62763740468e218916410671318e83da3c2ade5f6da6482b09fca5c823eb4d9933feae17d165a6db0e94bb09574fc1f7b8edcfbcf9e9696b6173f4b61403020001011603020030cbe6bf1ae7f2bc40a49709a06c0e3149a65b8cd93c2525b5bfa8f696e29880d3447aef3dc9a996ca2aff8be99b1a415716030200309bf02969ca42d203e566bcc696de08fa80e0bfdf44b1b315aed17fe867aed6d0d600c73de59c14beb74b0328eacadcf9')
ApplicationData
1703020030063c60d43e08c4315f261f8a4f06169acdb5818d80075143afe83c79b570ab0b349b2e8748f8b767c54c0133331fb8861703020030cd839b95954fcadf1e60ee983cbe5c21ac6f6e1fe34ae4b1214cded895db4746b8e38d7960d7d45cb001aab8e18c7fc717030200308092d75f72b16cb23a856b00c4c398988df099441e10dca5e850398e616e4597170796b7202e2a8726862cd760ebacdf17030200308e9f83b015fce7f9c925b8b64abee426224a5fbd2d9b8fc6ded34222a943ec0e8e973bcf125b81f918e391a22b4b0e6517030200300e24ba11e41bfcf66452dc80221288cea66fb3aed9bdc7e08a31a0e7f14e11ce0983ec3d20dd47c179425243b14b08c917030200300465fdb05b121cdc08fa01cdacb2c8f4eff59402f4dbf35a85cc91a6d1264a895cd1b3d2014c91fbba03ec4c85d058c91703020030e2ddbbb83fe8318c41c26d57a5813fab89549a874ff74d83e182de34ecf55fff1a57008afd3a29ef0d839b991143cd2a1703020030524f5210190f73c984bd6a59b9cf424cb7f30fafe5ea3ac51b6757c51911e86b0aa1a6bbf4861c961f8463154acea315170302003032765985e2e594cddca3d0f45bd21f49a5edfe89fdb3782e2af978585c0e27ba3ef90eb658304716237297f97e4e72bc1703020030e0ae69b1fa54785dc971221fd92215fb14e918a9e6e37139153be8cb9c16d2a787385746f9a80d0596580ba22eaf254e
What we want to do now is create the following conversation:
CH->
<-SH, CERT, SHD
-> CKE, CCS, FIN
-> APP, APP ,APP
This will be enough for Wireshark to decrypt the traffic. However, since we removed some messages (the whole HeartbeatMessages) our HMAC's will be invalid.
We need to record an interleaved transmission of these message with Wireshark. I will use these simple python programs to create the traffic:
If we record these transmissions and tick the flag in Wireshark to ignore invalid HMAC's we can see the plaintext (if we added the private key in Wireshark).
If you have question in regards to the challenge you can DM me at @ic0nz1
Happy HackingMore info
So let me introduce the challenge first.
The Challenge
You were called by the incident response team of Evil-Corp, the urgently need your help. Somebody broke into the main server of the company, bricked the device and stole all the files! Nothing is left! This should have been impossible. The hacker used some secret backdoor to bypass authentication. Without the knowledge of the secret backdoor other servers are at risk as well! The incident response team has a full packet capture of the incident and performed an emergency cold boot attack on the server to retrieve the contents of the memory (its a really important server, Evil Corp is always ready for such kinds of incidents). However they were unable to retrieve much information from the RAM, what's left is only some parts of the "key_block" of the TLS server. Can you help Evil-Corp to analyze the exploit the attacker used?
(Flag is inside of the attackers' secret message).
TT = Could not recover
key_block:
6B 4F 93 6A TT TT TT TT TT TT 00 D9 F2 9B 4C B0
2D 88 36 CF B0 CB F1 A6 7B 53 B2 00 B6 D9 DC EF
66 E6 2C 33 5D 89 6A 92 ED D9 7C 07 49 57 AD E1
TT TT TT TT TT TT TT TT 56 C6 D8 3A TT TT TT TT
TT TT TT TT TT TT TT TT 94 TT 0C EB 50 8D 81 C4
E4 40 B6 26 DF E3 40 9A 6C F3 95 84 E6 C5 86 40
49 FD 4E F2 A0 A3 01 06
If you are not interested in the solution and want to try the challenge on your own first, do not read past this point. Spoilers ahead.
The Solution
So lets analyze first what we got. We have something called a "key_block" but we do not have all parts of it. Some of the bytes have been destroyed and are unknown to us. Additionally, we have a PCAP file with some weird messages in them. Lets look at the general structure of the message exchange first.
So looking at the IP address and TCP ports we see that the attacker/client was 127.0.0.1:36674 and was talking with the Server 127.0.0.1:4433. When looking at the individual messages we can see that the message exchange looked something like this:
ENC HS MESSAGE .... ENC HS MESSAGE ->
<- SERVER HELLO, CERTIFICATE, SERVER HELLO DONE
ENC HS MESSAGE .... ENC HS MESSAGE CCS ENC HS MESSAGE, ENC HS MESSAGE ->
<-CCS, ENC HS MESSAGE
ENC HEARTBEAT ->
<- ENC HEARTBEAT
-> ENC APPLICATION DATA
<- INTERNAL ERROR ... INTERNAL ERROR
So this message exchange appears weird. Usually the client is supposed to send a ClientHello in the beginning of the connection, and not encrypted handshake messages. The same is true for the second flight of the client. Usually it transmits its ClientKeyExchange message here, then a ChangeCipherSpec message and finally its Finished message. If we click at the first flight of the client, we can also see some ASCII text fragments in its messages.
Furthermore we can assume that the message sent after the ChangeCipherSpec from the server is actually a TLS Finished message.
Since we cannot read a lot from the messages the client is sending (in Wireshark at least), we can look at the messages the server is sending to get a better hold of what is going on. In the ServerHello message the server selects the parameters for the connection. This reveals that this is indeed a TLS 1.1 connection with TLS_RSA_WITH_AES_256_CBC_SHA , no compression and the Heartbeat Extension negotiated. We can also see that the ServerRandom is: 1023047c60b420bb3321d9d47acb933dbe70399bf6c92da33af01d4fb770e98c (note that it is always 32 bytes long, the UNIX time is part of the ServerRandom).
Looking at the certificate the server sent we can see that the server used a self-signed certificate for Evil.corp.com with an 800-bit RSA modulus:
00ad87f086a4e1acd255d1d77324a05ea7d250f285f3a6de35b9f07c5d083add5166677425b8335328255e7b562f944d55c56ff084f4316fdc9e3f5b009fefd65015a5ca228c94e3fd35c6aba83ea4e20800a34548aa36a5d40e3c7496c65bdbc864e8f161
and the public exponent 65537.
If you pay very close attention to the handshake you can see another weird thing. The size of the exchanged HeartbeatMessages is highly uneven. The client/attacker sent 3500 bytes, the server is supposed to decrypt these messages, and reflect the contents of them. However, the Server sent ~64000 bytes instead. The heartbeat extension became surprisingly well known in 2014, due to the Heartbleed bug in OpenSSL. The bug causes a buffer over-read on the server, causing it to reflect parts of its memory content in return to malicious heartbeat requests. This is a good indicator that this bug might play a role in this challenge.
But what is this key_block thing we got from the incident response team? TLS 1.1 CBC uses 4 symmetric keys in total. Both parties derive these keys from the "master secret" as the key_block. This key_block is then chunked into the individual keys. You can imagine the key_block as some PRF output and both parties knowing which parts of the output to use for which individual key. In TLS 1.1 CBC the key_block is chunked as follows: The first N bytes are the client_write_MAC key, the next N bytes are the server_write_MAC key, the next P bytes are the client_write key and the last P bytes are the server_write key. N is the length of the HMAC key (which is at the time of writing for all cipher suites the length of the HMAC) and P is the length of the key for the block cipher.
In the present handshake AES-256 was negotiated as the block cipher and SHA (SHA-1) was negotiated for the HMAC. This means that N is 20 (SHA-1 is 20 bytes) and P is 32 (AES-256 requires 32 bytes of key material).
Looking at the given key_block we can chunk it into the individual keys:
client_write_MAC = 6B4F936ATTTTTTTTTTTT00D9F29B4CB02D8836CF
server_write_MAC = B0CBF1A67B53B200B6D9DCEF66E62C335D896A92
client_write = EDD97C074957ADE1TTTTTTTTTTTTTTTT56C6D83ATTTTTTTTTTTTTTTTTTTTTTTT
server_write = 94TT0CEB508D81C4E440B626DFE3409A6CF39584E6C5864049FD4EF2A0A30106
Since not all parts of the key_block are present, we can see that we actually have 14/20 bytes of the client_write_MAC key, the whole server_write_MAC key, 12/32 bytes of the client_write key and 31/32 bytes of the server_write key.
The client_write_MAC key is used in the HMAC computations from the client to the server (the server uses the same key to verify the HMAC),
The server_write_MAC key is used in the HMAC computations from the server to the client (the client uses the same key to verify the HMAC),
The client_write key is used to encrypt messages from the client to the server, while the server_write key is used to encrypt messages from the server to the client.
So looking at the keys we could compute HMAC's from the client if we could guess the remaining 6 bytes. We could compute HMAC's from the server directly, we have not enough key material to decrypt the client messages, but we could decrypt server messages if we brute-forced one byte of the server_write key. But how would you brute force this byte? When do we know when we got the correct key? Lets look at how the TLS record layer works to find out :)
The Record Layer
TLS consists out of multiple protocols (Handshake, Alert, CCS, Application (and Heartbeat)). If one of those protocols wants to send any data, it has to pass this data to the record layer. The record layer will chunk this data, compress it if necessary, encrypt it and attach a "record header" to it.
This means, that if we want to decrypt a message we know that if we used the correct key the message should always have a correct padding. If we are unsure we could even check the HMAC with the server_write_MAC key.
In TLS 1.0 - TLS 1.2 the padding looks like this:
1 byte padding : 00
2 bytes padding: 01 01
3 bytes padding: 02 02 02
4 bytes padding: 03 03 03 03
...
So if we guessed the correct key we know that the plaintext has to have valid padding.
An ideal candidate for our brute force attack is the server Finished message. So lets use that to check our key guesses.
The ciphertext looks like this:
0325f41d3ebaf8986da712c82bcd4d55c3bb45c1bc2eacd79e2ea13041fc66990e217bdfe4f6c25023381bab9ddc8749535973bd4cacc7a4140a14d78cc9bddd
The first 16 bytes of the ciphertext are the IV:
IV: 0325f41d3ebaf8986da712c82bcd4d55
Therefore the actual ciphertext is:
Ciphertext: c3bb45c1bc2eacd79e2ea13041fc66990e217bdfe4f6c25023381bab9ddc8749535973bd4cacc7a4140a14d78cc9bddd
The 256 key candidates are quick to check, and it is revealed that 0xDC was the missing byte.
(The plaintext of the Finished is 1400000C455379AAA141E1B9410B413320C435DEC948BFA451C64E4F30FE5F6928B816CA0B0B0B0B0B0B0B0B0B0B0B0B)
Now that we have the full server_write key we can use it to decrypt the heartbeat records.
This is done in the same way as with the Finished. Looking at the decrypted heartbeat messages we can see a lot of structured data, which is an indicator that we are actually dealing
with the Heartbleed bug. If we convert the content of the heartbeat messages to ASCII we can actually see that the private key of the server is PEM encoded in the first heartbeat message.
Note: This is different to a real heartbeat exploit. Here you don't usually get the private key nicely encoded but have to extract it using the coppersmith's attack or similar things. I did not want to make this challenge even harder so I was so nice to write it to the memory for you :)
The private key within the Heartbeat messages looks like this:
-----BEGIN RSA PRIVATE KEY-----
MIIB3gIBAAJlAK2H8Iak4azSVdHXcySgXqfSUPKF86beNbnwfF0IOt1RZmd0Jbgz
UyglXntWL5RNVcVv8IT0MW/cnj9bAJ/v1lAVpcoijJTj/TXGq6g+pOIIAKNFSKo2
pdQOPHSWxlvbyGTo8WECAwEAAQJkJj95P2QmLb5qlgbj5SXH1zufBeWKb7Q4qVQd
RTAkMVXYuWK7UZ9Wa9nYulyjvg9RoWOO+SaDNqhiTWKosQ+ZrvG3A1TDMcVZSkPx
bXCuhhRpp4j0T9levQi0s8tR1YuFzVFi8QIzANNLrgK2YOJiDlyu78t/eVbBey4m
uh2xaxvEd8xGX4bIBlTuWlKIqwPNxE8fygmv4uHFAjMA0j7Uk1ThY+UCYdeCm4/P
eVqkPYu7jNTHG2TGr/B6hstxyFpXBlq6MJQ/qPdRXLkLFu0CMwCf/OLCTQPpBiQn
y5HoPRpMNW4m0M4F46vdN5MaCoMUU+pvbpbXfYI3/BrTapeZZCNfnQIzAJ7XzW9K
j8cTPIuDcS/qpQvAiZneOmKaV5vAtcQzYb75cgu3BUzNuyH8v2P/Br+RJmm5AjMA
jp9N+xdEm4dW51lyUp6boVU6fxZimfYRfYANU2bVFmbsSAU9jzjWb0BuXexKKcX7
XGo=
-----END RSA PRIVATE KEY-----
We should store it in a file and decode it with OpenSSL to get the actual key material.
>> openssl rsa -in key.pem -text -noout
RSA Private-Key: (800 bit, 2 primes)
modulus:
00:ad:87:f0:86:a4:e1:ac:d2:55:d1:d7:73:24:a0:
5e:a7:d2:50:f2:85:f3:a6:de:35:b9:f0:7c:5d:08:
3a:dd:51:66:67:74:25:b8:33:53:28:25:5e:7b:56:
2f:94:4d:55:c5:6f:f0:84:f4:31:6f:dc:9e:3f:5b:
00:9f:ef:d6:50:15:a5:ca:22:8c:94:e3:fd:35:c6:
ab:a8:3e:a4:e2:08:00:a3:45:48:aa:36:a5:d4:0e:
3c:74:96:c6:5b:db:c8:64:e8:f1:61
publicExponent: 65537 (0x10001)
privateExponent:
26:3f:79:3f:64:26:2d:be:6a:96:06:e3:e5:25:c7:
d7:3b:9f:05:e5:8a:6f:b4:38:a9:54:1d:45:30:24:
31:55:d8:b9:62:bb:51:9f:56:6b:d9:d8:ba:5c:a3:
be:0f:51:a1:63:8e:f9:26:83:36:a8:62:4d:62:a8:
b1:0f:99:ae:f1:b7:03:54:c3:31:c5:59:4a:43:f1:
6d:70:ae:86:14:69:a7:88:f4:4f:d9:5e:bd:08:b4:
b3:cb:51:d5:8b:85:cd:51:62:f1
prime1:
00:d3:4b:ae:02:b6:60:e2:62:0e:5c:ae:ef:cb:7f:
79:56:c1:7b:2e:26:ba:1d:b1:6b:1b:c4:77:cc:46:
5f:86:c8:06:54:ee:5a:52:88:ab:03:cd:c4:4f:1f:
ca:09:af:e2:e1:c5
prime2:
00:d2:3e:d4:93:54:e1:63:e5:02:61:d7:82:9b:8f:
cf:79:5a:a4:3d:8b:bb:8c:d4:c7:1b:64:c6:af:f0:
7a:86:cb:71:c8:5a:57:06:5a:ba:30:94:3f:a8:f7:
51:5c:b9:0b:16:ed
exponent1:
00:9f:fc:e2:c2:4d:03:e9:06:24:27:cb:91:e8:3d:
1a:4c:35:6e:26:d0:ce:05:e3:ab:dd:37:93:1a:0a:
83:14:53:ea:6f:6e:96:d7:7d:82:37:fc:1a:d3:6a:
97:99:64:23:5f:9d
exponent2:
00:9e:d7:cd:6f:4a:8f:c7:13:3c:8b:83:71:2f:ea:
a5:0b:c0:89:99:de:3a:62:9a:57:9b:c0:b5:c4:33:
61:be:f9:72:0b:b7:05:4c:cd:bb:21:fc:bf:63:ff:
06:bf:91:26:69:b9
coefficient:
00:8e:9f:4d:fb:17:44:9b:87:56:e7:59:72:52:9e:
9b:a1:55:3a:7f:16:62:99:f6:11:7d:80:0d:53:66:
d5:16:66:ec:48:05:3d:8f:38:d6:6f:40:6e:5d:ec:
4a:29:c5:fb:5c:6a
So now we got the private key. But what do we do with it? Since this is an RSA handshake we should be able to decrypt the whole session (RSA is not perfect forward secure). Loading it into Wireshark does not work, as Wireshark is unable to read the messages sent by the client. What is going on there?
De-fragmentation
So if you do not yet have a good idea of what the record layer is for, you can imagine it like envelops. If someone wants to send some bytes, you have to put them in an envelop and transmit them. Usually implementations use one big envelop for every message, however you can also send a single message in multiple envelops.
The attacker did exactly that. He fragmented its messages into multiple records. This is not very common for handshake messages but fine according to the specification and accepted by almost all implementations. However, Wireshark is unable to decode these kinds of messages and therefore unable to use our private key to decrypt the connection. So we have to do this step manually.
So each record has the following fields:
Type | Version | Length | Data
If we want to reconstruct the ClientHello message we have to get all the data fields of the records of the first flight and decode them.
This is simply done by clicking on each record in Wireshark and concatenating the data fields. This step is at least on my Wireshark version (3.0.5) not very easy as the copying is actually buggy, and Wireshark is not copying the correct bytes.
As you can see in the image, the record is supposed to have a length of 8 bytes, but Wireshark is only copying 4 bytes. I am not sure if this bug is actually only in my version or affects all Wireshark versions. Instead of copying the records individually I therefore copied the whole TCP payload and chunked it manually into the individual records.
16030200080100009e03020000
160302000800000000004e6f62
16030200086f64796b6e6f7773
1603020008696d616361740000
16030200080000000000002053
1603020008746f70206c6f6f6b
1603020008696e67206e6f7468
1603020008696e6720746f2066
1603020008696e646865726500
16030200080200350100005300
16030200080f00010113370015
16030200084576696c436f7270
1603020008206b696c6c732070
1603020008656f706c65000d00
16030200082c002a0102020203
16030200080204020502060201
16030200080102010301040105
16030200080106010103020303
160302000803040305030603ed
1603020008edeeeeefefff0100
16030200020100
If we structure this data it looks like this:
Type Version Length Payload
16 0302 0008 0100009e03020000
16 0302 0008 00000000004e6f62
16 0302 0008 6f64796b6e6f7773
16 0302 0008 696d616361740000
16 0302 0008 0000000000002053
16 0302 0008 746f70206c6f6f6b
16 0302 0008 696e67206e6f7468
16 0302 0008 696e6720746f2066
16 0302 0008 696e646865726500
16 0302 0008 0200350100005300
16 0302 0008 0f00010113370015
16 0302 0008 4576696c436f7270
16 0302 0008 206b696c6c732070
16 0302 0008 656f706c65000d00
16 0302 0008 2c002a0102020203
16 0302 0008 0204020502060201
16 0302 0008 0102010301040105
16 0302 0008 0106010103020303
16 0302 0008 03040305030603ed
16 0302 0008 edeeeeefefff0100
16 0302 0002 0100
The actual message is the concatenation of the record payloads:
0100009e0302000000000000004e6f626f64796b6e6f7773696d6163617400000000000000002053746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e64686572650002003501000053000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100
So what is left is to parse this message. There is an easy way on how to do this an a labor intensive manual way. Lets do the manual process first :) .
We know from the record header that his message is in fact a handshake message (0x16).
According to the specification handshake messages look like this:
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
This is RFC speak for: Each handshake message starts with a type field which says which handshake message this is, followed by a 3 byte length field which determines the length of rest of the handshake message.
So in our case the msg_type is 0x01 , followed by a 3 Byte length field (0x00009e, 158[base10]). 0x01 means ClientHello (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-7). This means we have to parse the bytes after the length field as a ClientHello.
{
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello;
This means: The next 2 bytes are the ProtocolVersion, the next 32 bytes are the ClientRandom, the next byte is the SessionID Length, the next SessionID Length many bytes are the SessionID, the next 2 bytes are the CipherSuite Length bytes, followed by CipherSuite Length many CipherSuites, followed by a 1 byte Compression Length field, followed by Compression Length many CompressionBytes followed by a 2 byte Extension Length field followed by extension length many ExtensionBytes. So lets try to parse this:
Handshakye Type : 01
Handshake Length : 00009e
ProtocolVersion : 0302
ClientRandom : 000000000000004e6f626f64796b6e6f7773696d616361740000000000000000
SessionID Length : 20
SessionID : 53746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e6468657265
CipherSuite Length: 0002
CipherSuites : 0035
Compression Length: 01
CompressionBytes : 00
Extension Length : 0053
ExtensionBytes: : 000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100
This is manual parsing is the slow method of dealing with this. Instead of looking at the specification to parse this message we could also compare the message structure to another ClientHello. This eases this process a lot. What we could also do is record the transmission of this message as a de-fragmented message to something and let Wireshark decode it for us. To send the de-fragmented message we need to create a new record header ourselves. The record should look like this:
Type : 16
Version: 0302
Length : 00A2
Payload: 0100009e0302000000000000004e6f626f64796b6e6f7773696d6163617400000000000000002053746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e64686572650002003501000053000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100
To send this record we can simply use netcat:
echo '16030200A20100009e0302000000000000004e6f626f64796b6e6f7773696d6163617400000000000000002053746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e64686572650002003501000053000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100' | xxd -r -p | nc localhost 4433
Now we can use Wireshark to parse this message. As we can see now, the weired ASCII fragments we could see in the previous version are actually the ClientRandom, the SessionID, and a custom extension from the attacker. Now that we have de-fragmented the message, we know the ClientRandom: 000000000000004e6f626f64796b6e6f7773696d616361740000000000000000
De-fragmenting the ClientKeyExchange message
Now that we have de-fragmented the first flight from the attacker, we can de-fragment the second flight from the client. We can do this in the same fashion as we de-fragmented the ClientHello.
16 0302 0008 1000006600645de1
16 0302 0008 66a6d3669bf21936
16 0302 0008 5ef3d35410c50283
16 0302 0008 c4dd038a1b6fedf5
16 0302 0008 26d5b193453d796f
16 0302 0008 6e63c144bbda6276
16 0302 0008 3740468e21891641
16 0302 0008 0671318e83da3c2a
16 0302 0008 de5f6da6482b09fc
16 0302 0008 a5c823eb4d9933fe
16 0302 0008 ae17d165a6db0e94
16 0302 0008 bb09574fc1f7b8ed
16 0302 0008 cfbcf9e9696b6173
16 0302 0002 f4b6
14 0302 0001 01
16 0302 0030 cbe6bf1ae7f2bc40a49709a06c0e3149a65b8cd93c2525b5bfa8f696e29880d3447aef3dc9a996ca2aff8be99b1a4157
16 0302 0030 9bf02969ca42d203e566bcc696de08fa80e0bfdf44b1b315aed17fe867aed6d0d600c73de59c14beb74b0328eacadcf9
Note that his time we have 3 record groups. First there is chain of handshake records, followed by a ChangeCipherSpec record, followed by 2 more handshake records. The TLS specification forbids that records of different types are interleaved. This means that the first few records a probably forming a group of messages. The ChangeCipherSpec record is telling the server that subsequent messages are encrypted. This seems to be true, since the following records do not appear to be plaintext handshake messages.
So lets de-fragment the first group of records by concatenating their payloads:
1000006600645de166a6d3669bf219365ef3d35410c50283c4dd038a1b6fedf526d5b193453d796f6e63c144bbda62763740468e218916410671318e83da3c2ade5f6da6482b09fca5c823eb4d9933feae17d165a6db0e94bb09574fc1f7b8edcfbcf9e9696b6173f4b6
Since this is a handshake message, we know that the first byte should tell us which handshake message this is. 0x10 means this is a ClientKeyExchange message. Since we already know that TLS_RSA_WITH_AES_256_CBC_SHA was negotiated for this connection, we know that this is an RSA ClientKeyExchange message.
These messages are supposed to look like this (I will spare you the lengthy RFC definition):
Type (0x10)
Length (Length of the content) (3 bytes)
EncryptedPMS Length(Length of the encrypted PMS) (2 bytes)
EncrpytedPMS (EncryptedPMS Length many bytes)
For our message this should look like this:
Type: 10
Length: 000066
Encrypted PMS Length: 0064
Encrypted PMS: 5de166a6d3669bf219365ef3d35410c50283c4dd038a1b6fedf526d5b193453d796f6e63c144bbda62763740468e218916410671318e83da3c2ade5f6da6482b09fca5c823eb4d9933feae17d165a6db0e94bb09574fc1f7b8edcfbcf9e9696b6173f4b6
Now that we got the Encrypted PMS we can decrypt it with the private key. Since the connection negotiated RSA as the key exchange algorithm this is done with:
encPMS^privKey mod modulus = plainPMS
We can solve this equation with the private key from the leaked PEM file.
2445298227328938658090475430796587247849533931395726514458166123599560640691186073871766111778498132903314547451268864032761115999716779282639547079095457185023600638251088359459150271827705392301109265654638212139757207501494756926838535350 ^ 996241568615939319506903357646514527421543094912647981212056826138382708603915022492738949955085789668243947380114192578398909946764789724993340852568712934975428447805093957315585432465710754275221903967417599121549904545874609387437384433 mod 4519950410687629988405948449295924027942240900746985859791939647949545695657651701565014369207785212702506305257912346076285925743737740481250261638791708483082426162177210620191963762755634733255455674225810981506935192783436252402225312097
Solving this equation gives us:
204742908894949049937193473353729060739551644014729690547520028508481967333831905155391804994508783506773012994170720979080285416764402813364718099379387561201299457228993584122400808905739026823578773289385773545222916543755807247900961
in hexadecimal this is:
00020325f41d3ebaf8986da712c82bcd4d554bf0b54023c29b624de9ef9c2f931efc580f9afb081b12e107b1e805f2b4f5f0f1000302476574204861636b6564204e6f6f622c20796f752077696c6c206e65766572206361746368206d65212121212121
The PMS is PKCS#1.5 encoded. This means that it is supposed to start with 0x0002 followed by a padding which contains no 0x00 bytes, followed by a separator 0x00 byte followed by a payload. In TLS, the payload has to be exactly 48 bytes long and has to start with the highest proposed protocol version of the client. We can see that this is indeed the case for our decrypted payload. The whole decrypted payload is the PMS for the connection.
This results in the PMS: 0302476574204861636b6564204e6f6f622c20796f752077696c6c206e65766572206361746368206d65212121212121 (which besides the protocol version is also ASCII :) )
Now that we have the PMS its time to revisit the key scheduling in TLS. We already briefly touched it but here is a overview:
As you can see, we first have to compute the master secret. With the master secret we can reconstruct the key_block. If we have computed the key_block, we can finally get the client_write key and decrypt the message from the attacker.
master secret = PRF ( PMS, "master secret", ClientRandom | ServerRandom)
key_block = PRF (master_secret, "key expansion", ServerRandom | ClientRandom )
Where "master secret" and "key expansion" are literally ASCII Strings.
Note that in the key_block computation ClientRandom and ServerRandom are exchanged.
To do this computation we can either implement the PRF ourselfs, or easier, steal it from somewhere. The PRF in TLS 1.1 is the same as in TLS 1.0. Good places to steal from are for example openssl (C/C++), the scapy project (python), the TLS-Attacker project (java) or your favourite TLS library. The master secret is exactly 48 bytes long. The length of the key_block varies depending on the selected cipher suite and protocol version. In our case we need 2 * 20 bytes (for the 2 HMAC keys) + 2 * 32 bytes (for the 2 AES keys) = 104 bytes.
I will use the TLS-Attacker framework for this computation. The code will look like this:
This results in the following master secret: 292EABADCF7EFFC495825AED17EE7EA575E02DF0BAB7213EC1B246BE23B2E0912DA2B99C752A1F8BD3D833E8331D649F And the following key_block:
6B4F936ADE9B4010393B00D9F29B4CB02D8836CFB0CBF1A67B53B200B6D9DCEF66E62C335D896A92EDD97C074957ADE136D6BAE74AE8193D56C6D83ACDE6A3B365679C5604312A1994DC0CEB508D81C4E440B626DFE3409A6CF39584E6C5864049FD4EF2A0A30106
Now we can chunk our resulting key_block into its individual parts. This is done analogously to the beginning of the challenge.
client_write_mac key = 6B4F936ADE9B4010393B00D9F29B4CB02D8836CF
server_write_mac key = B0CBF1A67B53B200B6D9DCEF66E62C335D896A92
client_write key = EDD97C074957ADE136D6BAE74AE8193D56C6D83ACDE6A3B365679C5604312A19
server_write key = 94DC0CEB508D81C4E440B626DFE3409A6CF39584E6C5864049FD4EF2A0A30106
Now that we have the full client_write key we can use that key to decrypt the application data messages. But these messages are also fragmented. But since the messages are now encrypted, we cannot simply concatenate the payloads of the records, but we have to decrypt them individually and only concatenate the resulting plaintext.
Analogue to the decryption of the heartbeat message, the first 16 bytes of each encrypted record payload are used as an IV
IV, Ciphertext Plaintext
6297cb6d9afba63ec4c0dd7ac0184570 a9c605307eb5f8ccbe8bbc210ff1ff14943873906fad3eca017f49af8feaec87 557365723A20726FB181CF546350A88ACBE8D0248D6FF07675D1514E03030303
063c60d43e08c4315f261f8a4f06169a cdb5818d80075143afe83c79b570ab0b349b2e8748f8b767c54c0133331fb886 6F743B0A50617373D6F734D45FB99850CCAF32DF113914FC412C523603030303
cd839b95954fcadf1e60ee983cbe5c21 ac6f6e1fe34ae4b1214cded895db4746b8e38d7960d7d45cb001aab8e18c7fc7 3A20726F6F743B0A937048A265327642BD5626E00E4BC79618F9A95C03030303
8092d75f72b16cb23a856b00c4c39898 8df099441e10dca5e850398e616e4597170796b7202e2a8726862cd760ebacdf 6563686F20224F7769EACFBEEB5EE5D1F0B72306F8C78AD86CB4835003030303
8e9f83b015fce7f9c925b8b64abee426 224a5fbd2d9b8fc6ded34222a943ec0e8e973bcf125b81f918e391a22b4b0e65 6E6564206279204061736E93BFDC5103C8C2FE8C543A72B924212E8403030303
0e24ba11e41bfcf66452dc80221288ce a66fb3aed9bdc7e08a31a0e7f14e11ce0983ec3d20dd47c179425243b14b08c9 6963306E7A31223B84A3CAFA7980B461DE0A6410D6251551AE401DD903030303
0465fdb05b121cdc08fa01cdacb2c8f4 eff59402f4dbf35a85cc91a6d1264a895cd1b3d2014c91fbba03ec4c85d058c9 0A7375646F20726DB97422D8B30C54CC672FFEC3E9D771D4743D96B903030303
e2ddbbb83fe8318c41c26d57a5813fab 89549a874ff74d83e182de34ecf55fff1a57008afd3a29ef0d839b991143cd2a 202F202D72663B0A996F3F1789CB9B671223E73C66A0BA578D0C0F3203030303
524f5210190f73c984bd6a59b9cf424c b7f30fafe5ea3ac51b6757c51911e86b0aa1a6bbf4861c961f8463154acea315 0A666C61677B436868BF764B01D2CDCB2C06EA0DFC5443DABB6EC9AE03030303
32765985e2e594cddca3d0f45bd21f49 a5edfe89fdb3782e2af978585c0e27ba3ef90eb658304716237297f97e4e72bc 696D696368616E67FBF32127FA3AF2F97770DE5B9C6D376A254EF51E03030303
e0ae69b1fa54785dc971221fd92215fb 14e918a9e6e37139153be8cb9c16d2a787385746f9a80d0596580ba22eaf254e 61467233346B7D8BE8B903A167C44945E7676BF99D888A4B86FA8E0404040404
The plaintext then has to be de-padded and de-MACed.
Data HMAC Pad:
557365723A20726F B181CF546350A88ACBE8D0248D6FF07675D1514E 03030303
6F743B0A50617373 D6F734D45FB99850CCAF32DF113914FC412C5236 03030303
3A20726F6F743B0A 937048A265327642BD5626E00E4BC79618F9A95C 03030303
6563686F20224F77 69EACFBEEB5EE5D1F0B72306F8C78AD86CB48350 03030303
6E65642062792040 61736E93BFDC5103C8C2FE8C543A72B924212E84 03030303
6963306E7A31223B 84A3CAFA7980B461DE0A6410D6251551AE401DD9 03030303
0A7375646F20726D B97422D8B30C54CC672FFEC3E9D771D4743D96B9 03030303
202F202D72663B0A 996F3F1789CB9B671223E73C66A0BA578D0C0F32 03030303
0A666C61677B4368 68BF764B01D2CDCB2C06EA0DFC5443DABB6EC9AE 03030303
696D696368616E67 FBF32127FA3AF2F97770DE5B9C6D376A254EF51E 03030303
61467233346B7D 8BE8B903A167C44945E7676BF99D888A4B86FA8E 0404040404
This then results in the following data:
Data:
557365723A20726F6F743B0A506173733A20726F6F743B0A6563686F20224F776E656420627920406963306E7A31223B0A7375646F20726D202F202D72663B0A0A666C61677B4368696D696368616E6761467233346B7D8B
Which is ASCII for:
User: root;
Pass: root;
echo "Owned by @ic0nz1";
sudo rm / -rf;
flag{ChimichangaFr34k}
Honestly this was quite a journey. But this presented solution is the tedious manual way. There is also a shortcut with which you can skip most of the manual cryptographic operations.
The Shortcut
After you de-fragmented the messages you can patch the PCAP file and then use Wireshark to decrypt the whole session. This way you can get the flag without performing any cryptographic operation after you got the private key. Alternatively you can replay the communication and record it with Wireshark. I will show you the replay of the messages. To recap the de-fragmented messages looks like this:ClientHello
0100009e0302000000000000004e6f626f64796b6e6f7773696d6163617400000000000000002053746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e64686572650002003501000053000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100
ClientKeyExchange:
1000006600645de166a6d3669bf219365ef3d35410c50283c4dd038a1b6fedf526d5b193453d796f6e63c144bbda62763740468e218916410671318e83da3c2ade5f6da6482b09fca5c823eb4d9933feae17d165a6db0e94bb09574fc1f7b8edcfbcf9e9696b6173f4b6
We should now add new (not fragmented) record header to the previously fragmented message. The messages sent from the server can stay as they are. The ApplicationData from the client can also stay the same. The messages should now look like this
ClientHello
16030200A20100009e0302000000000000004e6f626f64796b6e6f7773696d6163617400000000000000002053746f70206c6f6f6b696e67206e6f7468696e6720746f2066696e64686572650002003501000053000f000101133700154576696c436f7270206b696c6c732070656f706c65000d002c002a010202020302040205020602010102010301040105010601010302030303040305030603ededeeeeefefff01000100
ServerHello / Certificate / ServerHelloDone
160302006A1000006600645de166a6d3669bf219365ef3d35410c50283c4dd038a1b6fedf526d5b193453d796f6e63c144bbda62763740468e218916410671318e83da3c2ade5f6da6482b09fca5c823eb4d9933feae17d165a6db0e94bb09574fc1f7b8edcfbcf9e9696b6173f4b61403020001011603020030cbe6bf1ae7f2bc40a49709a06c0e3149a65b8cd93c2525b5bfa8f696e29880d3447aef3dc9a996ca2aff8be99b1a415716030200309bf02969ca42d203e566bcc696de08fa80e0bfdf44b1b315aed17fe867aed6d0d600c73de59c14beb74b0328eacadcf9
ClientKeyExchange / ChangeCipherSpec / Finished
160302006A1000006600645de166a6d3669bf219365ef3d35410c50283c4dd038a1b6fedf526d5b193453d796f6e63c144bbda62763740468e218916410671318e83da3c2ade5f6da6482b09fca5c823eb4d9933feae17d165a6db0e94bb09574fc1f7b8edcfbcf9e9696b6173f4b61403020001011603020030cbe6bf1ae7f2bc40a49709a06c0e3149a65b8cd93c2525b5bfa8f696e29880d3447aef3dc9a996ca2aff8be99b1a415716030200309bf02969ca42d203e566bcc696de08fa80e0bfdf44b1b315aed17fe867aed6d0d600c73de59c14beb74b0328eacadcf9')
ApplicationData
1703020030063c60d43e08c4315f261f8a4f06169acdb5818d80075143afe83c79b570ab0b349b2e8748f8b767c54c0133331fb8861703020030cd839b95954fcadf1e60ee983cbe5c21ac6f6e1fe34ae4b1214cded895db4746b8e38d7960d7d45cb001aab8e18c7fc717030200308092d75f72b16cb23a856b00c4c398988df099441e10dca5e850398e616e4597170796b7202e2a8726862cd760ebacdf17030200308e9f83b015fce7f9c925b8b64abee426224a5fbd2d9b8fc6ded34222a943ec0e8e973bcf125b81f918e391a22b4b0e6517030200300e24ba11e41bfcf66452dc80221288cea66fb3aed9bdc7e08a31a0e7f14e11ce0983ec3d20dd47c179425243b14b08c917030200300465fdb05b121cdc08fa01cdacb2c8f4eff59402f4dbf35a85cc91a6d1264a895cd1b3d2014c91fbba03ec4c85d058c91703020030e2ddbbb83fe8318c41c26d57a5813fab89549a874ff74d83e182de34ecf55fff1a57008afd3a29ef0d839b991143cd2a1703020030524f5210190f73c984bd6a59b9cf424cb7f30fafe5ea3ac51b6757c51911e86b0aa1a6bbf4861c961f8463154acea315170302003032765985e2e594cddca3d0f45bd21f49a5edfe89fdb3782e2af978585c0e27ba3ef90eb658304716237297f97e4e72bc1703020030e0ae69b1fa54785dc971221fd92215fb14e918a9e6e37139153be8cb9c16d2a787385746f9a80d0596580ba22eaf254e
What we want to do now is create the following conversation:
CH->
<-SH, CERT, SHD
-> CKE, CCS, FIN
-> APP, APP ,APP
This will be enough for Wireshark to decrypt the traffic. However, since we removed some messages (the whole HeartbeatMessages) our HMAC's will be invalid.
We need to record an interleaved transmission of these message with Wireshark. I will use these simple python programs to create the traffic:
If we record these transmissions and tick the flag in Wireshark to ignore invalid HMAC's we can see the plaintext (if we added the private key in Wireshark).
Challenge Creation
I used our TLS-Attacker project to create this challenge. With TLS-Attacker you can send arbitrary TLS messages with arbitrary content in an arbitrary order, save them in XML and replay them. The communication between the peers are therefore only two XML files which are loaded into TLS-Attacker talking to each other. I then copied parts of the key_block from the debug output and the challenge was completed :)If you have question in regards to the challenge you can DM me at @ic0nz1
Happy HackingMore info
Linux.Agent Malware Sample - Data Stealer
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 passwordquarta-feira, 22 de abril de 2020
Estado de torpor é o que nos guia
"Um dos conjuntos de gente mais corrupto do planeta que é o Senado
Federal." - (José Roberto Guzzo)
Já diziam os antigos: "O Congresso Nacional é um grande puteiro,
comandado por cornos de todos os lados".
Infelizmente eu não posso almejar o fechamento do Congresso, apesar de
ele ser o antro de tudo o que não presta.
Olavo de Carvalho em seu twitter escreveu:
"O AI-5 foi uma bosta, mas nunca o vi batendo em velhinhas inocentes ou
estrangulando epiléticos.
Quem faz isso são os líderes da sua democracia, ó jornalistas de merda."
Não preciso dizer quem é o presidente do STF e este outro antro, eu
tenho que aceitar que não pode ser fechado, porque isso fere a democracia.
O que não fere a democracia é exatamente os bandidos estarem ocupando
postos de comando e batendo em cidadãos de bem, algemando trabalhadores,
soltando criminosos e enfim, tungando a carteira do povo de bem. Isto,
não fere a democracia.
"Quando você ataca as instituições, você ataca a democracia." - (Dias
Toffoli - "Amigo do amigo do meu pai")
"Errado!
Instituições não são a democracia.
Instituições representam o Estado de Direito.
A Democracia é a vontade popular.
Atacar a vontade popular é atacar a democracia e quem tem atacado tanto
o Estado de Direito quanto a Vontade Popular é o STF." (Luiz Philippe de
Orléans e Bragança)
E desta forma que eu penso é que vejo como boas, muitas das opiniões que
escancaram o viés demente que domina a nossa política.
"Bolsonaro é um tipo de cara sem etiqueta, daqueles que encontramos
coçando o saco no barzinho jogando bilhar. Apesar de ter mais estudo do
que qualquer professor de humanas da geração Paulo Freire e mais
inteligência emocional do que qualquer outro político brasileiro, não há
polidez em suas palavras e tão pouco elegância em seu comportamento.
Isso é o que mais incomoda artistas, jornalistas, feministas mal amadas
e complexadas, homens frágeis, covardes oportunistas, religiosos falidos
na luta contra a própria imoralidade, maconheiros, pedófilos,
estupradores e toda patrulha do politicamente correto que suportou
calada um circo de corrupção durante duas décadas, mas que agora é
ferida com as palavras do presidente "não pudico". Bolsonaro é o milico
com piadinhas sem graça, é o tiozão que pergunta se já temos pentelho, é
um elefante em uma loja de cristais, mas o que me faz a cada dia gostar
mais desse cara, é o tipo de gente que não gosta dele, que se ofende com
tudo que o cara faz, que do óleo venezuelano em nossas praias à histeria
mundial perante o coronavírus, buscam um meio de responsabilizá-lo.
Bolsonaro realmente é o cara que você passa a gostar, quando vê o lixo
de gente que não gosta dele. - (Arnaldo Jabor)
Aproveito para trazer para nosso conhecimento um texto do Guzzo, cujo
título é:
"Estado de exceção
Esqueça por um momento, se for possível, as ordens do STF que mais uma
vez mandaram soltar José Dirceu, o príncipe do PT condenado a 30 anos e
nove meses de cadeia por corrupção, além de outros dois colossos da vida
pública nacional — um, do PSDB, é acusado de roubar merenda escolar e o
outro é tesoureiro do PP. (Só isso: tesoureiro do PP. Não é preciso
dizer mais nada.)
Faz sentido um negócio desses? Claro que não. Não existe na história do
Judiciário brasileiro nenhum réu condenado a mais de 30 anos de prisão
por engano, ou só de sacanagem; dos outros dois nem vale a pena falar
mais do que já se vem falando há anos.
Mas a questão, a esta altura, já não é o que cada um deles fez ou é
acusado de ter feito no mundo do crime — a questão é o que estão fazendo
os ministros supremos que abriram a porta da cadeia para os três, e
virtualmente para todo o sujeito que hoje em dia é condenado por roubar
o erário neste país. Os ministros, pelo que escrevem nas suas sentenças,
decidiram na prática que ninguém mais pode ser preso no Brasil por
cometer crimes de corrupção.
Tudo bem, mas há uma pergunta que terá de ser respondida uma hora
qualquer: é possível existir democracia num país onde Gilmar Mendes,
Antonio Dias Toffoli, Ricardo Lewandowski e Marco Aurélio Mello, com a
ajuda de algumas nulidades assustadas e capazes de tudo para remar a
favor da corrente, decidem o que é permitido e o que é proibido para 200
milhões de pessoas?
Esse grupo de cidadãos está no STF por indicação, basicamente, de um
ex-presidente da República hoje na cadeia, condenado a 12 anos por
corrupção e lavagem de dinheiro, e por uma ex-presidente deposta por
quase três quartos dos votos do Congresso. Foram aprovados para seus
cargos pelo Senado Federal do Brasil — um dos ajuntamentos mais
corruptos que se pode encontrar entre os seres humanos vivos no momento
sobre a face da Terra. Jamais receberam um voto. Não respondem a
ninguém. Como os loucos, os pródigos e os silvícolas, estão fora do
alcance da lei — não podem ser acusados de nada, e muito menos punidos
por qualquer ato que venham a cometer.
Têm o direito de ficar nos seus cargos pelo resto da vida. Com essa
proteção toda, garantida pela Constituição suicida em vigor no Brasil,
deram a si próprios o poder de anular provas. Podem ignorar qualquer lei
em vigor, recusar-se a aplicar normas legais, não aceitar decisões do
Congresso e suprimir procedimentos judiciais.
Dizem, é claro, que todas as suas sentenças estão de acordo com as leis
— mas são eles, e só eles, que decidem o que a lei quer dizer. Se
resolverem que dois mais dois são sete, nenhum brasileiro terá o direito
de dizer que são quatro.
Os grandes gênios da nossa criatividade política, com os seus imensos
estoques de sabedoria acumulada, devem ter alguma resposta para a
pergunta feita acima. Talvez eles saibam como seria possível manter, ao
mesmo tempo, o regime democrático e uma corte suprema povoada por
Toffolis, Gilmares e Lewandowskis e dedicada a manter a corrupção como
uma atividade legal no Brasil.
Para os mortais comuns, está difícil de entender. Não existe em lugar
nenhum do mundo, e nunca existiu, uma democracia em que o tribunal mais
alto do Poder Judiciário faz uso da lei para impedir a prestação de justiça.
Se as atuais leis brasileiras, como garantem os ministros a cada vez que
soltam um ladrão de dinheiro público, os obrigam a transformar o direito
de defesa em impunidade, então todo o sistema de justiça está em
colapso; nesse caso, o que existe é um Estado de exceção, onde as
pessoas que mandam valem mais que todas as outras.
Contra eles, no entendimento de parte do STF, nenhum fato existe;
nenhuma prova é válida. Os Toffolis, etc., conseguiram montar no Brasil
um novo fenômeno: ao contrário da fábula narrada por Kafka em "O
Processo", o simples fato de alguém ser acusado perante o tribunal é a
prova indiscutível de sua inocência". - (José Roberto Guzzo)
=x=x=x=x=x=x=x=x=x=x=x=x=x=
Elementar que não se pode mais achar que alguém que tenha sido preso, ou
mesmo que tenha sido condenado no Brasil, possa ser considerado um
criminoso, pois em nossa nação, o bandido é o que está sendo solto, e
inclusive sendo colocado pelas ruas, a exemplo do que acontece na terra
que Helder Barbalho é o ditador de plantão, a ditar normas ao povo de
bem, das normas de conduta apropriadas ao bem viver em sociedade.
Como disse algum internauta, que infelizmente não peguei o nome: "Quem
deveria ter seu sigilo telefônico e bancário quebrado deveria ser o
Gilmar Mendes e sua esposa que advoga muitas causas no STF!"
Mas é claro que ninguém nos ouvirá e fará a escuta telefônica de Gilmar
Mendes e sua esposa, ainda que fosse, apenas e tão somente, para nos
provar que estamos errados.
Mas esse mesmo delinquente, ou seja, o Gilmar Mendes, é o que defende a
quebra de sigilo telefônico e bancário de pessoas que tenham participado
daquilo que ele considera como contrário à democracia, e assim que,
provavelmente a Polícia Federal deverá estar a serviço dos membros
quadrilheiros do Brasil e contra os patriotas que porventura ousem
clamar por Intervenção Militar, e mesmo pelo fechamento do STF.
E claro, não se espante, pois no Brasil, pau que bate em Chico, não bate
de forma alguma em Francisco.
Por esse motivo, vemos o twitter de Paulo Martins:
@PauloMartins10 - "STF abre investigação sobre a meia dúzia que pediu a
volta do AI-5. Há um problema nisso, pois se a lógica é identificar quem
defende ditadura, vai ter que investigar o PC do B e assemelhados. Ou
uma ditadura vermelha é aceitável?"
E não se espante, pois o STF tem um time de onze em campo, dentre eles,
tem um que se chama Alexandre de Moraes, e esse, que também foi alçado à
categoria de ministro, considerou gravíssimo tudo o que aconteceu
domingo, que ele considerou como sendo contra o Congresso e por
conseguinte contra o Supremo, dessa forma ele autorizou a abertura das
investigações sobre os organizadores dos eventos em questão. E a pedido
do Augusto Aras, determinou que houvesse a quebra de sigilo, assim como,
as buscas e apreensões, e dessa forma ferindo os incisos IV e XVI do
Artigo 5º da Constituição, determinando assim, a instauração do AI-5
contra o povo de bem, contra o povo que paga seus salários. Lembrando
que, aquilo que eles não querem contra eles, ou seja, a Intervenção e o
AI-5, eles o querem contra nós que somos justamente a razão da
existência do Estado.
Conforme lembrado pelo insigne (neste caso, insignificante) Alexandre
diz ser:
"imprescindível a verificação da existência de organizações e esquemas
de financiamento de manifestações contra a Democracia e a divulgação em
massa de mensagens atentatórias ao regime republicano, bem como as suas
formas de gerenciamento, liderança, organização e propagação".
(Alexandre de Moraes)
Quer o ilustre boçal impor limites aos direitos de ir e vir, e mesmo ao
direito e à liberdade de expressão que nos contempla a Constituição já
tão larga e fielmente rasgada, justamente pelos mandatários de plantão,
bem como pelos ditadores alojados na alta corte do País.
Lembrando ao dejeto felino ambulante, que a destruição dos valores
constitucionais, que a destruição das instituições que deveriam ser sim
republicanas, e que quem prega a violência e mesmo o desrespeito aos
direitos fundamentais, são exatamente os membros da Suprema Corte, que
inclusive emporcalha a referida instituição, juntamente com o restante
da quadrilha que se encontra alojada, nos mais diferentes postos da
República.
Ou seja, vocês é que são os tiranos, e quem está sofrendo com isso é o
povo brasileiro, justamente aquele que lhes paga seus salários, bem como
mantém os altos custos com suas manutenções, inclusive em suas mansões
que são por nós bancadas.
Finalizando, não precisamos querer, ou mesmo almejar um estado tirânico
de poder, uma vez que já o identificamos, na figura do timinho dos onze
que hoje imperam absolutos na mais alta Corte de nossa nação.
Amparados naturalmente, pelos demais membros da quadrilha que estão no
Senado Federal, e seus irmãos no delito que ocupam cadeiras na Câmara.
Faz-se importante dizer que não são todos?
Claro que não, observe-se a quem servem os referidos chapéus e ver-se-á,
quem de fato são os delinquentes supra citados.
(ap. Ely Silmar Vidal - Teólogo, Psicanalista, Jornalista e presidente
do CIEP - Clube de Imprensa Estado do Paraná)
Contato:
(41) 98514-8333 (OI)
(41) 99109-8374 (Vivo)
(41) 99821-2381 (WhatsApp)
Mensagem 22042020 - Estado de torpor é o que nos guia - (imagens da
internet)
Que o Espírito Santo do Senhor nos oriente a todos para que possamos
iluminar um pouquinho mais o caminho de nossos irmãos, por isso contamos
contigo.
Se esta mensagem te foi útil, e achas que poderá ser útil a mais alguém,
ajude-nos:
(ficaremos muito gratos que, ao replicar o e-mail, seja preservada a fonte)
leia este texto completo e outros em:
[youtube=http://youtu.be/dS7omyAk2mo]
http://www.portaldaradio.com
@elyvidal @radiocrista @pastorelyvidal @conipsip @CiepClube
#FalaPortaldaRadio #conipsi #cojae #dojae
Federal." - (José Roberto Guzzo)
Já diziam os antigos: "O Congresso Nacional é um grande puteiro,
comandado por cornos de todos os lados".
Infelizmente eu não posso almejar o fechamento do Congresso, apesar de
ele ser o antro de tudo o que não presta.
Olavo de Carvalho em seu twitter escreveu:
"O AI-5 foi uma bosta, mas nunca o vi batendo em velhinhas inocentes ou
estrangulando epiléticos.
Quem faz isso são os líderes da sua democracia, ó jornalistas de merda."
Não preciso dizer quem é o presidente do STF e este outro antro, eu
tenho que aceitar que não pode ser fechado, porque isso fere a democracia.
O que não fere a democracia é exatamente os bandidos estarem ocupando
postos de comando e batendo em cidadãos de bem, algemando trabalhadores,
soltando criminosos e enfim, tungando a carteira do povo de bem. Isto,
não fere a democracia.
"Quando você ataca as instituições, você ataca a democracia." - (Dias
Toffoli - "Amigo do amigo do meu pai")
"Errado!
Instituições não são a democracia.
Instituições representam o Estado de Direito.
A Democracia é a vontade popular.
Atacar a vontade popular é atacar a democracia e quem tem atacado tanto
o Estado de Direito quanto a Vontade Popular é o STF." (Luiz Philippe de
Orléans e Bragança)
E desta forma que eu penso é que vejo como boas, muitas das opiniões que
escancaram o viés demente que domina a nossa política.
"Bolsonaro é um tipo de cara sem etiqueta, daqueles que encontramos
coçando o saco no barzinho jogando bilhar. Apesar de ter mais estudo do
que qualquer professor de humanas da geração Paulo Freire e mais
inteligência emocional do que qualquer outro político brasileiro, não há
polidez em suas palavras e tão pouco elegância em seu comportamento.
Isso é o que mais incomoda artistas, jornalistas, feministas mal amadas
e complexadas, homens frágeis, covardes oportunistas, religiosos falidos
na luta contra a própria imoralidade, maconheiros, pedófilos,
estupradores e toda patrulha do politicamente correto que suportou
calada um circo de corrupção durante duas décadas, mas que agora é
ferida com as palavras do presidente "não pudico". Bolsonaro é o milico
com piadinhas sem graça, é o tiozão que pergunta se já temos pentelho, é
um elefante em uma loja de cristais, mas o que me faz a cada dia gostar
mais desse cara, é o tipo de gente que não gosta dele, que se ofende com
tudo que o cara faz, que do óleo venezuelano em nossas praias à histeria
mundial perante o coronavírus, buscam um meio de responsabilizá-lo.
Bolsonaro realmente é o cara que você passa a gostar, quando vê o lixo
de gente que não gosta dele. - (Arnaldo Jabor)
Aproveito para trazer para nosso conhecimento um texto do Guzzo, cujo
título é:
"Estado de exceção
Esqueça por um momento, se for possível, as ordens do STF que mais uma
vez mandaram soltar José Dirceu, o príncipe do PT condenado a 30 anos e
nove meses de cadeia por corrupção, além de outros dois colossos da vida
pública nacional — um, do PSDB, é acusado de roubar merenda escolar e o
outro é tesoureiro do PP. (Só isso: tesoureiro do PP. Não é preciso
dizer mais nada.)
Faz sentido um negócio desses? Claro que não. Não existe na história do
Judiciário brasileiro nenhum réu condenado a mais de 30 anos de prisão
por engano, ou só de sacanagem; dos outros dois nem vale a pena falar
mais do que já se vem falando há anos.
Mas a questão, a esta altura, já não é o que cada um deles fez ou é
acusado de ter feito no mundo do crime — a questão é o que estão fazendo
os ministros supremos que abriram a porta da cadeia para os três, e
virtualmente para todo o sujeito que hoje em dia é condenado por roubar
o erário neste país. Os ministros, pelo que escrevem nas suas sentenças,
decidiram na prática que ninguém mais pode ser preso no Brasil por
cometer crimes de corrupção.
Tudo bem, mas há uma pergunta que terá de ser respondida uma hora
qualquer: é possível existir democracia num país onde Gilmar Mendes,
Antonio Dias Toffoli, Ricardo Lewandowski e Marco Aurélio Mello, com a
ajuda de algumas nulidades assustadas e capazes de tudo para remar a
favor da corrente, decidem o que é permitido e o que é proibido para 200
milhões de pessoas?
Esse grupo de cidadãos está no STF por indicação, basicamente, de um
ex-presidente da República hoje na cadeia, condenado a 12 anos por
corrupção e lavagem de dinheiro, e por uma ex-presidente deposta por
quase três quartos dos votos do Congresso. Foram aprovados para seus
cargos pelo Senado Federal do Brasil — um dos ajuntamentos mais
corruptos que se pode encontrar entre os seres humanos vivos no momento
sobre a face da Terra. Jamais receberam um voto. Não respondem a
ninguém. Como os loucos, os pródigos e os silvícolas, estão fora do
alcance da lei — não podem ser acusados de nada, e muito menos punidos
por qualquer ato que venham a cometer.
Têm o direito de ficar nos seus cargos pelo resto da vida. Com essa
proteção toda, garantida pela Constituição suicida em vigor no Brasil,
deram a si próprios o poder de anular provas. Podem ignorar qualquer lei
em vigor, recusar-se a aplicar normas legais, não aceitar decisões do
Congresso e suprimir procedimentos judiciais.
Dizem, é claro, que todas as suas sentenças estão de acordo com as leis
— mas são eles, e só eles, que decidem o que a lei quer dizer. Se
resolverem que dois mais dois são sete, nenhum brasileiro terá o direito
de dizer que são quatro.
Os grandes gênios da nossa criatividade política, com os seus imensos
estoques de sabedoria acumulada, devem ter alguma resposta para a
pergunta feita acima. Talvez eles saibam como seria possível manter, ao
mesmo tempo, o regime democrático e uma corte suprema povoada por
Toffolis, Gilmares e Lewandowskis e dedicada a manter a corrupção como
uma atividade legal no Brasil.
Para os mortais comuns, está difícil de entender. Não existe em lugar
nenhum do mundo, e nunca existiu, uma democracia em que o tribunal mais
alto do Poder Judiciário faz uso da lei para impedir a prestação de justiça.
Se as atuais leis brasileiras, como garantem os ministros a cada vez que
soltam um ladrão de dinheiro público, os obrigam a transformar o direito
de defesa em impunidade, então todo o sistema de justiça está em
colapso; nesse caso, o que existe é um Estado de exceção, onde as
pessoas que mandam valem mais que todas as outras.
Contra eles, no entendimento de parte do STF, nenhum fato existe;
nenhuma prova é válida. Os Toffolis, etc., conseguiram montar no Brasil
um novo fenômeno: ao contrário da fábula narrada por Kafka em "O
Processo", o simples fato de alguém ser acusado perante o tribunal é a
prova indiscutível de sua inocência". - (José Roberto Guzzo)
=x=x=x=x=x=x=x=x=x=x=x=x=x=
Elementar que não se pode mais achar que alguém que tenha sido preso, ou
mesmo que tenha sido condenado no Brasil, possa ser considerado um
criminoso, pois em nossa nação, o bandido é o que está sendo solto, e
inclusive sendo colocado pelas ruas, a exemplo do que acontece na terra
que Helder Barbalho é o ditador de plantão, a ditar normas ao povo de
bem, das normas de conduta apropriadas ao bem viver em sociedade.
Como disse algum internauta, que infelizmente não peguei o nome: "Quem
deveria ter seu sigilo telefônico e bancário quebrado deveria ser o
Gilmar Mendes e sua esposa que advoga muitas causas no STF!"
Mas é claro que ninguém nos ouvirá e fará a escuta telefônica de Gilmar
Mendes e sua esposa, ainda que fosse, apenas e tão somente, para nos
provar que estamos errados.
Mas esse mesmo delinquente, ou seja, o Gilmar Mendes, é o que defende a
quebra de sigilo telefônico e bancário de pessoas que tenham participado
daquilo que ele considera como contrário à democracia, e assim que,
provavelmente a Polícia Federal deverá estar a serviço dos membros
quadrilheiros do Brasil e contra os patriotas que porventura ousem
clamar por Intervenção Militar, e mesmo pelo fechamento do STF.
E claro, não se espante, pois no Brasil, pau que bate em Chico, não bate
de forma alguma em Francisco.
Por esse motivo, vemos o twitter de Paulo Martins:
@PauloMartins10 - "STF abre investigação sobre a meia dúzia que pediu a
volta do AI-5. Há um problema nisso, pois se a lógica é identificar quem
defende ditadura, vai ter que investigar o PC do B e assemelhados. Ou
uma ditadura vermelha é aceitável?"
E não se espante, pois o STF tem um time de onze em campo, dentre eles,
tem um que se chama Alexandre de Moraes, e esse, que também foi alçado à
categoria de ministro, considerou gravíssimo tudo o que aconteceu
domingo, que ele considerou como sendo contra o Congresso e por
conseguinte contra o Supremo, dessa forma ele autorizou a abertura das
investigações sobre os organizadores dos eventos em questão. E a pedido
do Augusto Aras, determinou que houvesse a quebra de sigilo, assim como,
as buscas e apreensões, e dessa forma ferindo os incisos IV e XVI do
Artigo 5º da Constituição, determinando assim, a instauração do AI-5
contra o povo de bem, contra o povo que paga seus salários. Lembrando
que, aquilo que eles não querem contra eles, ou seja, a Intervenção e o
AI-5, eles o querem contra nós que somos justamente a razão da
existência do Estado.
Conforme lembrado pelo insigne (neste caso, insignificante) Alexandre
diz ser:
"imprescindível a verificação da existência de organizações e esquemas
de financiamento de manifestações contra a Democracia e a divulgação em
massa de mensagens atentatórias ao regime republicano, bem como as suas
formas de gerenciamento, liderança, organização e propagação".
(Alexandre de Moraes)
Quer o ilustre boçal impor limites aos direitos de ir e vir, e mesmo ao
direito e à liberdade de expressão que nos contempla a Constituição já
tão larga e fielmente rasgada, justamente pelos mandatários de plantão,
bem como pelos ditadores alojados na alta corte do País.
Lembrando ao dejeto felino ambulante, que a destruição dos valores
constitucionais, que a destruição das instituições que deveriam ser sim
republicanas, e que quem prega a violência e mesmo o desrespeito aos
direitos fundamentais, são exatamente os membros da Suprema Corte, que
inclusive emporcalha a referida instituição, juntamente com o restante
da quadrilha que se encontra alojada, nos mais diferentes postos da
República.
Ou seja, vocês é que são os tiranos, e quem está sofrendo com isso é o
povo brasileiro, justamente aquele que lhes paga seus salários, bem como
mantém os altos custos com suas manutenções, inclusive em suas mansões
que são por nós bancadas.
Finalizando, não precisamos querer, ou mesmo almejar um estado tirânico
de poder, uma vez que já o identificamos, na figura do timinho dos onze
que hoje imperam absolutos na mais alta Corte de nossa nação.
Amparados naturalmente, pelos demais membros da quadrilha que estão no
Senado Federal, e seus irmãos no delito que ocupam cadeiras na Câmara.
Faz-se importante dizer que não são todos?
Claro que não, observe-se a quem servem os referidos chapéus e ver-se-á,
quem de fato são os delinquentes supra citados.
(ap. Ely Silmar Vidal - Teólogo, Psicanalista, Jornalista e presidente
do CIEP - Clube de Imprensa Estado do Paraná)
Contato:
(41) 98514-8333 (OI)
(41) 99109-8374 (Vivo)
(41) 99821-2381 (WhatsApp)
Mensagem 22042020 - Estado de torpor é o que nos guia - (imagens da
internet)
Que o Espírito Santo do Senhor nos oriente a todos para que possamos
iluminar um pouquinho mais o caminho de nossos irmãos, por isso contamos
contigo.
Se esta mensagem te foi útil, e achas que poderá ser útil a mais alguém,
ajude-nos:
(ficaremos muito gratos que, ao replicar o e-mail, seja preservada a fonte)
leia este texto completo e outros em:
[youtube=http://youtu.be/dS7omyAk2mo]
http://www.portaldaradio.com
@elyvidal @radiocrista @pastorelyvidal @conipsip @CiepClube
#FalaPortaldaRadio #conipsi #cojae #dojae
Assinar:
Postagens (Atom)
Postagens
