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 

This time the DefCon CTF challenges were really tough. After about 40 hours of straight effort in those 2 days my head was spinning. There were some nice write-ups that people have posted:
Vedagodz’s site is up at : http://shallweplayaga.me/
Pursuits Trivial 400 writeup : http://pastie.org/510841
Binary l33tness 300 writeup : http://hackerschool.org/DefconCTF/17/B300.html (based on k0rupt’s original work)
Crypto badness 400 : http://beist.org/defcon2009/defcon2009_crypto400_solution.txt

tl,dr; Blue-Green deployments for critical uptime applications is a strong deployment strategy but if a deployment fixes critical security issues be sure that the definition of “deployment complete” is decommissioning of the “blue” environment and not just deployment of “green” successfully.

Organizations have gotten used to following Continuous Integration/Continuous Deployment (CI/CD) for software releases. The use of cloud solutions such as AWS Code* utilities, Azure DevOps or Google Cloud Source repositories enables enterprises to quickly and securely accomplish CI/CD for software release cycles. Software upgrades undergo the same CI/CD tooling and the dev teams need to choose how to do the upgrades.

There are a few different ways development teams upgrade their applications – full cut-over (same infrastructure, new codebase deployed directly and migrated in one go), rolling deployments (same infra or new infra gradually upgrading all instances), immutable (brand new infra and code for each deployment and migrated in one go), blue-green deployment (same infra, simultaneously deployed in prod, gradually phasing out old instances upon successful tests from a section of traffic). The Blue-green deployment strategy has, therefore, become quite popular for modern software deployment.

What is a Blue-Green deployment?
When you release an application via Blue-Green deployment strategy you gradually shift traffic as tests succeed and your observability (Cloudwatch alarms, etc.) does not indicate any problems. You can do that via Containers (ECS/EKS/AKS/GKE) or AWS Lambda/Azure Functions/Google Cloud Functions and traffic shifting can be done with the help of DNS solutions (Route53/Azure DNS/Google Cloud DNS), Load balancing solutions (AWS Elastic Load Balancer/Azure Load Balancer/Cloud Load Balancing). Simplistically, take your current (blue) deployment and create a full stack (green) and use either DNS or load balancers to slice out a traffic section and test the “green” stack. This is all happening in production, by the way. Once everything looks good, direct all the traffic to green and decommission the “blue”. This helps maintain operational resilience and, therefore, this is a popular deployment strategy. AWS has solid whitepaper I recommend to review to dive in from a solution architecture standpoint if you are interested.

Security Considerations

Some critical security issues (e.g., remote code execution via Log4j, remote code execution via struts, etc.) demand immediate fixes because of their severity. If your blue-green deployments are going to take days and your tests will run over a very long period (say days) then any security fixes you make also will get fixed after a successful “green” deployment and “blue decommission” only. If during that window or prior, an attacker managed to get a foothold into the impacted “blue” environment, then even decommissioning of the “blue” becomes critical to claim the issue is fully remediated. Typically, when incident responders and security operations professionals breathe a sigh of relief is when the fix is deployed. Typically, the software engineering teams consider fix as deployed is when the “green” is fully handling all traffic (and its unrelated to the decommissioning of the “blue” environment). In this case, the incident responders need to remember its not the deployment time when the risk is truly mitigated, its mitigated after completion of cut-over to green and decommissioning of the blue. There is a subtle, yet important, difference here – and it really comes down to the use of shared vocabulary. As long as security operations and software development teams both have this shared definition of what deployment means, there are no misunderstandings.

Just started blogging…actually getting pretty late into the blogging culture! Studying and doing projects to complete graduation at USC. My homepage is at http://www-scf.usc.edu/~swarup/.

Seems like the pwn2own this time around is going to be putting up prizes of about $100,000+ for people who can find 0-days for a variety of platforms. Especially, the fact that about $60,000 are being devoted for 0-days on the mobile security platform including the android platform etc., indicates a new era of security bugs.
The iPhone (non-jailbroken ones) as well as the BlackBerry application do tend to use signed executables. One only hopes that like the trust-relationships of the SSL-based certificates, the trust is really kept by analyzing the blackberry and iPhone apps.
Tyler Shields from Veracode presented his work of TXSBBSpy (source code URL: http://www.veracode.com/images/txsBBSpy.java; Presentation slides: http://www.veracode.com/images/TylerShields-MonkeyBerries-ShmooCon-2010.pdf).  In this he suggested that when controlled APIs are used the code needs to be signed by RIM but to do that RIM only gets the hash and not the source code.  This presents an interesting situation where RIM could actually be signing something that they don’t really know what it seems to be doing.

I recently purchased 2x2GB Memory upgrades for my fantastic Dell XPS M1210. To upgrade the memory there were 2 slots one located at the base of the laptop (the black bottom) and the other was located below the keypad. I searched a lot on the Internet but could not find the location of the 2nd slot.
The owner’s manual also did not mention the location of the DIMM B slot (the 2nd memory slot). See the details on the manual about how to remove the keyboard to reach the 2nd memory slot.
The key to reach the 2nd slot is to first remove the hinge cover (the cover that has three button saying Power, “Media Direct”, etc.). The hinge cover is not screwed so you can just lever it up using a thin, flat object and pop-it up, remove the three screws fixing the keyboad, pulling the keyboad out and right in the middle you will see the memory slot.
Hopefully, this post will help someone upgrading memory on their Dell XPS M1210.

To avoid saving the truecrypt password in history files and mounting the Truecrypt partitions on bash the following trick helps:

history -d $((HISTCMD-1)) && sudo truecrypt --mount <PATH_TO_TRUECRYPT_VOL> --non-interactive -p <PASSWORD>

This will avoid saving the password in the .bash_history file and also mount the truecrypt volume from the command line.  Of course, if you use this in a shell script then the shell script will have the password in it, so you must not do that.