These are the firefox URLs for different settings. Just paste them into the browser and bang, there you go:

chrome://pippki/content/getpassword.xul
chrome://pippki/content/PrefOverlay.xul
chrome://pippki/content/pref-ssl.xul
chrome://pippki/content/pref-certs.xul
chrome://pippki/content/pref-ciphers.xul
chrome://pippki/content/cipherinfo.xul
chrome://pippki/content/ssl2ciphers.xul
chrome://pippki/content/ssl3tlsciphers.xul
chrome://pippki/content/ssl3tlsciphers2.xul
chrome://pippki/content/PageInfoOverlay.xul
chrome://pippki/content/cacertexists.xul
chrome://pippki/content/CAOverlay.xul
chrome://pippki/content/WebSitesOverlay.xul
chrome://pippki/content/OthersOverlay.xul
chrome://pippki/content/MineOverlay.xul
chrome://pippki/content/viewCertDetails.xul
chrome://pippki/content/certpicker.xul
chrome://pippki/content/certDump.xul
chrome://pippki/content/load_device.xul
chrome://pippki/content/pref-validation.xul
chrome://pippki/content/pref-masterpass.xul
chrome://pippki/content/createCertInfo.xul
chrome://pippki/content/formsigning.xul
chrome://pippki/content/changepassword.xul
chrome://pippki/content/resetpassword.xul
chrome://pippki/content/newserver.xul
chrome://pippki/content/downloadcert.xul
chrome://pippki/content/certManager.xul
chrome://pippki/content/editcacert.xul
chrome://pippki/content/editemailcert.xul
chrome://pippki/content/editsslcert.xul
chrome://pippki/content/deletecert.xul
chrome://pippki/content/getp12password.xul
chrome://pippki/content/setp12password.xul
chrome://pippki/content/domainMismatch.xul
chrome://pippki/content/serverCertExpired.xul
chrome://pippki/content/clientauthask.xul
chrome://pippki/content/certViewer.xul
chrome://pippki/content/device_manager.xul
chrome://pippki/content/choosetoken.xul
chrome://pippki/content/escrowWarn.xul
chrome://pippki/content/crlManager.xul
chrome://pippki/content/serverCrlNextupdate.xul
chrome://pippki/content/crlImportDialog.xul
chrome://pippki/content/pref-crlupdate.xul
chrome://pippki/content/getpassword.xul
chrome://pippki/content/PrefOverlay.xul
chrome://pippki/content/pref-ssl.xul
chrome://pippki/content/pref-certs.xul
chrome://pippki/content/pref-ciphers.xul
chrome://pippki/content/cipherinfo.xul
chrome://pippki/content/ssl2ciphers.xul
chrome://pippki/content/ssl3tlsciphers.xul
chrome://pippki/content/ssl3tlsciphers2.xul
chrome://pippki/content/PageInfoOverlay.xul
chrome://pippki/content/cacertexists.xul
chrome://pippki/content/CAOverlay.xul
chrome://pippki/content/WebSitesOverlay.xul
chrome://pippki/content/OthersOverlay.xul
chrome://pippki/content/MineOverlay.xul
chrome://pippki/content/viewCertDetails.xul
chrome://pippki/content/certpicker.xul
chrome://pippki/content/certDump.xul
chrome://pippki/content/load_device.xul
chrome://pippki/content/pref-validation.xul
chrome://pippki/content/pref-masterpass.xul
chrome://pippki/content/createCertInfo.xul
chrome://pippki/content/formsigning.xul
chrome://pippki/content/changepassword.xul
chrome://pippki/content/resetpassword.xul
chrome://pippki/content/newserver.xul
chrome://pippki/content/downloadcert.xul
chrome://pippki/content/certManager.xul
chrome://pippki/content/editcacert.xul
chrome://pippki/content/editemailcert.xul
chrome://pippki/content/editsslcert.xul
chrome://pippki/content/deletecert.xul
chrome://pippki/content/getp12password.xul
chrome://pippki/content/setp12password.xul
chrome://pippki/content/domainMismatch.xul
chrome://pippki/content/serverCertExpired.xul
chrome://pippki/content/clientauthask.xul
chrome://pippki/content/certViewer.xul
chrome://pippki/content/device_manager.xul
chrome://pippki/content/choosetoken.xul
chrome://pippki/content/escrowWarn.xul
chrome://pippki/content/crlManager.xul
chrome://pippki/content/serverCrlNextupdate.xul
chrome://pippki/content/crlImportDialog.xul
chrome://pippki/content/pref-crlupdate.xul 

