Challenges With The ISC Bind Vulnerability
Posted by Daniel Hanley, Takehiro Takahashi, and David Gibson on August 12, 2009 at 4:32 PM EDT.
When a deluge of exploits, attack vectors, and novel security intelligence hits IBM X-Force Quality Assurance, it can be a monumental task to appropriately configure a vulnerable test environment, track down the necessary tools (or write our own), and hope to consider the innumerable test parameters that may impact the effectiveness of the attack and our products' ability to accurately report malicious traffic. For instance, what is the exact threshold of a buffer overflow? Is our decode/signature logic tuned accordingly? How many ways can you perform an SSL/TLS handshake? If the handshake is partly semantically invalid, does the exploit still work against some target hosts? If not, should our products report the attack regardless, risking a false positive, or can we safely proceed without reporting the malformed message?
These are just some examples of the questions we try to ask ourselves as we assess each attack and the corresponding technology solution, all while gaining valuable vulnerability insight from our X-Force Advanced Research team and providing feedback to X-Force Development for the next iteration of the signature. Multiply the millions of potential protocol parameters and PAM internal state transitions by the dozens of risky attacks speeding into our inboxes each month, and it's clear that this deluge could be enough to overwhelm any QA team -- unless it augments its usual test cases with some attack automation and fuzz testing.
We applied such techniques over the past month to ensure industry-leading coverage for our ISC BIND denial-of-service signature. To test our new signature, DNS_ISC_BIND_DoS, we started with the basic attack vector, a minimal exploit that sends a malicious DNS dynamic update. We then described several elements of this exploit hierarchically and abstractly in a context free grammar, which our fuzzing toolkit parsed to generate an exploit tool. We gradually added many new rules to this grammar with specified probabilities, each rule potentially modifying some attribute of the base exploit: adding additional zones to a DNS message, altering zone names in the update section, setting various combinations of flags, and so forth. The probabilities associated with each rule were carefully weighted such that the generated exploits generally tended toward the original test case, yet the randomly-generated code could potentially yield dramatically different DNS datagrams.
Let's consider a concrete example. Starting with a top-level rule, we can define the anatomy of an exploit tool with weighted random elements. The following is a simplified excerpt from our top-level rule:
exploit: shbang
init
declare
(prereq | prereq{2,5} | "")
(update{2,5} 2 | update | "")
.
.
.
send
;
This rule implies that our exploit will consist of initialization code, followed by code defined in the prereq rule, followed by the update rule, and so forth. As one might expect, the pipe represents the OR operator: the exploit can contain a single prerequisite section, two to five prerequisites, or none. On the following line, the first outcome (update{2,5}) is tagged as twice as likely as the others. The declare rule instantiates the DNS object and defines the zone to be referenced in the DNS dynamic update:
declare: "my $zone = " zone ";\n"
"my $sub = " sub ";\n"
"my $dns = Net::DNS::Update->new($zone);\n\n"
Note that zone and sub are new rules invoked by the declare rule. These rules generate random string literals. To exploit the ISC BIND denial of service, the target server must be authoritative for the specified zone, and therefore the first two possibilities below are weighted more heavily than the others:
zone:
"\"" (
"example" "."? 100
| "localhost" "."? 10
.
.
.
| "."{1,20}
| "iss.net"
)
"\"" ;
Next, the grammar invokes the prereq rule zero to five times:
prereq:
"$dns->push("
"pre => Net::DNS::RR->new("
(
"Name => \"$sub.$zone\"," 30
| "Name => " sub ".\".\"." zone ","
)
"TTL => '" ttl "',"
.
.
.
")"
")"
;
This rule yields a Perl code snippet that pushes a new prerequisite field into the DNS dynamic update to be sent to the victim server. The name field is either the previously defined subzone ($sub.$zone) or a new random subzone as defined by sub and zone. However, the former outcome is thirty times more likely, ensuring that most code generated by this rule will resemble the original exploit. Similarly, the time-to-live (TTL) field is randomly generated according to another rule. This ttl rule most often results in a TTL of zero, though other outcomes are certainly possible:
ttl: "0" 10
| "1"{1,4}
| "-1"
.
.
.
The completed grammar rapidly generated approximately one hundred thousand exploits, producing one hundred thousand datagrams for us to test automatically. Our internal test suite transmitted each DNS dynamic update to a vulnerable host and determined whether the denial of service was successful. We applied our signature to both the unsuccessful and successful attacks to minimize false positives and false negatives, respectively. X-Force Quality Assurance could promptly confirm to X-Force Development that no effective attack would slip past our product, yet certain test cases did uncover criteria for potential false positives. For instance, returning to the example above, our test results suggested that attacks specifying a TTL not equal to zero were ineffective. X-Force Quality Assurance notified X-Force researchers, who browsed the ISC BIND source code to confirm this hypothesis in update.c:
static void
update_action(isc_task_t *task, isc_event_t *event) {
.
.
.
if (ttl != 0) // TTL check
PREREQFAILC(DNS_R_FORMERR,
"prerequisite TTL is not zero");
ISC BIND discards DNS dynamic updates with a TTL not equal to zero. X-Force Advanced Research relayed this discovery to X-Force Development, which revised the signature, and as a result all three departments can sleep soundly, confident that neither successful attacks nor false alarms will disturb our customers, making for a more effective and manageable solution.
