Tag Archives: security flaws

Top Articles & WordPress Session Hijacking

The blog has successfully been migrated to the new self-hosted WordPress (forensicsblog.org), simple name, same great flavor! We’ve got a double feature for you this evening. First, is a list of some of the articles generating the most views on here (thank you for reading!), followed by some WordPress Session Hijacking resources.

Also, please take the time to visit some of the great forensics resources along the right side of the blog. I’ve tried to keep the list to (in my mind) the most interesting blogs/bloggers in information security. They all have great content and research worth reading.

Top Articles on fork()

  • Research: GPS Device Analysis” — research on the manual forensic examination of a Garmin Nüvi 1490. Piece includes a comprehensive breakdown of the GPX file structure, how it’s used to store trackpoint data and information on GPS metadata.
  • Thoughts on viaExtract (Demo)” — discusses the viaExtract utility designed by viaForensics for the analysis of android devices. Highlights artifact extraction with AFLogical and viaExtract case reports. Also discusses the Santoku Linux distribution for mobile forensics.
  • Updates to GPS Utility (Timestamp Features)” — TrackerCat’s latest post to date: adds timestamp extraction of trackpoint data within GPX files to CSV file format. Also includes the ability to recursively export GPX files from a user-specified path and displays embedded file metadata time.

There are a lot more interesting posts here so be sure and scroll down or use the Monthly Archives menu on the side panel. You can also use the site-wide search for topics such as “encryption” or “OpenPGP.”

WordPress Session Hijacking

Since I’ve been tinkering with this blog, I’ve noticed that WordPress is still vulnerable to session cookie hijacking. This is a topic that WordPress or plugin developers should address in much greater detail since many use WP as a site-wide CMS. This section is to share some links on the subject and increase awareness of it.

To those that may not know, session hijacking is when an attacker copies authenticated session cookies from an authorized user and uses them as his own. This is done by first monitoring unencrypted network traffic and then modifying the appropriate cookie and sending it back to the server. HTTP or poorly implemented HTTPS are most at risk. There’s nothing new about this and it’s extremely simple to execute.

These sources can be invaluable for understanding and mitigating the risk:

There are too many MITM tools to list. I’ve included the Fern link to demonstrate how such attacks can be carried out over a wireless network. The following tools are for either modifying HTTP headers or crafting clone cookies:

Almost every new installation of WP.org I’ve seen is susceptible to this attack. WordPress recommends using HTTPS. If you don’t have SSL enabled on your site or haven’t set up HTTPS properly, your site could be at risk. Other forms of risk mitigation include:

  • Use a trustworthy VPN when logging into a WordPress to prevent eavesdropping. If using a mobile device or laptop to access your blog a VPN is the simplest way to ensure your safety on an public hotspot.
  • The Safer Cookies Plugin by Janis Elsts which restricts an IP address to one session at a time, solving half the problem for blog owners. It would have been nice to see this as an option in out-of-the-box WordPress. It’s almost ludicrous that WP doesn’t come with a feature like this (even Facebook allows for terminating multiple simultaneous sessions).
  • Deploy WP security suites and WP firewall plugins such as Cloudflare Threat Management, WordfenceBetter WP Security or Bulletproof Security. Firewalls don’t protect against session hijacking directly but helps by adding IP-based controls such as blacklisting and white listing single IPs or addresses within a specific range. They may slow down the site’s loading speed but they’re worth it.
  • WordPress login control plugins are extremely useful to setup on your blog. There’s Login Lockdown and Lockdown WP Admin. The first provides excellent rules for login expiration and maximum login attempts before an account is locked down. The second offers the ability to hide the WP admin page from individuals that aren’t logged in. It also has the option of making logins use basic HTTP authentication (but without SSL, that isn’t as secure as it sounds).
  • Sandboxing. If an attacker does gain a foothold by accessing an account, make sure it isn’t your admin account (if you’re using your WP admin account to log in regularly, you shouldn’t be doing it from an open wifi network beyond your control). Also make sure your account’s user directory and all files within it are safe (this is critical if you’re using WP plugins that allow you access to modify files without having to FTP/SFTP in).

WordPress has yet to come up with a fix for this type of attack as it’s considered “low priority.” This is probably due to the fact that this attack isn’t direct, it’s passive and requires being in a position to capture network data. The problem is that WordPress isn’t necessarily responsible; HTTP is not secure and website owners should be aware of this threat.

Hope you found the resources above interesting. Thanks for reading!

Links – PGP Security

If you use PGP, as I do, you’ll want to read an old but useful article on pgp.net: “Security Questions” @ pgp.net as it covers a whole slew of topics ranging from how secure asymmetric cryptography can be to possible security threats arising from using PGP. Essentially if you have a good passphrase you’re better off than folks without one.

Similarly, this article explains passphrase safety tips: http://www.wowarea.com/english/help/pwd.htm — similar to the previous article mentioned which mentions TEMPEST*, this discusses things like a hidden microphone, camera, stolen swap files, access to your hard disk or other medium where private keys are stored, not using drive wiping technologies, key loggers, recovery software and EM microscopes on junked hard drives, viruses, Trojans and more.

