Sometimes simplest of the errors get you bad….and this was one such time.
I was trying to connect to my Oracle XE DB using SQL*Plus but kept getting this errror

connect hr/************
ERROR:
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist

Turns out I did not start the DB instance.
Start -> All Programs -> Oracle Database 10g Express Edition -> Start Database

If you are writing some Ring0 (or privileged mode code), say something like device drivers in Windows you’d probably be better served with a separate development machine and a deployment machine. This helps you to write poor code and still not lose hair because your development machine blue screens! 🙂

My setup was using a Windows 8.1 development machine and a Hyper-V based Windows 7 machine for debugging. You will need to execute different tasks on the “guest” (Hyper-V based Windows 7 virtual machine) and some other tasks on the development machine.  I followed many of the things from the MSDN blog post here

On your guest machine you would want to setup a named pipe and setup debug settings. To do that this is what you need to do:

Setup a virtual com port in the Hyper-V Settings (File -> Settings) , this port will be used to communicate from the host machine to the guest to communicate the Kernel debugging commands.

Now make sure that your target guest machine is configured to “listen” those commands.  Inside the guest VM, start a command shell (cmd.exe -> Run as Administrator).

Configure the bcdedit commands so that the machine can now be debugged.  Right after the 2nd command, reboot your Virtual Machine.

With the VM now configured to listen the debug commands via the COM1 port, and the debug mode on in the bootup settings, now start the WinDbg x64 on the host (using “Run as administrator”; you need administrative privileges for communication via Serial port).  In your kernel debugger on the host or the development machine (I’m assuming that these are both on the same physical hardware here).  Click on File -> Kernel Debug and you should see the following screen in the WinDbg window:

Hit Ctrl+Break or Debug -> Break and you will see something like this:

Just remember that when you break in the debugger, your guest in Hyper-V should become “unresponsive”.  The only thing is that it is not really unresponsive, its just being debugged.  Just to make sure, that you have the symbols package that is quite useful for debugging run the following command:

!process 0 0

If you see something like the following screen show up:

The following error means that the symbols are not defined.  Symbols help the debugger give more information about the commands that you are going to execute in the debugger.

**** NT ACTIVE PROCESS DUMP ****
NT symbols are incorrect, please fix symbols

To fix this, use the following commands:

kd> .sympath SRV*c:\symcache*http://msdl.microsoft.com/download/symbols
kd> .symfix
kd> .symfix c:\symcache
kd> !sym noisy
kd> .reload /o

Then again try the command: !process 0 0 and see if you get a good response.  A good response looks like the following:

With this you should be good to go! Happy debugging and writing cool Ring0 code.

I blogged earlier about blameless post-mortems and how one gets to a point that they are able to do blameless post-mortems – by having an operational rigor and observability. This is more of a lessons learnt post about what do you do and what you don’t when things go wrong?

Focusing on the Who?

A lot of times focusing on the “who reported the issue?” can be focusing on a wrong thing. If a report comes from a penetration test or a bug bounty researcher or an internal security engineering resource you need to make sure that the impact and likelihood is clearly understood. There are sometimes where customers (who pay or intend to pay for your service) report problems – these are obviously more important.

Focusing on the How?

How a security issue gets reported is important. As examples where you learn about a security issue via a bug report(1), or where you learn about it via your own telemetry(2) or you learn about it on Twitter! There is a potential for legal ramifications in each of these cases and the risks might be different. When things become public without your knowledge where you were not notified and the information is now public you do have a role to instill confidence in your current customers. The best approach here tends to be of sticking to facts without any speculations. If you are working on incident say so. Don’t say we are most secure when you are the subject of a breach discussion especially because you already have the data that you are not as secure. Identification and Containment of the security issue are top priorities – do not take resources that are doing these actions away to ensure Public Relations are good – doing that will eventually make public relations bad! Involve lawyers in your communications process and mark communications with right legal tags (“attorney client privileged material”) so that if a litigation happens you can clearly demarcate evidence that can be or cannot be part of a discovery.

Focusing on the What?

“What” needs to be done has to be clear with the help of an incident manager. The incident manager is the person who is most well read, subject matter expert, and leads the response process. Having this single-threaded ownership of leading the incident is incredibly important. The role of the incident manager is to ensure they have all the information that they need to make decisions. This also streamlines the process of public relations, legal needs, incident cleanup (eradication and recovery), and helps with swift and focused decision-making. This can sometimes be crisis management depending on impact and otherwise it can be just another day in the Security operations office. The key trait here is focus and goal-based decision making. Adrenaline can run high, tempers can flare – that typically happens when you are unprepared to handle security incidents. The tempers and nervousness can be avoided by being proactive in doing tabletop exercises, incident dry-runs and having good runbooks. But all practice games do is prepare you for the real thing – the real thing is how you handle a true incident. Use the help of key stakeholders to derive best decisions – there often tend to be situations where no answer looks good – and therein comes the customer focus – if you focus on the well being of customers you will rarely go wrong.

Focusing on the Why?

Capture incident response logs in tickets and communications so all the timeline and actions get captured properly with documentation. After the recovery is completed, do a blameless post-mortem of how you got there. Ensure you put a timeline of taking on agreed-upon corrective actions on a timeline that is agreed and don’t waiver – this is a part of operational rigor one needs to follow to really avoid incidents from happening in future. Typically, the reason why issues happen is because something was not prioritized as it should have been. Reprioritize to make sure you can reassess. Sometimes the size of the incident makes it your reprioritization almost coerced – it’s ok to be coerced in that direction. You will find that coercion is simply an acceleration of the actions that you should have taken up earlier. No one is perfect – just come out of it better!

Focusing on the Where?

Where you discuss the issue is important. When sizable incidents happen discuss is openly with the business leaders so that full awareness and feedback is provided in “powerful forums”. This obviously does not mean that you break your attorney client privilege – it just means discuss with the highest leaders in a manner where action items, impact and post-mortem results are provided. This enables business to become resilient over time and develop confidence in the security teams. If you need to do public releases then ensure that lawyers read it and security SMEs read it as well as business leaders read it – only then do such releases. Don’t let the “left hand meet right” situation ever occur. This instills customer confidence in your process.

Conclusion

This was just an attempt for me to pen-down my thoughts as they appeared in my brain. I am sure I forgot a lot such as stress of handling, avoiding knee-jerk reactions, etc. but these are top most important things that I felt were necessary to share. Remember, incident handling gets better with practice – you want the practice be done in practice games not in the olympics! 🙂

A very typical scenario is that by default the Tomcat Servers tend to have a 404 Error page that displays the name of the file that was requested and not found. It seems to me that though display of such pages might be considered as merely an informational item for the purpose of any security test…this definitely presents a risk.
E.g., take this scenario.
1. The attackers has a SQL injection vulnerability in an application
2. The App server and DB can reach each other
3. The DB cannot directly reach the attacker and his system (on any port outbound)
4. The app server issues 404 error messages with the name of the file being disclosed in the 404 error message (e.g., The requested resource indexblah.html was not found).
5. The attacker can see the responses to the injected SQL queries (i.e., the injection is not blind).

Assuming that the DB accesses have been tightly controlled and you can’t get much access to any tables except the current one. This can be exploited as follows:
Invoke a SQL query (in the injection string) on the DB to request a page from the app server based on the contents of the DB such as send me /blahusername, /blahpassword where /blah is a string the attacker’s put in to make sure that such a resource doesn’t actually exist on the app server and username and password are columns or DB names from the DB. These error messages will be reflected in the response to the SQL query to the attacker. This could create an interesting side-channel attack whereby even though the data from the DB doesn’t actually reach the attacker, it can be inferred from the 404 – error messages.

___________       ______________        __________
| Attacker| <===> | App server | <=====>|  DB    |
___________       ______________        __________
      1  ----------> 2  -----------------> 3
                     5  <----------------  4
                     6  -----------------> 7
      10 <---------- 9 <-----------------  8   
1. Attacker sends sql to make the db query the app server for a non-existent page
2. The app server sends this sql query to the DB
3. The DB receives this SQL query and acts on it
4. The HTTP query for a missing resource is sent to the app server
5. App server looks up the resource and can't find it
6. The App server responds with a 404 /blahusername not found
7. The response recd is put in the SQL query response
8. The SQL query response is sent to the app server
9. The App server received the SQL query response (404 /blahusername not found as a line in there)
10. The attacker receives the 404 response with the data from the username in the 404 error message  

An interesting attack vector to say the least!

Yesterday, while searching for Web Services on the Internet I came across an old, popular web service called “Amazon’s mechanical turk” based on the mechanical turk trick from old magic days.
The gist is, you (“The requestor”) put in a HIT (Human Interaction Task) in amazon’s lingo so that some one on the Internet can solve it for you (“the worker”). Most of what I saw on the website seemed like random tasks being used by researchers, online yellowpages-like directories, marketing, classification of goods, etc.
What might also be an interesting application, and I’m sure it’s probably being used for is, captcha-solving for spammers.
Also, the Amazon Mechanical Turk terms of service don’t help and say the following (verbatim):
Amazon Mechanical Turk provides a venue for third-party Requesters and third-party Providers to enter into and complete transactions. Amazon Mechanical Turk and its Affiliates are not involved in the transactions between Requesters and Providers. As a result, we have no control over the quality, safety or legality of the Services, the ability of Providers to provide the Services to Requesters’ satisfaction, or the ability of Requesters to pay for Services. We are not responsible for the actions of any Requester or Provider. We do not conduct any screening or other verification with respect to Requesters or Providers, nor do we provide any recommendations. As a Requester or a Provider, you use the Site at your own risk.

Given this, and the rates prevalent (about a penny or so per task), I think spammers might have a free-run on this service. Of course, amazon has a conveniently available web service available at http://mechanicalturk.amazonaws.com/AWSMechanicalTurk/AWSMechanicalTurkRequester.wsdl.
Now, the key question is, suppose a spammer uses this service, who’s to blame…I wouldn’t imagine the solvers know what the intent of the act is, amazon (possibly) can’t be liable because the ToS is required to be accepted before use, and since the requestor is somewhere on the Internet, he/she possibly can’t be traced.
Of course, I’m not saying that Mechanical Turk is all bad, but like all walks of life there’s a positive or a negative use to everything.
As someone once said: “Every tool is a weapon if you hold it right”!

Last night I was trying to get a VeriSign issued SSL certificate installed on my ASA using Cisco ASDM 6.2. I installed the Intermediate CA and the CA certificates all installed. I then imported the SSL certificate into the “Configuration -> Device Management -> Manage Certificates -> Identity Certificates” but it did not seem to work. I kept getting an error “Failed to parse or verify imported certificate”. The certificate was in the .p7b form. Changing the format of the certificate to X.509 Base64 Encoded format resulted in acceptance of the certificate.
I sincerely hope that Cisco alters its error messages to accurately reflect that .p7b is not a format supported by them.

Update: This link has the information on how to install SSL certificates on ASA:
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00809fcf91.shtml

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.