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 

If this is the error you are getting then one of the solutions is to reset your root password on the MySQL database server.

$ pkill mysql
$ sudo mysqld --skip-grant-privileges
$ mysql

At this point you get the mysql command shell. You will need to update the root password and flush the table when you reset the password.

mysql> set UPDATE mysql.user SET Password=PASSWORD('YOUR_NEW_PASSWORD') WHERE User='root';
mysql> FLUSH PRIVILEGES;

Now that you’ve flushed your passwords, just restart your mysql daemon.

$ sudo pkill mysqld
$ sudo /etc/init.d/mysqld start
$ mysql -u root -p
Enter Password: YOUR_NEW_PASSWORD
mysql>

You should be all set now!

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 wrote a very small script to set static IPs on a kubuntu box.

#!/bin/bash
if [ $# -lt 4 ]
then
    echo "Usage: $0 <interface> <ip> <netmask> <gateway> <dns1>"
exit
fi
ifconfig $1 $2 netmask $3
echo "Static IP set"
route add default gw $4
echo "Routes added"
if [ "$5" != "" ]
then
    echo "nameserver $5" >>/etc/resolv.conf
fi
echo "DNS set"

There has been a lot that’s being said about the use of AI in Cyber Security. This is for good reasons – people have said here and folks in information security (as we have called “cyber security” for decades now) have experienced first-hand. It’s only natural that already stretched InfoSec teams look at AI as the “saviour” to the skills / personnel gap to close it. Then again, there is a lot being said about companies selling products as “AI enabled” too.

But realistically speaking are there some things traditional organizations (“non-AI”) can do to actually do what many of these “AI enabled” products do? I wouldn’t have written this blog post now would I if the answer was anything but yes! 🙂

Let’s look at them:

1. Anomaly Detection – this is age old! Almost all security tools that “alert” us on something are essentially using this. How well? That’s debatable. The kind of anomaly detection that I am talking about is simple (but different). For example, abnormal login attempts on your Internet-facing systems is anomaly detection. So is abnormality of DNS queries. Your Cloudtrail logs (in AWS) showing an inordinate spend on EC2 instances is also anomaly. A abnormally small amount of time spent between a git commit and a production deployment of that commit is also odd! Your SaaS or Okta bill being high or your APIs getting throttled (without any known changes) are all anomalies. The response time for these depends on whether or not you have been able to automate these anomalies. The day you automate these “known” anomalies you are already doing what many of these “AI enabled” products are doing today (after of course charging you an arm and leg!)
2. UBA / User behavior analytics – a lot of products do that but the most simplistic things are reduction of logins / preventing logon from areas where you do not expect your users to originate from. This is “reduction” of attack surface. Is that foolproof? Hell no! Why? Generally, speaking adversaries do not attack systems from their home computers. Adversaries operate by using trampoline servers (sometimes layers of them) to send the attack from the “attacker controlled bots”. But it reduces your area of concentration. And then you can use UBA more effectively since you do know where your users are expected from at a macro level. To improve your “AI-ness” you can then add capabilities which are able to say not at a macro-level but on a per user level where that specific user is expected to originate from. And if it looks abnormal (or anomalous) then ask them to step up. There are numerous vendors in this space as well as products on the cheap which you could do. There are open source libraries that can also help you do that on the cheap. Again, something very expensive “AI enabled” products can do too.

I am sure there are many other things that as an organization one can start doing. Obviously, at the end of the day, every initiative takes resources and by no means are any of these simple but YMMV depending the size of your datasets, users, and organizations.

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.

So the other day I was on a pen test and I got hold of the hashes. Since my laptop got fried I needed a new version of SMBProxy. There were a few issues that I had with the compilation though. I got a few errors in the file crypto.c.
Moreover, SMBProxy ues crypto library libdes written by Eric Young available here.
I give here a guide to compiling SMBProxy that worked for me.

First, compile and install libdes

1. Download libdes 4.01
2. tar zxvf libdes-4.01.tar.gz
3. cd libdes
4. make gcc
5. sudo make install

Now, you’ll find that the file libdes.a is now in /usr/local/lib.
Second, compile and install SMBProxy. Now here there were a couple of compilation errors that I had to deal with.
Here’s the diff output for crypto.c

trance@z0n3:~/Desktop$ diff smbproxy/crypto.c smbproxy-orig-src/crypto.c
40,41c40
< #include
< #define MD4_SIGNATURE_SIZE 16 --- >
46c45
<> static u_char Get7Bits(UCHAR *input, int startBit) {
58c57
<> static void MakeKey(UCHAR *key, UCHAR *des_key) {
74c73
<> void DesEncrypt(UCHAR *clear, UCHAR *key, UCHAR *cipher) {
85c84
<> void mkResponse(UCHAR **ntlmhash, UCHAR hash[MD4_SIGNATURE_SIZE], UCHAR* challenge) {
88c87
<> UCHAR ntlm_response[24];

Having done this there were still a few issues with the make comand.
The Makefile can be generated by running the following command:

trance@z0n3:~/Desktop/smbproxy-orig-src$ ./configure

Here’s the diff output of the Makefile:

trance@z0n3:~/Desktop$ diff smbproxy/Makefile smbproxy-orig-src/Makefile
10,11c10,11
< smbbf_include =" -Iinclude">
< libs ="">
—
> SMBBF_INCLUDE = -Iinclude
> LIBS = des
31c31
< $(LIBDES) $(LIBS)
—
> $(LIBDES)

The following libraries are required: openssl, openssl-dev, libdes for successfully compiling SMBProxy.

apt-get install openssl openssl-dev