* Some useful sites dealing with information on the old TEMPEST attack can be found using these sites:

http://en.wikipedia.org/wiki/Tempest_(codename)
http://www.surasoft.com/articles/tempest.php

With modern technologies and, being a regular citizen as opposed to an enemy of the state, your probably safe!

While it wasn’t designed specifically for asymmetric key passphrases, the GRC’s Haystack Password checker can be used as a starting point for developing safe habits: https://www.grc.com/haystack.htm

Also, in GPG anyway, if you ever find yourself needing to explain what a particular encrypted message is you can always perform a session key override:

--show-session-key (file)

Followed by:

--override-session-key (session key hash) (file)

The former will reveal a unique encrypted session key string, which is derived from your public key but is different than your secret key. The latter will enable you to decrypt a single text/file without you having to give any sensitive information. This is very useful if you have a naggy wife (or husband)!

Lastly Schneier’s article regarding the flaws of public key infrastructure is a must read.

The sites above make for some good reading and could help you safeguard your data appropriately.

EDIT: If you are subscribed to the blog, sorry for the multiple emails for the same post. Seems to have been some sort of problem with the CSS but it seems to be fixed now.

IPv6 Security Issues

There’s a lot of talk about IPv6 having a number of security flaws. I thought I’d summarize some of them and address them accordingly. What follows is an enthusiasts’ view of the issues at stake gained by reading up on the issue through various sources.

Security Concerns

1) The argument that federal and state law enforcement will be hard pressed to be able to track criminals over the internet is also a benefit for those preaching anonymity online. Since IPv6 addressing is considerably more complex than their IPv4 counterparts, spanning multiple subnets, some security experts warn users against it entirely.

IPv6, currently being favored for use over on the popular uTorrret Bit Torrent client serves as a proponent to IPv6, saying Teredo tunneling enables a more effective means of sharing data between older operating systems (Teredo = backward compatibility between 6 and 4).

Could the prospect of anonymity have been a driving force in the adoption of IPv6 for torrent use? Possibly but not likely considering there are net tools available for IPv6 (such as SubnetOnline and many others, makes you wonder why the FBI is so concerned if tools are available, even if not so widespread yet).

Source: IPv6 good for criminals, says FBI and DEA | Digital Trends
Source: Teredo tunneling – Wikipedia, the free encyclopedia
Source: IPv6 – Wikipedia, the free encyclopedia

2) IPv6 may or may not be more susceptible to mass DDoS attacks and MITM attacks or at least ones which are not presently protected against by common routers and/or firewalls, the debate is still up in the air. If interested, there is a white paper that I’ve found that discusses the effects of DDoS with IPv6’s new IPSec protection configured and without it (covers TCP, UDP, ICMP flooding and Smurf attacks; check it here).

One exploit toolkit known as THC-IPV6 (THC-IPV6 – attacking the IPV6 protocol suite) has been particularly problematic as it contains ICMP flood tools, network listeners, ARP poisoning tool which actually fakes the network into believing you are a router, MITM traffic redistribution tools, DOS detection, IDS, ICMP6/TCP-SYN traceroute, network fuzzers, smurfers and countless other tools. The only safety users have against this is a really strong modern firewall and/or network policy. (Source of Note: thc-ipv6 Toolkit – Attacking the IPV6 Protocol | Darknet – The Darkside)

To summarize but counter the concerns, ZDNet said the following on their blog:

True, IPv6 incorporates Internet Protocol Security (IPsec), but by itself that doesn’t buy you any more security. IPv6’s header design also lends itself to better security since it can be used to provide to a cleaner division between encryption meta-data and the encrypted payload. In addition IPv6’s huge address space can be deployed to scanning attacks harder by allocating random addresses within subnets. But, those are all matters on how you deploy IPv6. In and of itself, IPv6 won’t make you any more secure than your childhood blue blanket.

First IPv6 Distibuted Denial of Service Attacks Seen, ZDNet

So although attacks can be larger spread if the implementation of IPv6 is handled improperly (across entire subnets), this is a deployment problem not a problem inherent in the protocol itself. Furthermore, on an individual level, as more firewalls support IPv6 so too will we see a decline in the attacks available to those using IPv6 on their network.

3) Route Header Security Concerns – a packet’s route header can be used to specify where and how to strike a particular target. This concern is mentioned in the following presentation: http://meetings.ripe.net/ripe-54/presentations/IPv6_Routing_Header.pdf Possible solutions is better packet routing by ISPs as they become more equipped to handle IPv6 as well as more advanced firewalls and security schemes.

Conclusion

So essentially what we see is a growing technology, still very much in its infancy, becoming more predominant by the day. Hopefully as IPv6 is adopted so to will public awareness of the security risks increase. It’s also my belief that software vendors and internet service providers alike should work together to better address such issues.

IPv6 may have started slow but it may be here to stay.