txtI just thought nevertheless it's February... here it is:
A scan-monkey's brain: a monkey brain
More automated security evaluation - via *nix Shell
I found
Jeriko through my RSS reader, announced by Gnuciticen. I think everybody has his scripts and tricks to automate parts of his work. These are some which might enhance your Shell experience constructively:
#!/bin/sh
cat << EOF
load db_sqlite2
db_create
EOF
extract-services | sed -r -e 's/^/db_add_port /' -e 's/,/ /g'
cat << EOF
db_autopwn -t
db_autopwn -e
EOF
This is kind of kewl I think. Nevertheless the source is hacked and well... not done in the most elegant way: it works. It's of course for Metasploit's db_autopwn but I guess that's obvious.
I don't see this as a pentest framework, but as something quite interesting to have. Maybe you can give it your own GUI via Rapid Application Development, maybe you can modify it, put it in a cronjob... It's just nice!
Which brings me to the point: defensive automation. I guess I'll focus on some stuff to ease hardending on a system level with system-tools. But a forensic script, which makes use of some
Shell tools isn't enough I think. My concept is usability and transparency based: I want GUI, automated scaling, much documentation. I guess for the start I'll focus on MacOS X 10.5 - because I
know the insecurities it has got. Some are inherited by FreeBSD, others are really stupid.
Buffer overflows in MD6 candidate
That's interesting. If you have a look at the problematic
MD6 code snippet:
unsigned char hashval[ (md6_c/2)*(md6_w/8) ];
#define w md6_w /* # bits in a word (64) */
#define c md6_c /* # words in compression output (16) */
Okay, so far, but:
if (z==1) /* save final chaining value in st->hashval */
{ memcpy( st->hashval, C, md6_c*(w/8) );
return MD6_SUCCESS;
}
This isn't even a mistake. But it can turn out to be problematic because the compiler implementations aren't 100% ANSI. Even GCC isn't as far as I can tell.
Conficker still isn't dead
As the VRT blog shows, you can
unpack Conficker. Looks like Lurene Grenier from Sourcefire's Vulnerability Research Team spent an awful amount of work with it. I think this is a well written write-up:
I'm not a malware gal. I really dislike analyzing the stuff. It could be an artifact of a life spent pulling apart Microsoft binaries. When Microsoft releases a binary, everything looks the same; it's not a challenge to figure out what's going on. The only challenge is how fast can you find the bug, and then how fast can you traverse the flow of the code to get there with some input. With malware though, this is anything but the case, and experience with exploitation doesn't really go very far. All you can do is apply your knowledge of asm and systems and hope you have the time to make sense of it.
IDA 5.4 is out... btw :).
Tweeted Shell-Fu
This is
pure fun! My personal favorite:
s="-<";while true;do echo -ne "$s\r";s=`sed 's/->$/-<-/;s/^>/;s/-<-/;s/>-/->/;'<<<$s`;sleep 0.1;done
Office stuff targeted
I mean seriously: Adobe has its (patched)
JavaScript 0day in the Reader because of the JS support in PDF. - Something I simply can't understand: why do you need that? But anyhow, Adobe's updater always creates problems: I had a Windows 2000 box, updated, which automatically got the new Adobe Reader versions. But these were incompatible to Windows 2000, because they nowadays just support ME+ or so. I can't say. I can say: do you know
Sumatra PDF? My favorite.
Well, Microsoft's Excel has had hilarious bugs in the past. Now we have got
this:
Microsoft Office applications have become regular targets of attacks by online criminals seeking to steal data from corporate executives using Trojan horses. Starting in 2006, the number of vulnerabilities found in Office programs jumped more than six-fold, while malicious programs that trick users into running them — known as trojans — grew to become the most popular type of attack.
Teach LaTeX to the Office people. ;) In any case manage the risk: Office applications are a problem. Outlook is a problem. Needs policies.
So long,
wishi
Post new comment