Diego Doval released beta of CleverCactus Share recently.  It's not a mindblowing invention, but a useful rendition of a private P2P file sharing network tool.  It's missing a key feature though: sharing needs and wants.  But then no P2P software has this feature yet so I hope CleverCactus Share becomes the first to implement this breakthrough feature.

A network of people can cover far more ground than a single person.  Each member sharing what they have is good, but not as good as having everyone knowing the needs of others and everyone searching together.  I had this strain of ideas for a long time BTW, long enough to get and then abandon groupsearch.com domain.

Wishlist allows you do that by having each person 'share' not only what they have, but also share what they need or want.  UI-wise, each 'wish' looks much like a file and are placed in the shared object list.  Others can download it to their own share list to 'share' the interest.  When a member finds the data, they drop it into the 'wish' object to 'fullfill' it.  Members who shared the 'wish' will automatically have their wish come true.

FYI, this post started off as an April 1st joke but I soon realized that the concept of sharing 'ahead of time' is actually useful.  So the joke was on me instead.  🙂

Anti-Phishing Working Group finally issued a Threat Advisory Alert on the problem I outlined and demonstrated in my Visual Spoofing post (via Payments News).  In my demo, I used a simple bitmap for the fake address bar because I didn't want to spend more than a few minutes on the demo.  A hacker with some talent and more time could create a fake address bar that behaves just like the real one which is what the advisory warns against.

The advisory mentioned that fake address bar could persist which is probably done by loading real websites in a frame under the address bar.  A properly written business web pages should be able to detect this and either refuse to load as a frame or 'popout' of the frame.

BTW, both of the 'clues' the advisory points to can be worked around by simulating overlapping windows visually to confuse the users.  So the advisory offers no real solutions against the threat.

Anyhow, I am glad they finally recognized the threat as "one of the most sophisticated phishing attacks that we have yet detected, and has serious security implications for consumers" although they haven't bothered to mention me nor my post.

Phishing through blogs

Meanwhile, Technorati still haven't responded to the threat outlined in my Cross-Site Scripting Network post despite the warnings I gave them through e-mail and blog comment.  The threat could lead to a storm of XSS-based phishing attacks using thousands of blogs.  I wrote the post because I felt the HTML fragment, used by Technorati to allow bloggers to claim their blogs, opens XSS vulnerability across claimed blogs if Technorati website is penetrated.  Considering the furious pace of change at websites like Technorati, I think the likelyness of penetration is high enough to make the threat real.

I will be posting in the future about how phishers might use blogs to lauch phishing attacks.  For now, I want to eliminate the threat I described above because the scale of attack in that threat scenario is impossible to ignore.

Update:

I have joined APWG and will be attending APWG meeting in San Francisco Monday.  They don't normally allow consultants to join, but some of their members are my clients so I got in.  Will post about the event on Tuesday unless APWG has a no blogging policy.

VS6 SP6, latest service pack for Visual Studio 6.0, is out.  Looking at the bugfix list, I'll have to upgrade soon or later for legacy projects.  Here is a choice selection of bugfixes:

1. CRT string format functions may underwrite buffer.
2. ISAPI DLLs that are built with MFC static libraries are vulnerable to Denial of Service attacks.
3. Visual C++ 6.0 Optimizer may generate code that experiences access violations
4. Inline functions return incorrect results when you specify the /Gx and /Ob1 compiler options for optimization
5. VCSpawn fails during build.

I wonder if SP6 fixes frequent build state corruption?  Having to rebuild completely over and over is not fun.

Blogs are highly linked and implicit trust accumulates at each blog up over time.  Many windows of vulnerability exists in blogosphere and many more are being opened everyday though unsafe cross-site script sharing, holes in scripts that run blogs, wreckless copy-and-paste practices (what you see might not be all that you copied), etc.  Net result is a growing field of dominos waiting for smart hackers to take advantage of.

Here is an example.  Some websites, popular among bloggers, encourage bloggers to add some HTML fragments into their blogs that looks like this:

  

This is, in fact, committing cross-site scripting (XSS) voluntarily.  Even worse, because hubsite.com typically offers some useful service, a cross-site scripting network is created around hubsite.com, turning hubsite.com into a very attractive target for hackers.

Once hubsite.com is penetrated and bar.js replaced with some hostile script, hackers can not only steal cookies but hack all the pages served by spoke sites.  How bad can it get?  Hackers can search links to well known sites like Paypal in all the pages that loads the hacker's script file and replace them with links to phishing sites.  Even worse, hackers could drop in zero-day exploits into thousands of blogs within minutes.

