I'm struggling to understand how to properly read and construct my NegotiateFlags parameter on the NTLM messages. On the official protocol specification I simply cannot understand that table. I think it represents a 32-bits since the NegotiateFlags is 4 bytes, but what means these letters? How to set that?
Searching on Google I found another example, that makes a lot more sense to me:
0x00000001 Negotiate Unicode
0x00000002 Negotiate OEM
0x00000004 Request Target
0x00000008 unknown
0x00000010 Negotiate Sign
0x00000020 Negotiate Seal
0x00000040 Negotiate Datagram Style
0x00000080 Negotiate Lan Manager Key
0x00000100 Negotiate Netware
0x00000200 Negotiate NTLM
0x00000400 unknown
0x00000800 Negotiate Anonymous
0x00001000 Negotiate Domain Supplied
0x00002000 Negotiate Workstation Supplied
0x00004000 Negotiate Local Call *//Sent by the server*
0x00008000 Negotiate Always Sign
0x00010000 Target Type Domain *//Sent by the server in the Type 2 message*
0x00020000 Target Type Server *//Sent by the server in the Type 2 message*
0x00040000 Target Type Share *//Sent by the server in the Type 2 message*
0x00080000 Negotiate NTLM2 Key
0x00100000 Request Init Response
0x00200000 Request Accept Response
0x00400000 Request Non-NT Session Key
0x00800000 Negotiate Target Info
0x01000000 unknown
0x02000000 unknown
0x04000000 unknown
0x08000000 unknown
0x10000000 unknown
0x20000000 Negotiate 128
0x40000000 Negotiate Key Exchange
0x80000000 Negotiate 56
But looking on FreeRDP example the NegotiateFlags are:
b7 82 08 e2
Reading in little endian I have:
e2 08 = 57864
82 b7 = 33463
Sum of values = 91327
I cannot get the sum of this value with the example table I show above... How I should calculate this? (I accept explanations that lead me to understand the official table from Microsoft, of course)
Your endian conversion is wrong.
it should be E20882B7
0x is that standard notation for hex.
first digit is , so
0x00000001 Negotiate Unicode +
0x00000002 Negotiate OEM +
0x00000004 Request Target
second digit is B, so
0x00000010 Negotiate Sign +
0x00000020 Negotiate Seal +
0x00000080 Negotiate Lan Manager Key
and so on.
Related
I'm wondering whether it's possible to write a snort rule matching ESP packet with spoofed SPI value.
Packets I want to alert:
00:00:00.000000 IP x.x.x.x > x.x.x.x: ESP(spi=0x00000000,seq=0x29)
Raw packet would look something like this:
4500 XXXX XXXX XXXX XXXX -> 20 bytes of IP header
0000 0000 XXXX XXXX XXXX -> ESP header starting with 4 bytes of zeroes
XXXX...
That's why my best guess is trying to match by:
1) IP Proto equals ESP
2) raw bytes at the start of ESP header equals 0x00000000
So far I came up with this:
alert ip any any -> any any \
(ip_proto:esp; content: "|00 00 00 00|"; offset:0; depth: 4;)
Unfortunately, that doesn't work. I believe it's because Snort starts looking at 'content:' in the payload. I tried using pkt_data option to reset detection cursor to the start of transport layer. Per manual:
"pkt_data: This option sets the cursor used for detection to the raw transport payload"
I assumed it would fool snort to start 'content:' checking right after IP header. Unfortunately, no result.
Am I making a mistake here somewhere? Or is it just not possible for Snort to match by raw bytes in the ESP header? Any help/opinion would be greatly appreciated!
There is no good way to do this except to write your own preprocessor. Snort does not currently have anything that exposes the ESP spi value to the rules configuration language.
While it is true that there is support to decode ESP data, this still only exposes the decrypted payload to your rules.
To save you some trouble, byte_test might seem like a possibility, but it very specifically allows you to manipulate the payload only. For example, the following will not allow you to examine the UDP destination port in the header for 2049:
...byte_test:2,=,2049,-2,big;
I have a Mifare fob and a magic Mifare Classic card. When I fully clone the fob onto the card, the SAK found from the card is 0x88, despite a SAK of 0x08 on the fob.
If I change the sixth byte of block 0 on the card from 0x88 to 0x08, the SAK changes accordingly. However, the fob holds a value of 0x88 at that position whilst reporting a SAK of 0x08. So, what determines the SAK such that two cards with supposedly identical data can report different values for it?
I had the same problem. I had:
An original TAG (mifare 1k)
A chinese TAG (mifare 1k) gen1a with block 0 rewritable.
From the Rfid Research Group documentation we can found this information:
MIFARE Classic block0:
11223344440804006263646566676869
^^^^^^^^ UID
^^ BCC
^^ SAK(*)
^^^^ ATQA
^^^^^^^^^^^^^^^^ Manufacturer data
(*) some cards have a different SAK in their anticollision and in block0: +0x80 in the block0 (e.g. 08->88, 18->98)
so usually the SAK is determined by the bytes #6 of the block 0.
But as specified in the doc, some cards have a different SAK in their anticollision and in block0.
So unfortunately my chinese TAG gen1a was unable to reproduce the same behavior of my original TAG. Also a gen1a TAG accept magic command, which means that a backdoor exist with those tags and you can read or write a block without using the access key, this backdoor is now well known and some reader can detect that.
The solution was to use a gen2 TAG aka CUID card, with block 0 rewritable. This TAG add a 08 SAK, by default, that did not change, even if a rewrite the byte #6 of the block 0.
The SAK byte identifies the manufacturer code and product code.
x08 would be NPX mifare clasic 1k and
x88 would be Infineon mifare clasic 1k
You would need to clarify with your card supplier which one does he sale.
source: http://nfc-tools.org/index.php?title=ISO14443A
Could not figure out if linux kernel 4.4 supports IPSEC AH transport with AES GMAC.
Trying various combination of "ip xfrm state" command but no luck. Is this implemented ?
Try 1 sudo ip xfrm state add src 192.168.0.1 dst 192.168.0.2 proto ah spi 100 mode transport auth "rfc4106(gcm(aes))" 0x010203047aeaca3f87d060a12f4a4487d5a5c335 RTNETLINK answers: Function not implemented
Try 2 sudo ip xfrm state add src 192.168.0.1 dst 192.168.0.2 proto ah spi 100 reqid 100 mode transport aead "rfc4543(gcm(aes))" 0x010203047aeaca3f87d060a12f4a4487d5a5c335 128 ALGO-TYPE values "enc", "aead", and "comp" are invalid with XFRM-PROTO value "ah"
Based on the code, it does support the algorithm under the cipher name rfc4543(gcm(aes)) for ESP, but I'm not sure if it does for AH. I guess technically this is considered an AEAD, meaning it is an encryption cipher (for ESP, not AH which is only authentication without encryption) even though it is NULL encryption.
I'm using ip xfrm under Linux to add an IPsec SA with AES in GCM mode to the system.
The command I'm using is like this:
ip xfrm state add src 10.66.21.164 dst 10.66.21.166 proto esp spi 0x201 mode transport aead "rfc4106(gcm(aes))" 0x010203047aeaca3f87d060a12f4a4487d5a5c335 96
Now I'm wondering:
The key is seemingly 20B = 160b long. The normal AES key is 128b and, as can be seen above, the IV-length is 96b. If I lengthen or shorten the key it doesn't work, so clearly the expected input is (sizeof(AES)=128b) (it does, of course, work with 256b too) + 32b long.
Why is this so? The only thing I know that is 4B long in this context is unsigned int, which is the data type of IV-length variable, but this has nothing to do with the key.
Shouldn't the key plus IV be 224b long (128 + 96 for the IV)?
The 96 value in your command is the size of the authentication tag. The authentication tag is part of a message in the session, it is not something you have to specify. The same thing goes for the IV, it is generated by the protocol per message.
The key material consists of a 16 byte (128 bit) AES key and a 4 byte (16 bit) salt in hexadecimal format, which uses 2 characters per byte.
The KEYMAT requested for each AES-GCM key is 20 octets. The first
16 octets are the 128-bit AES key, and the remaining four octets
are used as the salt value in the nonce.
Source: RFC 4106.
Are there any workarounds to connect to HID device using L2CAP in JAVA ME (using JSR-82 specification implementation native to mobile device not BlueCove etc.)?
I know that HID devices usually uses PSMs (Protocol Service Multiplexor) with 0x0011 value. Unfortunately as I found:
Legal PSM values are in the range (0x1001..0xFFFF), and the least significant byte must be odd and all other bytes must be even.
Above explains why javax.microedition.io.Connector connect() method throws exception when I try following code:
Connector.open("btl2cap://600010120296:11");
This page suggests that the restriction was removed in JSR-82 1.2:
Legal PSM values are in the range (0x0005..0xFFFF), and the least significant byte must be odd and all other bytes must be even. When a server connection string does not have a psm parameter, the server PSM value assigned by the implementation must be no less than 0x1001.
And the comment:
Remove reserved ranges from L2CAP PSM values, to allow a Java application to use a Bluetooth protocol that is built on top of L2CAP using a PSM value in the "reserved" range.
Also, the "interrupt endpoint" is PSM 0x13 (that's where keyboards, mice, etc will send unsolicited reports just like they would send on the control channel (0x11) in response to GET_REPORT).