After a two year absence due to unavoidable other obligations like good friends’ weddings, I finally made it back to one of my favorite hacker conferences, Toorcon. San Diego is always beautiful when I happen to be there with nice weather and a cool mix of people, both locals and visitors who are there for the conference, and this year was no exception.
Archive for the ‘attack’ Category
This last weekend I took a trip up to Montreal for REcon. If you’re unfamiliar with REcon, it’s a small security conference focused on topics most interesting to reverse engineers. As such, the talks are more technical than you will find at other more mainstream conferences like BlackHat or DEFCON, and generally require a certain level of expertise as a baseline. If you don’t understand assembly language, you’ll probably not get much out of at least half of the lectures.
Ok, enough with the APT marketing and journalism diarrhea… It’s really quite simple:
ad·vanced – /ædˈvænst, -ˈvɑnst/ -adjective
1. ahead or far or further along in progress, complexity, knowledge, skill, etc.: an advanced class in Spanish; to take a course in advanced mathematics; Our plans are too advanced to make the change now.
per·sist·ent – /pərˈsɪstənt, -ˈzɪs-/ –adjective
1. persisting, esp. in spite of opposition, obstacles, discouragement, etc.; persevering: a most annoyingly persistent young man.
2. lasting or enduring tenaciously: the persistent aroma of verbena; a persistent cough.
3. constantly repeated; continued: persistent noise.
threat – /θrɛt/ –noun
1. a declaration of an intention or determination to inflict punishment, injury, etc., in retaliation for, or conditionally upon, some action or course; menace: He confessed under the threat of imprisonment.
2. an indication or warning of probable trouble: The threat of a storm was in the air.
3. a person or thing that threatens.
This term has been around for ages, and means exactly what the acronym’s words mean. It’s not any single attack, it’s not any trivial or obvious piece of malware, and it’s not the bogeyman that the hot new security product will save you from. It’s a particular class of threat. The term gained critical mass being used as early as a few decades ago in the intelligence community where it is used to describe advanced and generally covert modus operandi for ensuring the ongoing gathering of intelligence about an individual or other entity. The term has been more recently applied, although still at least a decade ago, to Information Security where it is used to describe an ongoing campaign of targeted, sophisticated attacks, or the actors facilitating or conducting said campaign. In other words, a threat that is both advanced and persistent.
Please, for the love of all that’s holy, stop using “APT” interchangeably with “malware”. A particular piece of malware may be an APT, or a component used by an APT, but not every APT is malware. In fact, most of the time malware can’t be considered an APT as the majority of malware is neither relatively advanced nor persistent, and to be APT it would have to be both.
I recently purchased the Motorola Droid from Verizon, and am so far very happy with it. Other than finding the physical keyboard a bit lacking from being extremely spoiled by the Sidekick’s physical keyboard to which no other physical keyboard could ever hope to live up to, I’ve really had no complaints with the device or the Android 2.0 operating system that runs on it. I have however, noticed that touch-screen smart-phone unlock screens (not just the Droid’s) are getting progressively less secure.
Todd Manning and I have a new whitepaper available over at BreakingPoint on simulating Distributed Denial-of-Service (DDoS) attacks using the BreakingPoint product. You can read more about the paper in my BreakingPoint blog post, or just grab the paper here. If you’re a BreakingPoint customer, you’ll want the bundled version which comes with test cases and other supporting materials.
First let me say that this article is not meant to diminish the work that Alexander Sotirov et. all have been doing for the past 6 months. It’s good work, has brought about some awesome results, and has demonstrated what was once a theoretical attack on PKI certificates based on MD5 hash collisions. What I’m amazed at is that it had the impact that it actually did.
If someone is selling you a network penetration test, and then running a vulnerability scanner and handing you a report, you’re not getting what you paid for, period.
Obviously the first thing everyone should be doing is to apply the patches that the major vendors rolled out, and do it quickly. It is no longer the time for debate in regard to whether or not you really do need to patch… the answer to that question is quite clear; Yes. Yes you do. Stop reading this, go to your vendor right now, and get the patches. Then apply them. This will still be here when you get back…
Unfortunately, the existing patch doesn’t really fix the problem, it just makes it much harder to attack, which is a good thing. If you still aren’t patched, you obviously didn’t follow my instructions in the first paragraph, so I’ll reiterate: Stop reading this, go to your vendor right now, and get the patches. Then apply them.
The patches that most major vendors rolled out when this vulnerability was announced, albeit with no technical details, primarily revolves around randomizing the source port that the nameserver makes it’s queries from. Without this randomization, the only other piece of random information in the DNS packet is the transaction ID, which DNS servers use to correlate queries and replies, and also helps prevent reply-spoofing attacks by requiring that the attacker correctly guess this value. Given the randomized hostname exploitation technique used in this attack, the attacker can force the nameserver to do as many queries as they like, which provides a birthday attack scenario for guessing the transaction ID value and succeeding in spoofing the reply. The search space of the transaction ID is 16 bits, which provides possible values of 0-65535 within which the attacker has to guess correctly. Given as many attempts as the attacker likes, this can take anywhere from a few seconds to a couple of minutes. By adding the source port randomization to the picture, this adds around another 16 bits to the equation (minus source ports already used, privileged source port range, etc.), making the time it takes to correctly guess much longer, but still not impossible.
It’s been quite a while since I wrote or updated DFW, the I)ruidic FireWall. Included with that utility is a default iptables firewall policy which the user can use directly, tweak to their liking, or completely throw away and start over from scratch. NetFilter (iptables) has come a long way since I was actively working in the firewall space and regularly maintaining the DFW utility, so I thought it high time that I update the firewall policies on my servers to take advantage of some of it’s newer features, and in doing so update DFW’s default policy with some extra bells and whistles. The primary goal I wanted to accomplish was to significantly clean up my firewall logs, as the Internet is an extremely dirty and hostile place to connect a computer to. Regularly my logs would be full of default drop log entries for entire port-scans, the same worm-infected hosts connecting to the same closed ports over and over and over again, and other general random connection attempts.