Update:

I had to replace the HTML fragment above with an image to prevent the tags from being inadvertently pasted into other blogs.  With all the escaping, unescaping, copying, and pasting in blog softwares out there, I can't take a chance.

Edwin Khodabakchian, CEO of Collaxa, enumerates the shortcomings of BPELJ, a joint-proposal from BEA and IBM for skintight integration of BPEL and Java.  In summary, BPELJ introduces new elements (code, value, package, snippet, etc.) for embedding and using Java code snippets in BPEL4WS files to specify variables, join conditions, partner links, correlation sets, and other extension points.  Since Collaxa is the leading vendor of BPEL servers and tools for J2EE, Edwin's observations are important IMHO.

BTW, I have to note that the BPELJ whitepaper (PDF) does mention briefly about supporting other languages although I am not sure how deeply and sincerely that support is.  After all, that 'J' in the name means something.  In comparison, Biztalk use of CLR (.NET VM) supports multiple languages.  Still, Biztalk is a wonderful sword with the vendor lock-in curse.  BPELJ looks similarly cursed with Java language lock-in.

Is being locked-in vendor or language-wise really bad considering J2EE is a binding marriage with Java and most of the corporate IT shops are Microsoft addicts?  I guess the answer depends on whether one cares about being tied down or not.  After 12 years of marriage, I try not to think about the question too much. 🙂

Update:

Another well thought out opinion against BPELJ (PDF) by Howard Smith, co-author of the book BPM the Third Wave (book site with extensive excerpts).

Version 1.0 of libbt, an open source C library that implements the BitTorrent protocol, is released.  Get the bits here.  You'll need it if you want to add BitTorrent support in your news aggregator.

Two must-have features I am planning to add to PhishGuard are:

• Require the user to approve hyperlink activation from within e-mail clients using a security dialog that clearly displays destination URL.
• Disable all hyperlinks in e-mail clients

Implementing these two features for just Outlook and Outlook Express should stop most phishing attacks on Windows platforms.  It's a brutal solution, but I am sure there are plenty of IT guys who are dying to wield these two lovely hammers.

BTW, I somehow ended up as the top Google result for Phishing Toolbar.  I guess Phishing Hammer is next.

Anti-Phishing Working Group (APWG) is an industry group whose mission is to:

1. Share information and best practices
2. Identify the size and cost of the phishing problem
3. Promote visibility and adoption of industry solutions

I like what the group is about and what they are doing but it's not apparent how an independent consultant/developer like me can easily participate.  APWG membership is only available to eligible organizations without specifying who or what dictates eligibility.  Also, I don't like the idea of having to pay to contribute my time to the group activities.  It would be nice if they had something similar to W3C's Invited Expert status for membership.

Anyhow, APWG is meeting in San Francisco on April 5th.  I have asked them if I can attend the meeting but haven't heard from them yet.

This morning, I got a phishing e-mail pointing to:

http://www.securecitibank.us

It won't be long before domain name registars are forced to treat phishing target names specially to prevent this sort of things from happening.

PhishGuard TODO: If a link's textual content appears to be a URL yet differs from the link's URL, flag it as a possible phishing attempt.

Reusing passwords is common and many paranoid-yet-lazy engineers have adopted the habit of appending or prepending their 'universal' passwords with domain names.  In reality, such practice is not very secure because the password can be easily deduced if any of the machines are broken into.

Dan Boneh's Stanford Applied Crypto Group, which created SpoofGuard and Identify Based Encryption (the technology behind Voltage), is using an automated variation of the scheme to let users reuse passwords at multiple sites with arguably acceptable level of risk.  The idea is to detect password fields using a browser plugin and replace passwords entered with site-specific passwords calculated like this:

    site-pwd = hash(domain-name + reused-pwd + universal-pwd)

universal-pwd is needed for protecting against dictionary attacks.

I like the general idea but there are many implementation and usability issues yet to be solved, some listed in their PowerPoint presentation and some not such as password length limitation and password field spoofing.  Still, I think the idea is useful when combined with other ideas and am looking forward to their demo.

BTW, SpoofGuard also uses password hashing using server-provided salt to protect password reuse, but I don't think server-provided salt alone provides much value.  Also, I think they gave up on per-user salt too easily.  Anyhow, I am impressed with the work Stanford ACG is doing because they are not afraid to roam outside the crypto realm to find creative solutions.

Update:

One important side-effect of above password hashing scheme, which I neglected to mention, is that passwords cannot be 'phished' without DNS poisoning because the domain name will be different.  Neat, eh?