DCE RPC messages are predominantly embedded in SMB Messages such as SMB_COM_READ response, SMB_COM_WRITE and ANDx versions of them. Also DCE RPC messages are also sent with SMB_COM_TRANSACT command and response messages. Note that these evasion techniques are not only useful for detecting attacks in DCE RPC based applications, but also CIFS (SMB) itself.
Protocol details of SMB are described very well here.
Many IDS/IPS devices don't have protocol intelligence of SMB and DCE RPC protocols. IDS/IPS systems that depend on generic pattern matching can be bypassed by attackers with simple evasion (obfuscation) techniques. Let us examine some of the evasion techniques.
1. ANDx messages:
As indicated above, there are commands with ANDx version. Any command/response ending with ANDx have following structure in the packet after SMB Header.
SMB_Parameters
{
UCHAR WordCount;
Words
{
UCHAR AndXCommand;
UCHAR AndXReserved;
USHORT AndXOffset;
USHORT FID;
ULONG Offset;
USHORT MaxCountOfBytesToReturn;
USHORT MinCountOfBytesToReturn;
ULONG Timeout;
USHORT Remaining;
ULONG OffsetHigh (optional);
}
}
SMB_Data
{
USHORT ByteCount;
}Variable size of SMB Parameters : Many IDS/IPS devices assume that the 'wordcount' is constant for a given ANDx message. For example, for SMB_COM_READ_ANDx message, the 'word count' is assumed to be 10 words. But it can be 12 words in case of 64 bit offset (OffsetHigh). IDS/IPS devices assuming 10 words and interpreting the data would have the detection wrong. Attacker deliberately set the wordCount to 12 words even though OffsetHigh is 0. IDS/IPS devices must interpret the 'word Count' to move to the data section.
Multiple ANDx messages under one SMB message (with one SMB Header):
Many IDS/IPS devices assume that there is only one command (or response) in the SMB message. But SMB protocol allows multiple ANDx commands (or responses) in one single message. Every command/response would have its own 'SMB Parameter' and 'SMB Data' blocks. Attackers can put the malicious command/response as non-first command/response in the SMB message to bypass detection by security devices. IDS/IPS devices must interpret the 'AndxCommand' to figure out whether any more commands/responses are present in the message. AndXCommand is normally set to 0xFF if there are no additional commands.
Filler between ANDx messages : AndXOffset field indicates the next command in the SMB message. Since there is explicit mention of offset, is is protocol wise legal to send some additional filler data between Andx commands. Attacker can take advantage of this and put some data to confuse security devices. Security devices thinking that all commands are next to each other would fail to detect the attacks. Security devices must be aware of this and interpret the AndXOffset appropriately as end systems do.
Out-of-Order of ANDx messages : Here AndX commands can refer to the data in the SMB messages before AndX header. Note that AndXOffset indicates the offset from the beginning of SMB header. Hence it can be set to any place in the SMB message. This is tricky for IDS/IPS devices as they need to store the complete SMB message before analyzing and hence it increases the memory requirements. But it is necessary to do this to mitigate any evasion techniques used by attackers.
2. Transaction Messages
Transaction command messages have this structure. Responses also have similar structure but some fields don't exist. So, be careful in analyzing the command and responses.
SMB_Parameters
{
UCHAR WordCount;
Words
{
USHORT TotalParameterCount;
USHORT TotalDataCount;
USHORT MaxParameterCount;
USHORT MaxDataCount;
UCHAR MaxSetupCount;
UCHAR Reserved1;
USHORT Flags;
ULONG Timeout;
USHORT Reserved2;
USHORT ParameterCount;
USHORT ParameterOffset;
USHORT DataCount;
USHORT DataOffset;
UCHAR SetupCount;
UCHAR Reserved3;
USHORT Setup[SetupCount];
}
}
SMB_Data
{
USHORT ByteCount;
Bytes
{
SMB_STRING Name;
UCHAR Pad1[];
UCHAR Trans_Parameters[ParameterCount];
UCHAR Pad2[];
UCHAR Trans_Data[DataCount];
}
}Fragmentation : If application payload is bigger than the 'MaxBufferSize' negotiated during setup phase, application payload is divided across multiple SMB messages with first message having SMB_COM_TRANSACTION command/response and further messages are sent with SMB_COM_TRANSACTION_SECONDARY. Attackers take advantage of this to evade the detection by security devices which are not reassembling the data that is sent across multiple 'TRANSACTION' messages, even if the real application data is less than 'MaxBufferSize'. Security devices must ensure that all messages have come in to reassemble by checking the 'TotalParameterCount' and 'TotalDataCount'. If all transaction messages (with same PID, MID, TID, UID in the SMB Header) parameter count and data count adds up to TotalParameterCount and TotalDataCount with different ParameterOffset and DataOffset, then security device can assume that all fragments are received. Note that some attackers try to fool security devices by sending duplicate SMB messages. Security devices blindly adding 'ParameterCount' and 'DataCount' of all matching SMB messages to match 'Total ParameterCount' and 'TotalDataCount' without checking for unique 'ParameterOffset' and 'DataOffset' can be bypassed with attack detection by sending duplicate SMB messages.
Out-of-Order of Transaction fragments : As seen before 'Parameter Offset' and 'Data Offset' indicate the position of the parameter and data section of the message in the overall application payload. End SMB systems honor these values while reassembling. So, the order in which they come is not important. Security devices, if they assume that the packets would be in order' can be evaded by attacker by sending these messages in different order.
