Archive for September, 2009

FFIEC Best Practice Audit

Tuesday, September 22nd, 2009

I saw this article today:

US court rules that bank failed to protect customer against fraud

Dan Raywood | Sep 22, 2009 9:55 AM

Could set precedent for banking sector.

The banking sector could face a major shake-up after a court in the US ruled that a bank failed to protect a user’s account against fraudulent access.

In a recent case, a US judge allowed Marsha and Michael Shames-Yeakel to bring a case against Citizens Financial Bank, who alleged that the bank failed to implement state-of-the-art security technology, as they were the victims of fraud perpetrated through their online bank account to the tune of $US26,500.

The US District Judge refused to grant summary judgement in favour of the financial institution, clearing the way for the court case to take place. In her judgement, Rebecca Pallmeyer stated: “In light of citizens’ apparent delay in complying with FFIEC security standards, a reasonable finder of fact could conclude that the bank breached its duty to protect Plaintiffs’ account against fraudulent access.”

Rik Ferguson, senior security advisor at Trend Micro, claimed that the case could have important ramifications across the US. He highlighted a 2005 FFIEC report entitled ‘Authentication in an internet banking environment’, that stated: “The agencies consider single-factor authentication, as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties.”

Ferguson said: “The sheer volume of personal banking data and the ease with which it can be accessed is staggering. Don’t for a moment think that cost or lack of skill is a barrier to entry into the shady world of ‘carding’ and online financial fraud.

“Logon details for online banking are usually sold priced as a percentage of the available balance on the account. Today, bank accounts are available online for as little as three per cent including personal, business and offshore accounts.”

He claimed that online banking in the US still tends to rely on simple username and password combinations, and in the rare cases where a confirmation number is required, this is often sent to the customer’s email account, which is also easy for a criminal to compromise.

US banks have traditionally used single factor authentication, while in Europe, two-factor authentication has been common for years.

Ferguson said: “The deployment of these kinds of technologies in Europe, along with the language issues, means that the US is considered ‘low-hanging fruit’ for online banking fraud, and until financial institutions invest in the necessary deterrent technology, it will remain so.

“That being said, though, two-factor authentication technology may not be familiar to even some European banking customers, because (as was the case with chip and PIN cards) certain European countries have also been guilty of tardiness in deploying security technologies for online banking. So, if your bank doesn’t require this additional security, you can bet that cybercriminals know this and that your bank and your account will be targets.”

He further claimed that it is worth remembering that you should not always rely on the goodwill of your financial institution to reimburse you for losses to cybercrime.

“An argument I have heard time and again from friends and acquaintances is ‘Why should I worry when the bank always reimburse any losses?’ If the losses to cybercrime ever become too much for UK banks for example, they can fall back on the provisions of their Banking Code which states ‘If you act without reasonable care, and this causes losses, you may be responsible for them’,” said Ferguson.

As a result I’m sure the big four auditor and all the various consultancies will begin offering FFIEC Best Practice Audits. They might come up with a better name, but that’s basically what they’re selling. I guess it’s a good day to be a pen tester.

Woe unto Microsoft

Wednesday, September 16th, 2009

From DailyDave:

http://www.immunityinc.com/ceu-index.shtml has a nice reliable remote
Vista SP2 SMBv2 exploit now. I guess one thing that always strikes me
about this sort of thing is that while most people associate exploits to
a single person, the reality of the situation is that you want a pretty
large team working on it.

In this case we had Skylar Rampersaud, Nicolas Pouvesle, Gustavo Scotti,
and last but not least, Kostya Kortchinsky.

Or as I used to say at the Fort, “One team, one parking lot.” :>

Thanks,
Dave Aitel
Immunity, Inc.

More info at:

  1. http://expertmiami.blogspot.com/2009/09/smbv2-exploit-video.html
  2. http://vrt-sourcefire.blogspot.com/2009/09/smbv2-quotes-dos-quotes.html

Dealing with Cyber Crime

Friday, September 11th, 2009

Recently a family member discovered an unknown charge of approximately $2000 on her debit card. The charge was from Amazon business services and was otherwise myterious. Amazon wasn’t overly communicative but after several days they finally got back with an informative email. They wrote:

