<![CDATA[[SecurityRatty] tag: poc]]> http://securityratty.com/tag/poc Tue, 27 Nov 2007 05:37:00 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[Patch For Android Security Flaw Released By Google And T-Mobile]]> http://securityratty.com/article/19b72914c0f8ef9bfa06abe0e1fe70dc http://securityratty.com/article/19b72914c0f8ef9bfa06abe0e1fe70dc Tue, 04 Nov 2008 23:30:58 +0000 google google android mobile patch system users flaw security hole weekend poc Patch For Android Security Flaw Released By Google And T-Mobile <![CDATA[Another Google Bug Put Users At Phishing Risk Due To Domain Flaw And Frame Injection Possibility]]> http://securityratty.com/article/a3a826883c2875f86d3d818f4095efc1 http://securityratty.com/article/a3a826883c2875f86d3d818f4095efc1 Fri, 10 Oct 2008 19:05:05 +0000 sensitive google services users login credentials spoof pages adrian pastor security flaws google calendar security expert attack collective Another Google Bug Put Users At Phishing Risk Due To Domain Flaw And Frame Injection Possibility <![CDATA[Is an incorrectly implemented security program better than a non-existent one ?]]> http://securityratty.com/article/5893399324f415d7cb19e54c1340401b http://securityratty.com/article/5893399324f415d7cb19e54c1340401b carefully on this one. Think long term. Think about implementation hurdles, think about project documentation.

The answer to this IMHO is a big "DEPENDS".

To explain:

Imagine you're working in a company that has no security controls in place - and is in desperate need of getting a security program impemented. They hire a new CISO to make sure their physical and logical controls are in place, network and applications are secured appropriately and their incident management and forensics capabilities are upto date. At this point the CISO clearly knows that he needs to create and implement a number of programs and hires a bunch of people to perform and manage a series of tasks. Till this point, things are going smoothly. Everyone understands the need, and is working towards meeting a common goal. The program is not in place yet, but people know and understand the urgency need to act immediately. The CISO's risk radar has a list of projects ranked by priority and everone begins to tackle them.

Now consider the scenario when certain security programs are not done right - say, a few of the high risk applications are not considered in the initial risk matrix or there are certain business units that have been granted an 'exception'to the process that is being put in place, with the most common excuses of:

1. This is a pilot
2. We will get to this in the next phase
3. The group has a number of high profile clients who don't want it implemented right now
4. <plug your own excuse here>

Well - initially, everyone is completely aware that they have more issues to remediate and and have honest intentions to fix that too, once the pilot and
PoC is well established and in place. But then things change. Leaders change. Managers change. People's roles change. What doesn't, is the documentation regarding the project. But documents usually tend to highlight what the project does, not what it doesn't do. Nobody seems to remember there are additional tasks that need to get completed. People take a quick look at documents detailing what was done in the program and begin to assume that it is well established, completely ignoring the fact that a very important Phase 2 still needs to be in place. A false sense of security is now well in place... and life goes on.

Till you get hacked.

..and then a forensics team attempts to determine the cause. A new CISO comes in, reviews the existing program, decides it is too complex and structureless and decides to do away with it entirely and create a new security program.. and the cycle continues.

The moral of the story: When you have no security program - be very careful while diligently working to get one in place

But when you have a partial one, be extremely careful and don't leave any loose ends while getting it completely and correctly put in place.


On a lighter note - here's an email I received from a school I was doing some courses from ..

Beautiful !! Here is your PIN (username). But we will not give you your password over email. I was sooo impressed when I got that! - Could it be that schools and universities are finally waking up and trying to understand security ? No more SSNs as IDs ? No more default 'password' passwords ? This was great. I followed the procedure outlined to receive a new password - it asked for my name, DOB and email.. and then .. I receive this:




For those who cannot see the image:


the email says:

blah blah blah blah blah blah..
your PIN:
your password: password1234

blah blah blah blah blah blah]]> Wed, 03 Sep 2008 12:02:00 +0000 security security program program security controls change leaders change programs security programs roles change Is an incorrectly implemented security program better than a non-existent one ? <![CDATA[Some Burning Logging Questions - Answered!]]> http://securityratty.com/article/d9d6f72f9a5cc1e9a8b472fe3df3a204 http://securityratty.com/article/d9d6f72f9a5cc1e9a8b472fe3df3a204 I was wandering down a street and somebody came out and confronted me with these logging questions :-) So I answered them - now I am posting them here since they might be useful for my readers.

Q1: For those companies that have successfully implemented enterprise-wide logging, what were the big nasty surprises that they encountered?

A1: Here are a few:

  • political boundaries within the organization: "these are our logs, and you are not getting them"
  • privacy laws: some logs cannot be collected in some countries; some cannot cross the border, some cannot be seen by some people, etc. This is true mostly in EU, less in US.
  • legal blocks: work with legal before deploying any org-wide log management; legal might try to prevent certain data from ever being created (for fear of being legally discovered later)
  • log volume: underestimating log volume is common and pretty nasty
  • related to the last one: vendors being "optimistic" about their tool scalability
  • time synchronization (of course!), specifically, lack thereof.

Q2: For those companies that have successfully implemented enterprise-wide logging, what was their implementation approach?

A2: Typically, 2-3 vendor PoC or pilot first. Then with the chosen vendor: phased approach based on location + type of log source (e.g. firewalls, then routers, then OS, then proxies, etc) + network topology (e.g. DMZ, then internal) + log source criticality (e.g. critical servers first; the rest next). This might be handy to look at.

