I was using the vpnc the other day on my Backtrack 4 R2 system to log in to VPN. I noticed that there was nothing that would give me the status of whether or not the tunnel was up. So I wrote a small one-liner to help me:

while [ `ps aux |grep vpnc|grep -v grep|awk '{print $2}'` ] ; do printf "Connected\r"; done


i updated my backtrack 4 R1 finally using the directions mentioned here. However, after the upgrade my Intel Corporation Wireless WiFi Link 5100 wireless adapter stopped working. My first thought was that the driver was corrupted or something after the upgrade.
But looking through the ‘dmesg‘ command output it became clear that during the startup a particular file iwlwifi-5000-2.ucode could not be located. I thought a reinstall will do it (always works right?).
# apt-get install firmware-iwlwifi
No luck yet! Searching for these files showed me that they were in two locations and both of these were identical (verified via md5sum) :
/lib/firmware-2.6.30.9/iwlwifi-5000-2.ucode
/lib/firmware-2.6.34/iwlwifi-5000-2.ucode
So I just added a symbolic link as follows:
ln -s /lib/firmware-2.6.34/iwlwifi-5000-2.ucode /lib/firmware-2.6.35.8/iwlwifi-5000-2.ucode
Voila! It now worked! Hope it helps!

There was a persistent cross-site scripting (XSS) vulnerability in Apache ActiveMQ console that could be triggered by an anonymous user. The stored XSS issues tend to be worse that reflected ones because they necessarily do not need any social engineering. Especially, in cases where an anonymous user can inject the payloads.
The link to the advisory is here.
Update April 8, 2010:
It turns out that there were many more variables vulnerable to the XSS attacks and not all the issues had been fixed. Dejan Bosanac (the ActiveMQ developer) has now put in more fixes to close out the issue.

An interesting thing happened today …I was trying to redirect some input to /dev/null in cygwin…using something like:
some_exec -p params 2>&/dev/null | grep blah
I kept getting an error : bash: Ambiguous redirect.
I then realized that I should probably doing a simple direct and not a re-direct…seemed to solve my problem. Come to think of it…it makes sense, why should I need to redirect when I’m sending it to /dev/null…should simply be able to direct it using:
some_exec -p paraa 2>/dev/null | grep blah

I recently came back from the ToorConX in San Diego, CA. It was a great conference with some really cool talks. Especially RFD (Remote file download using blind sql injection), reversing malware using browser hooking, cracking crypt() hashes using Ps3, grey box peach fuzz xml generation tool (nunchaku), voip eavesdropping, bypassing browser memory protection.
These were some really cool talks but I still don’t have access to any presentation slides yet for the con. May be those will be posted some time.

Long time since I posted anything here …. but it’s just been those times been busy as a bee. So securing Cisco routers is a big deal especially since the routers (especially the edge routers) can be critical to any organizations infrastructure. I am not a Cisco guru but am only a student. However, I thought I should create a list that could help me perform security reviews of routers.
Security of routers is important as attackers could add static routes, advertise bad BGP neighbours on edge routers, create inbound tunnel into the intranets and such. Therefore, it’s imperative that adequate efforts be put in to secure Cisco routers.

I thought I’ll put in my first attempt at creating a small checklist:

1. Use SSH for non-console access (“line vty” command should not have telnet in it)
2. Use class 5 passwords, do *not* use class 7 passwords as they’re easily reversed (“enable secret”) alongwith the use of strong passez
3. Limit virtual terminal access by using an ACL
      access-list 100 permit 10.10.10.10 log
      access-list 100 permit 10.10.10.11 log
      access-list deny any log
      line vty 0 4
       access-class 100 in
4. Disable Proxy ARP on each interface (“no ip proxy arp”)
5. Disable CDP as it can be used for information disclosures (“no cdp run”)
6. Use AAA (TACACS+ or RADIUS) (“aaa new-model”, “aaa authentication”, etc.)
7. Use “access-list ACL_NAME deny ip any any log” at the end of each ACL
8. Disable http server (“no ip http server”)
9. Keep the IOS versions updated
10. Set centralized logging using a syslog (“logging internal_ip_address”)
11. Configure NTP to keep the time synchronization (“ntp server 129.6.15.28”)
12. Disable TCP and UDP small services e.g., echo, chargen, discard, etc. (“no service tcp-small-servers” and “no service udp-small-servers”)
13. Put RFC 1918 (ingress filtering) protections using ACLs
       access-list 100 deny ip 127.0.0.0 0.255.255.255 any log
       access-list 100 deny ip 10.0.0.0 0.255.255.255 any log
       access-list 100 deny ip 192.168.0.0 0.0.255.255 any log
       access-list 100 deny ip 172.16.0.0 0.15.255.255 any log
14. Put some more filtering for common IPs
       access-list 100 deny ip 169.254.0.0 0.0.255.255 any log
15. Use SNMPv3 with ACLs if you must (“snmp-server v3 auth priv”)
16. Use SSHv2 (“ip ssh version 2”)
17. Try to use EIGRP instead of RIP/OSPF (“ip authentication mode eigrp N md5”)
18. Use MD5 authentication for RIP/OSPF if you must use these protocols (RIPv2/OSPF)
    (“ip rip authentication mode md5”)
19. For edge routers using BGP authentication (if possible)
       router bgp 10
        neighbor 10.10.10.10 password Cr4zY$%^
20. Configure BGP route flap dampening that prevents BGP oscillations (“bgp dampening”)
21. Use warning banners that could be used for legal purposes for prosecuting hackers