David Maynor at Erratasec has written an article about how to circumvent the debugging prevention inside of iTunes.
"..I noticed iTunes kept crashing, predictably and reliably in the same place. I decided to use gdb to see what the hubbub was all about. However I got dissed and iTunes would not allow itself to be debugged."
Not a new concept for sure.
A new wave of more difficult to remove malware? A new way of stealing information? Maybe.
In the last 6 months to a year it seems code injection and file infectors have "opened a new door". It's still seems to be the "replicate and destroy" but recently with infections like "Scribble" "sality" "alman" and "virut" some changes have begun to show in this "angle of attack".
Now instead of just replicating out of control the infections are replicating crazily, but also bringing down fake-alerts and other nasty things.
As usual, Brian Krebs from the Washington Post has done some fine reporting bringing us news about the Conficker Worm Strike. Here are some choice excerpts of the horror that is raining down upon the world:
"A nuclear missile installation near Elmendorf Air force Base outside of Anchorage, Alaska briefly went on a full-scale military alert after technicians manning the bunker suspected that several of their control systems were infected with Conficker."
"According to local news reports, shortly after midnight local time, an ATM in the capital city of Reykjavik began spewing 100-Krona notes."
It's time to auger in with an AR-15 and your favorite dog Will Smith "I Am Legend" style.
by Taneja Vikas
Phillip Porras, Hassen Saidi, and Vinod Yegneswaran from SRI has publicly posted an excellent overview of the Conficker malware. They even have a great analysis of the C variant as well. I highly recommend reading this excellent work.
"Conficker is one of a new interesting breed of self-updating worms that has drawn much attention recently from those who track malware. In fact, if you have been operating Internet honeynets recently, Conficker has been one very difficult malware to avoid. In the last few months this worm has relentlessly pushed all other infection agents out of the way, as it has infiltrated nearly every Windows 2K and XP honeypot that we have placed out on the Internet. From late November through December 2008 we recorded more than 13,000 Conficker infections within our honeynet, and surveyed more than 1.5 million infected IP addresses from 206 countries."
I had a presentation the other day at UNM on some of the work that I had done two years ago. It's fascinating that there is such a renewed interest.
A. Kozakiewicz, A. Felkner, P. Kijewski, and T. Kruk published a paper (4/2007) after my DefCon presentation entitled "Application of bioinformatics methods to recognitio of network threats." The conclusion of this paper was that these the bioinformatics techniques seem to have less resistance to polymorphism, however I maintain that was because of the simplicity of the scoring function they considered.
One of the starting papers in the field of using nature as a way to figure out how to do things correctly was a 1994 paper "Principles of a Computer Immune System" by A. Somayaji, S. Hofmeyr, and S. Forrest. This spends a lot of time considering the acquired immune system.
So, how does nature do things differently than anti mal*? There's a lot out there on this topic. I'd like to advance two points I've not seen elsewhere:
- Natural systems don't "root" the individual hosts, but the hosts provide enough information (via MHC II molecules) to an immutable status of what each host is doing. Anti-mal* is the opposite, wanting hooks into everything and itself being readily disabled.
- There is no hesitation to kill hosts that are suspected infected. Among many destruct mechanism is the FAS ligand activation pathway. Think of this as a lever on the outside that automatically shreds the cell and makes it easy for the acquired immune system to improve future defense. Note again that the cell is shredded; there is no "root" required for post mortem forensics.
These are just some ideas. I hope to be getting them together in a formal paper sometime soon. I look forward to comments.
This is something that I've ignored for entirely too long, so I finally just did it instead of trying to pretty up the release.
binBLAST is now available via google code (not SourceForge):
binBLAST source code
This is everything that was presented at DefCon.
This latest Adobe vulnerability has created a stir on some of the closed mailing lists regarding full disclosure. While I would have liked to think that this debate was over a long time ago, I now realize that everyone has disagreed to disagree. On one side we have the people that are doing remarkable work by researching these flaws, disclosing them with appropriate warning to the vendors, and letting the public know about the problems. On the other side of the argument are the limited disclosure people.
The advocators of limited disclosure are excellent researchers who I know and respect. It floors me to think that it is acceptable for vulnerabilities to be left unpatched for a serious amount of time. I consider 90 days to be entirely too long to patch a vulnerability. The fact that Adobe said that a patch would be issued 18 days after the public disclosure is highly irresponsible.
You can disagree with full disclosure, but it is a useful motivational tool. Microsoft responded well to their problems. They created a security development process that is unparalleled in the world. Adobe, it's time for you to step up as well. Limited or closed disclosure creates complacency, which amounts to willful neglect.
I wish there was some other way than full disclosure to motivate vendors. Unfortunately it is the only method available that has a proven track record of working.
Hey everyone. I had another membership here a while back but had to create this one.....for reasons. (See TDSS rootkit and you'll know)
There's a file infector (Detected by sophos as scribble-a)
I've done some preliminary analysis on it as of now. Just looking at infected files via ollydbg and it's looking pretty odd. About 20k is added to whichever EXE you're dealing with. It's start address is the end of *.exe + 0x000001h
Lurene Grenier from Sourcefire's Vulnerability Research Team has a good writeup on a technique to unpack the Conficker worm DLL. Thanks for going through the pain of malware analysis Lurene.
"The goal was to take the dll, and make it spit out some dns traffic so we could test our SO rule conficker dns detection engine which was written with a generation algorithm provided through the MAPP program in conjunction with Microsoft. We'd paired it down a good bit, and some information about randomness from other write-ups around the net conflicted with what was provided to us."