Let’s assess the situation: You have a 3G phone which allows tethering, a windows machine, a wireless access point and another PC that is connected to the LAN port of the wireless access point (or typically called a wireless router). The wireless access point is a home network and your ISP decides to disconnect your signal or is experiencing some problems. How do you share your 3G connection, so that other computers can connect through the wireless AP and use your cell phone’s 3G connection? It’s actually quite simple.

Tether your smartphone (in this case let’s say blackberry). Blackberry tethering in Windows over AT&T is allowed using a software called AT&T Communication Manager. Install ACM, and connect your Windows machine using a mini-USB cable to your phone. Goto Start->Run->cmd.exe. Type ipconfig /all to see the IP address and the DNS servers IP addresses.

Now connect the WAN link of your Wireless access point to this Windows machine’s ethernet port. Setup a static IP for this Windows machine say 192.168.10.1 with a netmask of 255.255.255.0. Now go to Network connections (from Control Panel), right click on the Mobile connection representing your blackberry, click on Advanced. In the Internet Connection Sharing section, check the box that says “Allow other network users to connect through this computer’s Internet connection” and select “Local Area Connection” (this is the same connection you connected to the WAN port of the wireless AP). Click OK. You may have to disconnect and reconnect your ACM connection to allow the settings to take effect.

Now that this is done, connect to the administration interface of the wireless access point to the other PC that is connected to the LAN port (or through the wireless) to the access point. Go to the administration interface of the wireless AP, and set a static IP for the router in the same subnet as with the Windows box (the one you set with 192.168.10.1). Set the static IP on the AP to be say 192.168.10.2 (remember this has to be the same subnet), netmask as 255.255.255.0 and then the most important, the default gateway to 192.168.10.1 (the IP of the windows box on the ethernet card). To set the DNS server addresses, use the same addresses you found using ipconfig /all in the first step. Otherwise you could also use open DNS servers or any other DNS servers but it’ll be best to use the DNS servers pointing to the ones used by the tethered connection because you can rule out DNS issues if something isn’t working and it comes down to troubleshooting. Once on the router, the static is set, the gateway is set, the DNS is set, you should be able to connect from your wireless network to the internet through your 3G connection! 🙂
Happy internet sharing! 🙂
Here is a schematic diagram:

[tethering]                [static IP]    [static IP]   [internal IP]  [DHCP address]
                                   |         |                |           |
[ phone ] <==> [Windows machine]:eth0 <==> wan:[Wireless AP]:lan <==> [client]

cURL (groks URL) can be used as a SOAP client to send XML SOAP requests to web services. But the problems that I was facing in sending the data directly with the -d switch of curl is that DOS command shell would greet me with an error message:

< was unexpected at this time.

But there is a great way to send data in the POST requests by using the -d switch with the @ symbol. For example to send the xml data in the xmlfilewithdata.xml in the POST request to http://www.somesite.com/thewebservice you could use the following command:
curl -d @xmlfilewithdata.xml http://www.somesite.com/thewebservice

Off go all the errors and there it is …. your SOAP client – cURL!

Back in the day “recon” had a different meaning than it does today. Today, in the age of cyber-terrorism and cyber-stalking or Google stalking, reconnaissance comes from a variety of different sources including tools such as mash-up applications make things quite palpable for a social engineer. For the purpose of this discussion, let’s consider two entities “stalker” (the person seeking information about “someone”) and the “stalkee” (the “someone” whose information is being sought).
Back in the day (and man I’m only talking about 4-5 years ago!), the only source was public forums where users would post questions using constant email IDs. You would need to scourge through different Usenet groups and that was it…and possibly a Friendster account. Now, people have Facebook profiles which can be publicly viewed. This gives us the information about a person’s friends giving us information about the stalkee’s geographical location and may be even birthday. LinkedIn gives information about the stalkee’s job. You can even confirm the geographical location of the stalkee using LinkedIn. Now you have the name of the person and the geographical location. If you need more information about the person such as his/her age/birthdate, I’ve seen that ZabaSearch is a good resource. You can get a lot of information using ZabaSearch but if the stalkee needs he/she can remove this information using the block feature of Zaba located here. I do not know how they deal with this information but Zaba does have a “premium service” and I do not know if this premium service would give access to these “blocked records”. Now you have the information about the age of the stalkee. You could even search Twitter for the person’s twitter feed to see what the stalkee’s doing. I came across an interesting mashup application that crawls twitter to get information about where a person is and it’s aptly called Please Rob Me!. There are other great tools available such as Loopt and Tripit. Just as Twitter, Google Buzz can also give a lot of information. And the best part about google buzz is things are searchable …cool…the stalker’s job’s now easier.

Application or software security is a field of infinite complexity. All of us know that where there is complexity, security issues lurk around in those dark corners. This post is about my ramblings on how I believe Application Security and Incident Response need to come together to handle incidents. As usual, I make references to the cloud because that’s what I do for my day job but the argument is remarkably similar even for on-premises companies that are not in the cloud.