Q3: What kind of storage requirements have been experienced by those organizations who have successfully implemented enterprise-wide logging?

A3: Massive? :-)

Here is a simple example: PCI DSS is a bit more aggressive than NERC since it mandates 1 year of log retention vs NERC 90 days, so: 1 year worth of logs is = 365 days x 24 hours x 3600 seconds x 1 (one!!!) busy firewall with 100 log messages each second x 200 bytes per message average (e.g. valid for PIX and ASA devices) = 588 gigabytes / year of raw log data uncompressed (assuming 10x compression you'd get about 60GB of compressed log data per year)

Store it in RDBMS? Multiple it by 2-3. Have an index? Add about 30%.

The bottom line is: terabyte is the unit to measure logs.

Q4: At the organizations that have successfully implemented enterprise-wide logging, how logging impacted network and system performance?

A4: Too broad a question, so here are a few pointers:

  • logging affects performance much more on some types of systems compared to other types: most painful examples are databases where some people (can't find a link...sorry) report performance loss of up to 40% if logging all SELECT statements and other data retrieval commands (you need to log selectively on these); in other cases (e.g. web servers) there is no performance loss and logging is "always on"
  • log collection: agents impact system performance (long post on this subjects): a little when they run (everybody knows this) and A LOT when they crash (few people think about it - agent software memory leaks are not uncommon); unlike agents, remote agentless log collection barely affects system performance (unless you have one of the few esoteric cases)
  • log transfer and network performance: look for compressed (logs compress really well), TCP-based transfers; syslogging over UDP uncompressed has a chance of doing a pipe saturation DoS on your network. Yes, people say "use a dedicated LAN," but this is definitely wishful thinking for many. Also, raw UDP syslog in large quantities over WAN = insanity :-)

Q5: What were some successful strategies for obtaining buy-in from system owners and operators in regards to turning logging on?

A5: OK, also too broad a question, but here are some pointers:

  • provide them a useful service based on their logs (e.g. performance measurement, availability monitoring, compromise detection :-), or other security metrics, etc)
  • help them with their compliance mandates (e.g. create reports that they can show to the auditors that "bug" them)
  • give them tools to better solve their problems (e.g. allow access to a log management tool so that can investigate issues better, search the logs, check on their users, etc)

Q6: How the organizations that have successfully implemented enterprise-wide logging dealt with unusual devices (=log sources) that have no log management vendor support?

A6: They were in massive pain - if they choose a log management vendor wrong. You need to look for vendors that have "universal log source support" with NO requirement for a custom rules or custom collector/connector/agent development. Some vendors have generic text log collectors that can grab and analyze unknown logs. Typically this is done via some form of text indexing that works across all logs, including those from unknown, vertical, esoteric or custom-developed log sources

Hope it was useful!

About me: http://www.chuvakin.org
]]> Wed, 23 Apr 2008 12:20:00 +0000 data raw log data logs compress logs analyze unknown logs unknown data retrieval commands measure logs log data Some Burning Logging Questions - Answered! <![CDATA[XSS on Whois]]> http://securityratty.com/article/a81e3923220ae8c69dd1dc5c2d3643f6 http://securityratty.com/article/a81e3923220ae8c69dd1dc5c2d3643f6 Klaus over on Blackhatdomainer described on his blog the use of XSS in whois information to take over domains when people are researching your domain. Very cool stuff. I have a feeling there are also servers that may be vulnerable to SQL injection as well, but that’s probably much more difficult and dangerous to test. Dotster was apparently vulnerable to this, but we didn’t have a working PoC.

However, Thrill then posted an screenshot of this on one of the several domain registrars that we found to be vulnerable to this. So now we proof that this can be done. Of course the usefulness of this is probably limited to only a few sites, but sites which often take credit card information for payment processing of domains. Which, obviously, has some usefulness for phishing. Anyway, pretty interesting stuff!

]]> Sun, 30 Dec 2007 17:55:53 +0000 apparently vulnerable vulnerable credit card information domain cool stuff domain registrars stuff usefulness sql injection XSS on Whois <![CDATA[Poll: How Important is a POC When Getting Someone to Fix a Security Issue]]> http://securityratty.com/article/0815fdfe5f027fa19daefa249d4112a2 http://securityratty.com/article/0815fdfe5f027fa19daefa249d4112a2
I've noticed that lots of people that work as consultants and/or inside companies have to jump through lots of hoops to get a security vulnerability taken seriously.

In many cases I see people spending hours and hours crafting a working proof-of-concept exploit for a vulnerability and needing to actually demonstrate that exploit to get the issue taken seriously.

To understand this better, I set up a small poll to get some data about why people are needing to craft a working POC when demonstrating a vulnerability exists.

I've only ever had to do this once, and yet it seems that every time I read about a penetration test I see people spending lots of time crafting sample exploits rather than spending more time on finding more vulnerabilities, or fixing classes of vulnerabilities that are similar and offering solutions to those.

In my experience the only time a POC has been really useful is when I need to make sure that the person fixing the issue has the necessary information/tests to make sure they've closed the issue.

For those who do penetration tests (network or application) - how often do you feel that you need to create working POCs for exploits in order for the company's management to take it seriously?]]> Tue, 27 Nov 2007 05:37:00 +0000 issue people vulnerability vulnerability exists time poc lots exploits security vulnerability Poll: How Important is a POC When Getting Someone to Fix a Security Issue