I got forwarded this link today from businesswire about how Google and Yahoo are now going to be armed with the information necessary to look at and extract information out of SWF files. Ho-boy, here we go. The link was sent to me with the “bad juju” caveat, and I’m pretty sure I agree.

The problem is, like anything, if the search engines start pulling down rich applications that actually interact with the web application, there is untold issues that could arise. For instance, Flash applications have quite a bit of rich features in them, and some of that could be dangerous if they interact with back end applications. Also, if the word “test” appears in a Flash movie, does that mean it should get indexed? Or is it a frame that’s not visible, or off the side of the page, or whatever? What if it takes ten minutes to find that particular line of text or dozens of sub-menus? Are people really going to sit for that?

Do people really want to load a Flash movie when they query for things? I know I sure don’t! I’m already annoyed when I get linked to PDF files or .docx files. I think this just takes searching to a new level where people don’t actually want to go. Instead of crawling deeper and refining their search, the search engines are going to new mediums to stave off the people (like myself) who have argued that Flash isn’t a good medium for accessibility, usability and SEO. SEO is going to be off the table soon enough, leaving accessibility and usability.

But seriously, what’s next? Are the search engines going to decompile Java applets looking for text? As a side note, this should, at least in the short term, lead to a new round of Flash hacking, once it goes live. I’ll give a tee-shirt to the first person who writes a Google dork for internal Flash text that leads to exploitation.

The new version of Kaspersky’s security suite, Internet Security 2009, features a novel but simple defense against keylogging malware — a virtual keyboard.

Full details have yet to be confirmed, but it is understood that the program will let users bring up the keyboard from which to enter login details for Web sites such as online banks that might be vulnerable. The on-screen keyboard will cache the keystrokes, protecting them from recording programs that would pick up physical keystrokes coming via the keyboard driver.

It’s not a new idea but Kaspersky is the first major security vendor to include such a feature in a standard Net security program.

The company has also announced a raft of other enhancements to Internet Security 2009, and Anti-Virus 2009, both due out this month.

Yesterday I wrote a quick proposal for the Synapse project. Since not everyone has access to the Synapse project, I will share some ideas here from time to time. I started with a proposal on how to detect Xpath vulnerabilities. Since Xpath can be used in combination with every server-side language, it is easy to write a detection flow for most languages. XPath injection attacks are similar to regular SQL injection, it is possible to inject the same kind of vectors as we normally do with a slight difference in ending syntax in most cases. This document proposes a technique on how to find them, it does not include a method in looking around a vulnerability in order to determine if functions are being called, nor variable correlation. This will be incorporated in a later phase since I like to have different levels of detecting vulnerabilities. As such this is to be treated as a loose method in locating Xpath injections. Xpath has no protection for injection, and thus it can be found in many software where programmers do not escape or use parametrized queries.

Working closely with the German hosting company – manitu, heise is making available with immediate effect a realtime DNS-based blacklist service for identifying weak SSL keys. The provider already runs the Realtime Blacklist for the iX spam filter NiX Spam, which enables mail servers to identify and filter spam.

The principle of a DNS realtime blacklist is as simple as it is elegant. An application makes a DNS enquiry for .weakSSLkeys.dnsbl.manitu.net, which arrives at the name server responsible for the weakSSLkeys.dnsbl.manitu.net domain. It checks in its lists to see whether the string – host name is there. If it is, the DNS server responds with the IP address 127.0.0.2; if it cannot find the string, it responds with 127.0.0.3. DNS blacklists normally use NXDOMAIN for a negative result. It makes little sense to do so here, however, as under certain circumstances, certificate tests cannot determine the exact error code of the DNS lookup.

The SHA1 hash value from the certificate’s modulus of the RSA key is used as the host name. All tests for weak SSL certificates use a similar fingerprinting, including the Debian Tools openssl-vulnkey and the heise networks SSL tests. The lists log keys with 512, 1024, 2048 and 4096-bits, both for 32- and 64-bit systems and little- or big-endian architectures.

All tools for the SLL certificate test can be used for the SLL blacklist service, which saves having to download and maintain the weak key lists, which now contain around 1.2 million entries. The service is provided free of charge. As only the key’s hash value is sent, there is no problem with confidentiality. Also, it is not possible to ascertain the server addresses or the URL being used from the hash value.

Now this is an oldskool topic, wardialling! Some people still ask me about wardialling tools though, so here’s one I found recently written in Python.

PAW / PAWS is a wardialing software in python. It is designed to scan for ISDN (PAWS only) and “modern” analog modems (running at 9.6kbit/s or higher). Wardialing tools are – despite their martialic naming – used to find nonauthorized modems so one can disable those and as result make access to the internal network harder.

For PAW list all numbers you want to be dialed into the (text) file “dial.lst”, one in each line – numbers only, no spaces, plus signs, dashes or slashes please.

For PAWS the numbers are accompanied by the ISDN modes to be tested in the (text) file “dial.lst” in the exact format you find in the example file (you can delete individual ISDN types, though), one in each line – numbers only, no spaces, plus signs, dashes or slashes please. A syntax check of any kind is effectively non-existant, so be careful.

Make sure the device your modem is attached to is set correctly in paw.py in the variable “tty” at the top of the file.

Then simply call “./paw.py” or “./paws.py” and watch – a verbatim full log will be written into paw_dialing.log where CR, LF and TAB will be translated into readable equivalents. For PAW an additional summary will be written as CSV file in paw_dialing.csv