Thank you for contacting us at Amazon.com.

I have investigated the charge made to your credit card and confirmed that it was the result of the unauthorized use of your credit card number.  Please note that we have closed the Amazon.com account through which the unauthorized purchase was made.

To receive a refund, please contact the bank that issued your credit card and report the charge as unauthorized.  The bank will send paperwork for you to sign to verify any unauthorized charge.  Your bank will then pass the appropriate paperwork on to us.

It may be helpful for you to know that under U.S. banking regulations (Regulation Z – the Truth in Lending Act), in most cases, you have the right to withhold the unauthorized charge from payments to your bank until the matter is resolved.  In addition, your bank must resolve the matter within 90 days of its receipt of notice from you.

We recommend that you have this card cancelled and reissued to prevent any future unauthorized use.  We also encourage you to report the crime to your local law enforcement officials.  Although we are not permitted to provide you with any further details about the unauthorized charge to your card, we will gladly cooperate with your bank or local law enforcement, should they contact us.

Again, thank you for contacting us at Amazon.com.

Best regards,

Ultimately, I find this email infuriating. Without evidence to the contrary, Amazon inappropriately charged the money. Their solution, is basically to complain to the bank. Now, the bank readily resolved the issue, but my concern is that this is Amazon’s mistake and they seem to take little responsibility. Further, they write: “Although we are not permitted to provide you with any further details about the unauthorized charge to your card, we will gladly cooperate with your bank or local law enforcement, should they contact us.”

They’re not permitted to provide you with further details? Seriously? Their company makes an illegal $2000 charge and they think they don’t have to own up to what happened?

Righteous indignation doesn’t go very far, so I thought I’d research what actual recourse I might have. Several options came to mind:

  1. Talk to local police and pursue charges against Amazon. This is viable, as a crime has been committed and the only available evidence points toward Amazon. I don’t think Amazon intentionally commited a crime, but since they’re not owning up otherwise it’s an option. The problem is that local police are often barely computer literate.
  2. Option 2, file a civil suit for financial losses associated with the incident. They money itself is returned, but there could be over draft fees or costs associated with needing credit monitoring. One could always sue to recover those expenses.

I think both options are potentially viable, but they’re also distasteful and seem excessive to resolve what should be a simple problem: We want more information on what happened, what data was compromised, and why it was compromised.

I think Maryland has come to the rescue. I found the Maryland Consumer Protection – Personal Information Act of 2007. This act basically defines data destruction and compromise rules. In particular it has the following clauses:

  •  
    • TO PROTECT PERSONAL INFORMATION FROM UNAUTHORIZEDACCESS, USE, MODIFICATION, OR DISCLOSURE, A BUSINESS THAT OWNS ORLICENSES PERSONAL INFORMATION OF AN INDIVIDUAL RESIDING IN THE STATESHALL IMPLEMENT AND MAINTAIN REASONABLE SECURITY PROCEDURES ANDPRACTICES THAT ARE APPROPRIATE TO THE NATURE OF THE PERSONALINFORMATION OWNED OR LICENSED AND THE NATURE AND SIZE OF THEBUSINESS AND ITS OPERATIONS.
    •  

    • (B) (1) A BUSINESS THAT OWNS OR LICENSES COMPUTERIZED DATATHAT INCLUDES PERSONAL INFORMATION OF AN INDIVIDUAL RESIDING IN THE STATE, WHEN IT DISCOVERS OR IS NOTIFIED OF A BREACH OF THE SECURITY OF A SYSTEM, SHALL CONDUCT IN GOOD FAITH A REASONABLE AND PROMPT INVESTIGATION TO DETERMINE THE LIKELIHOOD THAT PERSONAL INFORMATION OF THE INDIVIDUAL HAS BEEN OR WILL BE MISUSED AS A RESULT OF THE BREACH.
    •  

    • (2) EXCEPT AS PROVIDED IN SUBSECTION (D) OF THIS SECTION, THE NOTIFICATION REQUIRED UNDER PARAGRAPH (1) OF THIS SUBSECTION SHALL BE GIVEN AS SOON AS REASONABLY PRACTICABLE AFTER THE BUSINESS DISCOVERS OR IS NOTIFIED OF THE BREACH OF THE SECURITY OF A SYSTEM.
    •  

    • (3) A BUSINESS THAT IS REQUIRED TO NOTIFY AN OWNER OR LICENSEE OF PERSONAL INFORMATION OF A BREACH OF THE SECURITY OF A SYSTEM UNDER PARAGRAPH (1) OF THIS SUBSECTION SHALL SHARE WITH THE OWNER OR LICENSEE INFORMATION RELATIVE TO THE BREACH.

