In the attack against krebsonsecurity.com, one of the systems that is said to have been used was the “H.264 Network DVR“. This device accepts HTTP connections, and communicates outbound using FTP and EMail. There may also be an undocumented protocol for a proprietary interface.
As I’ve previously discussed, use of Manufacturer Usage Descriptions (MUD) can limit the attack surface of a device, and it can also prevent devices from being used to source an attack. MUD allows for manufacturers to define classes, and now one simply needs to fill them in on deployment. From the manufacturer’s side, one needs to provide the file. For the DVR in question, I used MudMaker to create a description that a network device could use to create appropriate network protections:
{
"ietf-mud:meta-info": {
"lastUpdate": "2016-10-02T08:28:19+02:00",
"systeminfo": "DVR H.264",
"cacheValidity": 1440
},
"ietf-acl:access-lists": {
"ietf-acl:access-list": [
{
"acl-name": "mud-65333-v4in",
"acl-type": "ipv4-acl",
"ietf-mud:packet-direction": "to-device",
"access-list-entries": {
"ace": [
{
"rule-name": "entout0-in",
"matches": {
"ietf-mud:controller": "http://dvr264.example.com/controller"
},
"actions": {
"permit": [
null
]
}
},
{
"rule-name": "entin0-in",
"matches": {
"ietf-mud:controller": "http://dvr264.example.com/controller",
"protocol": 6,
"source-port-range": {
"lower-port": 80,
"upper-port": 80
}
},
"actions": {
"permit": [
null
]
}
}
]
}
},
{
"acl-name": "mud-65333-v4out",
"acl-type": "ipv4-acl",
"ietf-mud:packet-direction": "from-device",
"access-list-entries": {
"ace": [
{
"rule-name": "entout0-in",
"matches": {
"ietf-mud:controller": "http://dvr264.example.com/controller"
},
"actions": {
"permit": [
null
]
}
},
{
"rule-name": "entin0-in",
"matches": {
"ietf-mud:controller": "http://dvr264.example.com/controller",
"protocol": 6,
"source-port-range": {
"lower-port": 80,
"upper-port": 80
}
},
"actions": {
"permit": [
null
]
}
}
]
}
}
]
}
}
What is left for the controller to do that is specific to this device is define which devices are in the class http://dvr64.example.com. That might include the FTP-based logging system that this model uses, for instance, as well as those systems that are authorized to connect to the HTTP port.
The important part of that description is what you don’t see. You don’t see any of the attack vectors used, because through this whitelist approach, you only specify what is permitted, and everything else aside from name service and time queries is explicitly denied. This device uses a good few services, and so I haven’t specified each one in the example for brevity’s sake.
This may well have stopped the hacker from gaining access to the device in the first place, and would have stopped the device from being able to attack the blogger, and many other attacks as well.