First came the test….

When software fails, before it is deployed, it is typically deemed to be a “safe” failure i.e., someone who is looking can do something about it. In the cloud, what makes software development easy is that the cloud makes it easy for people to look. In AWS, for example, you have Cloudwatch and you also have things like liveness checks in Load balancers which can “trigger” events and you can create “operational handlers” for those trigger events via technologies like AWS Lambda and AWS Eventbridge. This is not new to security people. For as long as I can remember, Security operations and IT Ops teams (from the pre “cyber” days), always had runbooks on what to do when something did not work as expected. Today, this happens a lot as the complexity of software has increased. The software engineers need to ensure that they have “eyes” in their test environment even more than they have in production because, quite frankly, they can have as much instrumentation as they want in the test environments because who cares if there is a minor performance impact. It’s important to re-architect so that there is no impact due to observability but you can still go to town as long as the means justify the ends. Keeping a close eye on test failures, helps avoid failures in production – this is all captain obvious advice. So in the cloud, what does that translate to? In the cloud, you can tag resources and you can have separate dashboards for those tags. Ensuring that you pay a close attention to “thresholds” on when to alert and what to do when certain measures / thresholds hit. You can also get creative in using anomaly detection tooling or “Machine Learning” (there … I said it!). The core point being – the more you are observing your test environment, the less failures you see in production. And when you see less failures in production you can do what I am going to talk about next.

Then came the failure…

When software fails in production, assuming you have been diligent in your testing and have encountered “exception handlers” either in code or in operations, it is categorized as an incident. While operational incidents are just as important and may have as much impact as security incidents, I will restrict this discussion to security incidents (because that’s what I do). What sets apart organizations such as AWS and other mature software shops from the rest of them is their rigor and approach of blameless post-mortems on security incidents. Everyone, loves to say “there will be no finger pointing” but in reality that’s really, really difficult to implement and that’s where the culture of fact-finding has a big impact on “getting to the bottom of it”. A security incident *never* happens without an error on someone’s part – this is critical to recognize. For a security incident to happen, someone had to make a mistake but its important to realize that in the security world, there is no exact science so mistakes are inevitable – what “security maturity” means is how you don’t make a knee-jerk reaction (aka scorched earth mentality) and recover from it stronger. The more maturity companies show in diving into whether the security incident involved a requirements error, design error, implementation error or deployment error tells application development teams where they can improve their development process and also tells their Application security engineers where they can improve their pre-deployment checkers or integration tests as well as areas where tooling is developed to detect deviations from security expectations (or “security invariants”). This also tells the development teams, where they can improve their developer tooling so the misses don’t recur. Also, the operations teams should determine where their checkers can do better and how the response times can be reduced to say half of what it took. Asking the question “why?” repeatedly on reasoning about the events during an incident can give a unique insight on how to improve.

Then came the win!

The situation where the AppSec, AppDev, SecOps, IT Ops teams collaborate to ensure they can help each other to do such blameless post-mortems end up having better telemetry, better tooling process, better detection when something goes wrong (“alerts”) and also a healthier environment of positive feedback. No one is blameless, recognize it, improve from it and help each other for better organizational security.

I was looking at some Oracle databases recently and I saw that the Oracle Auditing Tool (OAT) is an awesome toolset but you just need to download the classes12.zip which are the Oracle JDBC drivers for Java into that same directory. I downloaded the classes12.zip from the Oracle site and placed it into the same folder as OAT. On linux, the .sh files will then need some editing. Just replace classes111.zip to classes12.zip and off you go.
Patrik Karlsson has done an awesome job of providing these tools. You can do the whole gamut of operations using this tool from first guessing the Oracle SID to checking for default passwords using opwg.sh.
sudo ./opwg.sh -s 192.168.1.101
The above command will give you the Oracle SID for the remote database.
Once you have the sid and the credentials you can run queries using oquery.sh
sudo ./oquery.sh -s 192.168.1.101 -u DBSNMP -p DBSMP -d db_sid_found -q "select 1 from dual"
The source of the OAT is also provided here: http://www.cqure.net/tools/oat-source-1.3.1.zip. I found an interesting decompiler for Java too (when I overlooked that the sources existed on cqure.net website) and it’s called jd-gui. It works wonderfully on linux.

I recently started blogging for InfoSec Pals. It was started by Palan Annamalai who was my colleague at Ernst & Young’s Advanced Security Center where I worked for a year and a half. Other people who are active bloggers on the site apart from Palan and I are : Sri Vasudevan, Jay Kelath and Felipe Moreno. Let’s see if I can maintain the technical content of both the blogs and keep the goodies coming.