The full text is available at: http://mlis.state.md.us/2007RS/chapters_noln/Ch_532_hb0208E.pdf

It’s important to obtain this information as there’s no reasonable way to to mitigate the problem otherwise. Yes, the Amazon account was close and the credit card has been changed, but some attack vector enabled the compromised and that needs to be fixed. Without more information, we have no idea if the fault was a bot on a home pc, a guessed password, XSS, SQL Injection of amazon, a reused password, or some other problem. The plan now is to reply to Amazon citing the above Act and requesting all relevant information.

Quicksort Beaten

Friday, September 11th, 2009

True geeks should appreciate this from:

http://permalink.gmane.org/gmane.comp.java.openjdk.core-libs.devel/2628

Hello All,

I'd like to share with you new Dual-Pivot Quicksort which is
faster than the known implementations (theoretically and
experimental). I'd like to propose to replace the JDK's
Quicksort implementation by new one.

Description
-----------
The classical Quicksort algorithm uses the following scheme:

1. Pick an element P, called a pivot, from the array.
2. Reorder the array so that all elements, which are less than
    the pivot, come before the pivot and all elements greater than
    the pivot come after it (equal values can go either way). After
    this partitioning, the pivot element is in its final position.
3. Recursively sort the sub-array of lesser elements and the
    sub-array of greater elements.

The invariant of classical Quicksort is:

[ <= p | >= p ]

There are several modifications of the schema:

[ < p | = p | > p ]  or  [ = p | < p | > p | = p ]

But all of them use *one* pivot.

The new Dual-Pivot Quicksort uses *two* pivots elements in this manner:

1. Pick an elements P1, P2, called pivots from the array.
2. Assume that P1 <= P2, otherwise swap it.
3. Reorder the array into three parts: those less than the smaller
    pivot, those larger than the larger pivot, and in between are
    those elements between (or equal to) the two pivots.
4. Recursively sort the sub-arrays.

The invariant of the Dual-Pivot Quicksort is:

[ < P1 | P1 <= & <= P2 } > P2 ]

The new Quicksort is faster than current implementation of Quicksort
in JDK (L. Bentley and M. Douglas McIlroy) and classical Quicksort.

The full description of the Dual-Pivot Quicksort you can find
on my page: http://iaroslavski.narod.ru/quicksort

Performance tests
-----------------
Here is result of running on different types of input data:

Client VM                          all    85%  organ  0..1          0..4
              random ascend descend equal  equal pipes random 010101 random
Dual-Pivot:  16.83  5.31    5.47   0.35  0.68  10.59  1.06   1.02   2.18
   Bentley's:  19.77  9.08   10.13   0.63  1.12  13.22  1.63   1.08   2.49

Server VM                          all    85%  organ  0..1          0..4
              random ascend descend equal  equal pipes random 010101 random
Dual-Pivot:  23.94  6.68    6.63   0.43  0.62  17.14  1.42   1.96   3.41
   Bentley's:  25.20 10.18   10.32   2.07  1.33  16.72  2.95   1.82   3.39

The a lot of other tests have been run under client and server mode.
The most interesting is BentleyBasher test framework. It runs battery
of tests for all cases:

{ 100, 1000, 10000, 1000000 } x
{ sawtooth, rand, stagger, plateau, shuffle } x
{ ident, reverse, reverse_front, reverse_back, sort, dither}

where

100, ... , 1000000 - array length

sawtooth: x[i] =i%m
rand: x[i] = rand() % m
stagger: x[i] = (i*m + i) % n
plateau: x[i] = min(i, m)
shuffle: x[i] = rand()%m? (j+=2): (k+=2)

ident(x) - a copy of x
reverse(x, 0, n) - reversed copy
reverse_front(x, 0, n/2) - front half reversed
reverse_back(x, n/2, n) - back half reversed
sort(x) - an ordered copy
dither(x) - add i%5 to x[i]

Here is the result of execution:
Server VM: http://spreadsheets.google.com/pub?key=t_EAWUkQ4mD3BIbOv8Fa-AQ&output=html
Client VM: http://spreadsheets.google.com/pub?key=tdiMo8xleTxd23nKUObcz0Q&single=true&gid=0&output=html

Mathematical investigations
---------------------------
It is proved that for the Dual-Pivot Quicksort the average number of
comparisons is 2*n*ln(n), the average number of swaps is 0.8*n*ln(n),
whereas classical Quicksort algorithm has 2*n*ln(n) and 1*n*ln(n)
respectively. Full mathematical proof see in attached proof.txt
and proof_add.txt files. Theoretical results are also confirmed
by experimental counting of the operations.

Diff between current and new implementation of Quicksort
--------------------------------------------------------

Here is the link to the diff for java.util.Arrays class:
http://cr.openjdk.java.net/~alanb/6880672/webrev.00

If you like to look and play with new algorithm,
please, take attached class DualPivotQuicksort.java

Feedback
--------

Also I'd like to share a feedback from Joshua Bloch and
Jon Bentley who spent a lot of time investigating this
algorithm, who gave me many advices and tips how to
make new Quicksort better.

Simply awesome!

Statistical Traffic Volume Analysis

Friday, September 11th, 2009

IDS systems are fragile. As a penetration tester, I have flown under the radar countless times. Most IDS systems depend on known bad signatures (which are often poorly written). They look for things like large NOP sleds, malicious EXEs, IRC traffic, and SYN scans. Some systems are much better, but many aren’t.

Once an attacker has access to a system, he needs to maintain access. My favorite technique for accomplishing this is to spawn a new thread by injecting it into Iexplorer. This works well, as all Windows systems have Internet Explorer and in all but the fewest cases, it has ready Internet access. From there, it’s easy enough to use Microsoft’s API to communicate via SSL to a remote C&C webserver. In 5 years of penetration testing, I’ve never seen this detected.

How do you detect C&C from the network when the traffic is inside a SSL tunnel? There’s no good solution to this problem. However several ideas come to mind:

  1. Create netflows for all traffic. Measure the sent and received data. Use statistics to find anomalous traffic. In general, botnets will often send more data than typical web traffic. Compute statistics on the traffic and identify anomalies that need further research. This has been previously discussed. The buzz term is statistical traffic volume analysis. However, I haven’t seen a tool to test this approach, so I’m currently writing a simple prototype.
  2. Create netflows for traffic. Utilize the previous statistical metrics, but combine this with network traffic relationships. To do this, implement directed graphs. For instance, you might detect a compromised machine via the former method, but know you need to determine what machines it attacked — not just communicated with. Often, the attacking machine will initiate a probe or (blindly) initiate an attack, but in either case initiate the connection. As discussed above, I generally don’t use a traditional shell or reverse shell. I want a known good service to callback. So a second connection is often initiated from the attacked machine to the attacker. From this point, the traffic volume statistics should also apply. The attacker will datamine or pivot through the attacked machine causing unusual (for http) traffic patterns. The direct graph can be used to reduce the traffic for analysis into subsets where more precise statistics can be computed.

These methods are far from perfect. In fact, I wouldn’t even say they’re good, but then again there are few good methods I’ve heard for tackling this type of problem. The only one that comes to mind is a statistical analysis on traffic times. For instance, looking for regular call-back intervals. I find this difficult, as many implants will call back every couple of days or at best every several hours. This is a difficult challenge to program as the memory requirements to log every packet time, source ip, dest ip, and size for any length of time on a fairly large network are enormous. Additionally, the mitigation is fairly trivial — add a random delay of up to several hours.

In the next week or two, I hope to release prototype code (netent) that implements the statistical traffic analysis. Currently it’s working fairly well, but I need to tune it better, determine how to display data, and clean up the code. It currently (successfully) identifies gmail and facebook as anomalous. This makes sense as both are highly chatty Web 2.0 applications that send a lot data compared to other sites — where you typically send very little and read a good deal. Therefore, the traffic is anomalous in a manner similar to compromised hosts. The challenge going forward is reducing benign anomalous traffic while still capturing possibly malicious anomalies.

Security Taken Aback

Friday, September 11th, 2009

hacking-tngI was surprised a week or two ago when Hacking: The Next Generation showed up on Amazon. I generally anxiously await most new security titles months ahead of time. But this one stayed under the radar. Hacking immediately got my attention both because of the title and because the lead author, Nitesh Dhanjani, wrote Network Security Tools. The latter book is an excellent work with practical examples and lots of code that will enable you to quickly jump into the internals of many security tools.

Hacking sets ambitious goals. The premise seems to be evolving the art of penetration testing to include recent blended attacks. If you’re familiar with HD Moore’s Tactical Exploitation or other similar talks you’ll see a lot of familiar material. Additionally, the book covers ‘blended’ or ‘chained’ attacks. Overall, the book succeeds in articulating conceptual attack vectors. Unfortunately, it falls short in execution. The book lacks details. Excluding Chapter 2, there’s very little code. So while the concepts are great, the book doesn’t enable the reader to readily execute the discussed attacks.

Several of the chapters have extremely interesting topics. Chapter 6: Abusing Mobile Devices could have been awesome. But rather than discussing mobile software security, it focuses on web sites of mobile provider websites and theoretical security weaknesses. There’s very little sustenance that the reader can use to hack or evaluate a particular mobile device.

Chapter 7: Infiltrating the PhishingUnderground is similar to the previous chapter. It looks at real-world attacks, but it doesn’t give a security professional the tools to go execute phishing attacks. The chapter belongs more in the book Crimeware.

Overall, I’m disappointed in the book. If you’re new to penetration testing or the security community this might be a good book. But if you’re looking for something that can immediately be hands on to execute the latest types of attacks, Hacking falls short. I think the cover accurately describes the book… it’s a cool looking pirate ship. However, if you look closely, you’ll see that the ship is taken-aback (meaning it’s sailing too close to the wind and the captain has lost control), and is in danger of being dismasted. Likewise, the book looks cool, and could be cool, but something went wrong.

Note: the book isn’t available in paperback yet. It is available on safari.oreilly.com and on the Kindle.

Even Security Engineers Make Mistakes

Thursday, September 10th, 2009

I’ve been writing a basic packet capture utility to implement a couple ideas I’ve had floating around on statistical IDS. Earlier today I had an odd bug. I had a pointer to a vector that after “a while” would randomly be de-referenced. I thought maybe libpcap was causing a concurrency issue and the structure was accidentally de-referenced then. After making some alterations I decided that was unlikely.

Here’s an example piece of what I did:


vector <omg *> * foo()
{
   vector <omg *> v;
   while(data)
    {
      //manipulate data
      v.push_back(data);
     }
return &v;
}

 int main()
 {
   vector * vptr;
   while(things_to_do)
   {
      vptr = foo();
      //process vptr
   }
}

Don’t nitpick pseudo code for memory management. The problem is actually fairly obvious if you think about it. v formatted in foo() is a stack variable. So it works fine inside the function. It also works fine later, for a while, but then that stack space is re-used and your pointer is dereferenced. As a result you get a bug that will eventually appear no matter how many sanity checks you perform later. The right way to do this is as follows:

vector <omg *> * foo()
{
   vector <omg *> * v = new vector <omg *>;
   if(!v)
      return NULL;

   while(data)
    {
      //manipulate data
      v-%gt;push_back(data);
    }

return v;
}

This works, because new creates a heap allocation that’s only destroyed with an explicit free/delete. So the repaired code works fine without randomly being de-allocated. The only trick from