Eric Monti | February 22nd, 2008 | Filed Under: Bitching About Protocols, Industry Punditry
If you do any kind of info security work or FOSS integration with windows and other Microsoft products, go and bookmark this link now!
By this time, I imagine everybody has heard about Microsoft’s new “Interoperability Initiative” announcement yesterday and all the buzz surrounding it. Lots of nay-saying about the actual level of openness coming out of Redmond, which is to be expected as par for the course. But… have you actually READ any of the references they published???
Whether this is as complete as it could be is probably still debatable to an extent. As somebody who’s got some experience reversing Microsoft protocols, I have to say from skimming the site, it looks like the lions share of transparency the FOSS and security communities have been calling for for a long time now. Given some more time, even I will inevitably nitpick about the things that aren’t included or are “under-included” in this reference material. Off the bat, for example, there seems to be little if any information on SQL Server and similar tertiary MS technologies.
But this is definitely a huge step by Microsoft. I really hope they will keep all of this material up to date and keep it coming where there are gaps. Something tells me they probably will.
So… credit where credit’s due. Microsoft definitely gets kudos for this. The nay-sayers claiming “we’ve heard that one before” appear to be dead wrong this time. My natural instincts would normally be to join them, but the evidence is to the contrary. In the spirit of my fairly blatant and deep-seeded prejudices, I will still at least proclaim “It’s about freaking time, Redmond!”. Oh and while I’m being snide… that stuff about not suing some of us is real sweet to hear from Ballmer too…
Still, my gold kudo ultimately goes to the EU. The whole episode definitely affirms that our government representatives in the US never put any real teeth on our MS anti-trust struggle over the past decade and that they really should have a long time ago. As we’ve seen in the last number of years with MS’s increased security transparency initiatives, I think it will become even more apparent that increased transparency has never been contrary to corporate interests either.
Anyway politics aside… Deep down, while skimming the site, I’m feeling a little like Wiley Coyote in the ACME factory after closing time.
As soon as I got wind of the release, I made a bee-line right for this document — NTLMSSP/NTLMv2 token exchanges being a subject near and dear to me during several projects a few years back. I think this is an example of where the new references, accessibility, and toning down of the “suing” rhetoric may bear fruit.
Now that MS seems to have admitted that it is “legal” to do so (more sarcasm) we may for example see Firefox and other open browsers fully implement NTLMv2 authentication blobs to get along with IIS webserver authentication. On the flip side, people might start using NTLM under Apache to integreate with their Windows domains and/or directories (I seem to recall a 3rd party module or two out there that even does this already). NTLMSSP is goofy, sure. Don’t get me wrong. I still dislike NTLM, it’s just that I got pretty “close to it” for a while there. For all the troubled past and arguable nastiness, NTLMv2 challenge/response handshakes over HTTP are at least a better alternative to Basic Auth (at least somewhat comparable to Digest). Sure, there are some really gross flaws in the crypto, arguably some information leakage… but on the plus-side there are tons of IE browsers out there all ready to actually start using it if it actually becomes relevant by working elsewhere other than just IIS.
A little background: Even though for some time, this has been considered “conquered territory”— lots of FOSS implements it to varying degrees (as evidenced by the Wikipedia entry) — NTLMv2 and NTLMSSP are still and have long been Microsoft inventions that are not terribly well understood by “the rest of us”. This is mostly due to the lack of documentation out of Redmond. Before it was “deprecated” by Active Directory/Kerberos, Microsoft cobbled NTLM/NTLMv2 into all sorts of protocol implementations. Examples include CIFS (where it’s rooted), MS-SQL, POP3, IMAP, HTTP, SMTP, even Telnet for jebus’ sake! The list goes on. To many, it would be an understatement to say that Microsoft has historically leveraged NTLM to attain a degree of ill-gotten market dominance through incompatibility.
NTLMSSP is still relevant in the AD/Kerberos world for that matter. Probably in order to save themselves the hassle (irony), MS decided to leverage much of the basic NTLMSSP token structure and protocol semantics for when AD/Kerberos message exchanges came around. You’re still pretty likely to see NTLMSSP blobs in and out of Base64 packaging in many MS protocol implementations — regardless of whether you’re using Kerberos or still downwardly compatible.
In the past, incorporating or implmenting NTLMv2 (let alone “correctly” whatever that was) was a pretty big hassle. Just deciphering those NTLMSSP NegotiateFlags was cause of considerable grief. The worst part was wondering whether and which of the “unused” bits were “really unused”. Now, seeing all those bits laid out and documented in their entirety outside of a Samba or MS-SDK C header this way gets me a little dizzy. There was, I admit, a masochistic kind of pleasure in cobbling together and in some cases reversing the information from various sources back then — like discovering new frontiers or something. But yeesh… I think my rational side ultimately wins out on that kind of nostalgic waxing. Yea, enough of that crap! It’s time to move on.
So… in conclusion:
Keep it up MS and… <cough>… thank you!
I’m pretty sure MS wont regret this, either. I hope the old-guard holdouts out there (yes that includes YOU, Apple… Cisco…) pay very close attention over the weeks and months to come.
6 Comments
Wes Brown | February 15th, 2008 | Filed Under: Matasano, Navel Gazing
I’m Wes Brown, and I’ve just joined the Matasano team and will be working on various clients’ projects as well as internal ones.
Ever since I was hired to rewrite a Fortune 10 corporation’s host security scanner from Bourne Shell into something more usable almost eight years ago, I’ve been involved in security more or less full time. I’ve worn many hats, including researcher, security consultant, and malware analyst.
I’ve presented in the past at security conferences under the banner of Ephemeral Security on the idea of injectable virtual machines. We had a reference implementation of Mosquito using Lua in 2006, and a more sophisticated one using our own Lisp-based virtual machine. While Ephemeral Security is on hiatus, the source code of Mosquito remains available at SourceForge. It’s a lightweight Lisp-based portable virtual machine written in ANSI C that has network and cryptography built in. One of my better presentations is up at Google Video.
I remain keenly interested in lightweight virtual machines as pertaining to security, and will be continuing to work on them with the team at Matasano. I am looking forward to writing about my investigations into malware, virtual machines, small and elegant programming languages, and security in general.
9 Comments
Thomas Ptacek | February 11th, 2008 | Filed Under: Industry Punditry
We’re more than a month delayed on this post, and it’s mostly my
fault, but to compensate:
You’re not reading this post alongside every other lame
predictions post, and
Our predictions are good until February of ‘09.
I note with satisfaction that the TSA has made my ‘07 prediction of
laptop searches come true, albeit belatedly.
And so, on to Nate and my 2008 (or, “trailing twelve months from
February 2009”) predictions!
Nate: Predicted! Hardware hacks go mainstream
Exciting developments are bringing hardware hacking to the security
community. Cheap FPGAs, free JTAG libraries, tutorials,
Xbox timing attacks, and open information about silicon all mean the era of
software-only protection is over. The Trusted Computing TPM spec says
“… to spoof the modifier to the TPM requires more than just a simple
hardware attack but would require expertise and possibly special
hardware.” That expertise and hardware will see widespread use in
2008.
Thomas: All that reversing work has to go somewhere
A dirty secret: most embedded systems are much less complicated than a
PC running Windows. No embedded system gets the attention the Windows
X86 runtime does. And when your code runs directly alongside the
system scheduler and memory manager, there are entire new classes of
vulnerabilities that need to be tested for; for instance, preemption
and reentrancy. This is a long-winded way of saying, of course I
agree. We’re long past “peak oil” for Windows vulnerabilities; hell,
Aitel predicted that two years ago. It’s long past time for the
research community to start extracting from the tar sands of
peripherals and hardware. I’ll even extend your prediction: the iPhone
doesn’t count.
Thomas: Predicted! A hardware hack my mom will understand
Let’s be specific: within the next 12 months of this post, there is
going to be a public, trivially-reproduceable break in a
security-critical piece of infrastructure. Even more specifically,
it’s going to be one of three things:
a published break in one of the RF door lock or time card systems
that get employees in the doors at multiple Fortune-100
companies,
a published break in a toll or billing system, like a mass transit
card, mass-market affiliation card, or open lane tolling
system (denial of service counts!), or
a published break in a deployed advanced metering infrastructure
system for a common home utility.
The qualifying vulnerability will be based on fielded hardware (or the
protocols they speak, such as RF modulation schemes). It will not be
based on some Internet-exposed controls software hosted on an HP box
in a data center rack.
Nate: Real-world destruction by hacking still only happens in the movies
Despite all the scare about SCADA, we’ll still avoid any major
catastrophe in 2008. Like network security, actual damages end up
being kept to a manageable level as protection advances. Sometimes
hackers are ahead, sometimes defenders are. Occasional local areas of
pain will still appear as disgruntled employees push the Big Red
Button, although damage due to mistakes will still far outweigh
anything intentional.
Nate: Predicted! Public vulnerability disclosure disappears
In the wake of payola (semi-legit and black market) and hassle,
litigation, and lawmaking by companies, system vulnerabilities will
cease to be publicly and freely disclosed. Sure, there will still be
XSS galore, but systems-level vulnerabilities will only appear in
0days or Microsoft patches. In its place, expect PR-disclosures being
used to sell IPS/IDS updates, which are the only place legitimate
money is to be made in finding security holes. Flaws in popular
devices like the iPhone and minor applications like Facebook Bingo
will continue to be publicly disclosed due to notoriety and no one
caring, respectively.
Thomas: Not a chance. Vulnerabilities aren’t worth enough.
For this to come true, payola schemes would have to offer enough to
counterbalance the reputation benefit that accrues to published
researchers. You’re not even following the money: no competent
researcher makes more at auction than they can from their base
comp. If you’re good enough to rack up enough frequent flier miles
with TippingPoint to make car payments, you’re good enough to land an
excellent job at any of the major security companies. And that’s just
the money; the reality is, if we just wanted to make bank, there’s 10
other technology jobs that pay better that vulnerability research —-
like designing social network pet calendars. Too much of this field is
about ego and gamesmanship for it to be taken underground by
payola. And I don’t think that’s a bad thing.
Thomas: Predicted! No new major web vulnerability class
A vulnerability class is something you have to audit all deployed
software to track down and kill. Overflows are a bug class. Integer
mishandling is a bug class. In web apps, XSRF is a bug class, as is
SQL injection and cross-site scripting. And speaking of those three:
12 months from the time this is posted, these three problems (and
Internationalization, which amplifies them) will still be the mainstay
of every web app penetration test. Here’s what doesn’t count: exploit
techniques like Prototype Hijacking. 12 months is a long time, and
Tavis Ormandy and Stefano Di Paola are going to come up with plenty of
cool web tricks. But none of them are going to fundamentally change
the landscape of web security.
Nate: The old ones are still everywhere
I’m not a big Web guy so I honestly don’t track the prevalence of
known bugs. But, a quick browse of recent Bugtraq archives shows that
they’re still appearing at the historic rate. Since I think most new
software development is in web-based applications, that’s likely the
place the most bugs are being introduced by emergency hires that
happen to have Rails on Resume.
Nate: Predicted! Watermarks first used successfully
Everyone thinks watermarks are a failed technology, and they are in
their current form. However, people have recently been talking about
forensic marks, where the method of embedding data is
content-dependent and the detector is kept private. This is different
from the previous approach, where the detector is present in every
piece of equipment and the default is “play if watermark not
detected”. Such systems are obviously permanently broken since you
can take a piece of content and make small random modifications until
it finally plays.
I predict that forensic marks will be successful in 2008 where
watermarks failed. By succeed, I mean have some slight limiting
effect on piracy from a given source due to a perceived threat to
anonymity. If you knew that Apple embedded an encrypted version of
your user ID in each song you downloaded (but not where), it would
definitely make you think twice before posting that song online.
Thomas: You’d know better than I would
Every time I try to play the “analog gap” card in arguments with you,
you bust out with forensic watermarking.
You have an interesting point: the major breaks in watermarking
schemes (at least, the schemes that we know about) have all happened
on the attackers’ turf: the system told you when you beat the
mark. And, like the SPDC VM in BD+, you’d think that watermarking
schemes are painlessly renewable; as long as the system isn’t using
them to allow playback, but only to help the lawyers track you down on
BitTorrent, it feels like this one gets fought on the defenders’ turf.
Thomas: Predicted! The year of the uninitialized variable vulnerability
You clearly can’t call this a new vulnerability class, because it’s
many years old. But as an attack vector, it’s undervalued. Here’s a
trick for reading specifications, standards, and documentation like a
security researcher: when something has an “undefined” value, that
means “a value defined by your attacker”. Here’s a perfect storm of
software insecurity: a shortcut taken by virtually every developer in
every C/C++ project ever fielded, an obvious-in-retrospect means of
exploiting it, and just enough mitigation (compiler warnings) to throw
casual researchers off the scent. Here’s what I think: the people who
excel at inventing bug classes aren’t the same people who excel at
using those inventions to find flaws, and the best hunters aren’t the
same people who excel at writing exploits. Those stars will align this
year, and the same people who comb Freshmeat looking for KDE video
player software to bust shells with will have enough sample code to
start exploiting this problem everywhere.
Nate: Not until fuzzers for it become more common
I don’t think you’ll see widespread exploitation until there’s a
recipe. Just like with buffer overflows, then integer overflows,
uninitialized variable attacks still need more tools for automated
discovery, say with a modified Valgrind. You not only need to find
uninitialized use of a variable but also a trace of memory
fingerprints to find how you can fill that area with your own data.
Then, you have to figure out what you can do with that variable. I’m
not saying it’s too hard, just that the tools haven’t caught up yet to
make this a fruitful area. Maybe in 2009.
Nate: Predicted! Ed Felten wrong about DRM
Every year, Ed Felten predicts that DRM will fail to prevent
widespread infringement. He’s been right up to this point, but 2008
will change that in one area. So far, the Blu-ray content protection
(BD+) has prevented high-def rips of Fox discs from hitting
BitTorrent. The ones that have appeared have been sourced from
HD-DVD, which only has a traditional encryption/revocation protection
scheme. In 2008, we’ll see the first released BD+ titles cracked
(probably by SlySoft, who has already invested four months in
analyzing those titles) but new discs will continue to be protected
for the key release window. Rips of just the main feature via direct
video capture will be the main source of piracy for protected titles
(see watermarking prediction above.)
Thomas: I know you have a dog in this hunt, but DRM is going to fail elsewhere
The best “breaks” of iTunes Fairplay barely qualify today (audio
capture? Come on). Within 12 months of this post, there will be a
freely downloadable tool that converts protected M4P audio files to
unprotected AAC files, without decoding and playing sped-up audio.
Thomas: Predicted! A game-over bug class in a scripting language kernel
It has to happen. People have been claiming that high-level languages
like Perl are immune to runtime security vulnerabilities —- most
notably memory corruption —- for the past 14 years. People like us
have been saying they’re wrong, but we’ve had precious little
ammunition to back up that argument. Here’s what a game-over scripting
kernel bug class is:
something that occurs commonly, that a “competent developer skilled
in the art” is likely to accidentally introduce
something you have to audit bulk Python, Ruby, or Perl code to eradicate
something that isn’t easily fixed by patching the language kernel
something that isn’t domain-specific (for instance, SQL Injection doesn’t qualify)
Within the next 12 months, someone is going to disclose a bug that
totally screws over Python, Ruby, or Perl devs. If I was looking (and
I’m not), the first two places I’d pay attention to are regular
expression engines and threading.
Nate: Bug of the Year… if it happens
Sounds impressive and feasible, but not likely to happen this year.
Nate: Predicted! first Facebook app 0day
I consider Facebook the proverbial canary in the coal mine when it
comes to Web 2.0 valuations. As soon as startup companies figure out
they’ll never make money porting 1980’s text games to Facebook, we’re
at the start of the next dotcom crash. Anyway, just like the
Myspace worm, a popular Facebook app will have a 0day bug that tries to steal
passwords or other important private information. Making private
profiles public does not count as we’ve already seen that numerous
times.
Thomas: This is a lay-up
We’re already feeling the tremors on this one; look what happened to
Google’s Orkut social network. A simple web vulnerability in an Orkut
feature, the ability to use Orkut to send email teasers to your
friends list, and boom. Mass casualty. What’s better is, your Facebook
password is probably the same as your Yahoo Mail password. This is too
tempting a target. Sometime within the next 12 months, one single
social network vulnerability is going to compromise between 500,000
and 1,000,000 web email accounts, and because they’re all searchable,
multiple percentage points of those accounts are going to be converted
into bank account compromises.
Thomas: Predicted! The death of the Network Access Control “market”
Do you know anybody who is rolling these products out network-wide?
Here’s the pitch: you deploy, oh, I don’t know, 100 crappy new 1U
security boxes across your network, and in return, your VP/Sales can’t
get to the CRM server anymore. Also, you get fired. Even if this
technology worked well, it wouldn’t solve much: the host-level
vulnerabilities enterprises care about now are clientsides, and we
find too many of them every month for anyone to believe that some
4-person “research team” at a 10MM/yr NAC startup is really going to
keep on top of them. The drumbeat of IT security is now how many times
a year you have to medevac the last version of Adobe Reader, and while
pure-play NAC vendors promise the moon here, none of them lessen that
customer pain. Meanwhile, the big problems in security are moving
towards the web; no NAC vendor has any answer to the Big Problem,
which is that any XSS vulnerability in any internal web app probably
hands an attacker every other web app, including payroll.
I do have a point: within 12 months, two (2) NAC startups —- I’m not
naming names, but I’m definitely thinking them —- are going to turn
the lights out: no major product announcements or customer wins for 4
months. NAC will underperform Data Loss Prevention this year, and next
year, and every year after that, leaving aside whatever Cisco and
Juniper bake into their gear.
Nate: Agreed, but NAC will be reduced to an integrated feature, not disappear
There’s no reason to deploy some small company’s NAC boxes,
absolutely. But IT people have a thing for control and policy. You
don’t see the death of AV file scanning even though floppies are no
longer how you get viruses, email is. This kind of vantage point
tends to survive longer than its importance. So I agree that a lot of
the startups will disappear, a few will be acquired, and NAC becomes
merely a feature of edge switches with the heavyweight clientside
logic left to the AV companies.
32 Comments
Mike Tracy | February 1st, 2008 | Filed Under: Uncategorized
A lot has been made of the SocGen trading scandal as a case of someone
cracking a computer system to defraud the bank. I traded on the Chicago
Board Options Exchange before getting into software testing and security
full-time and anywhere the two intersect is interesting.
Reading the first outbreak of stories, you’d think the guy was slicing
through the bank’s access controls causing all sorts of unauthorized
mayhem (note the use of the word “unauthorized” for later on). Sifting
through the follow-ups I came across
Reuters
which put a whole different spin on it. Rich Bejtlich at
TaoSecurity
has a good write-up, sums it up pretty well in his first graph and
highlights some salient points. Paul
Waldie
has the most interesting article I have read on the subject.
So why bother writing about it? Because, assuming the bank’s story is
true, this is a teachable moment in authorization versus authentication.
So what happened Mike?
According to news accounts, a junior derivatives trader (Jerome Kerviel)
who was recruited from the back office (what position he held isn’t
clear) concocted an incredibly clever scheme to lose the bank $7.2
billion. The motive wasn’t money as he wouldn’t have been able to
profit if things had gone well. Apparently he just wanted recognition
as a star trader and a bonus.
Is getting into a trading position from the back office really so
“unusual”?
In my experience with exchanges, no. Getting onto a bank’s trading
floor is a different matter. The spin by the bank, however, provides
fuel for their premise that Kerviel had inside knowledge that allowed
him to bypass authorization in their system.
So what exactly is a “derivative instrument?”
The simplest definition of a derivative is a financial instrument that
derives its value from another underlying financial instrument. For
example, a futures contract is a derivative that bases its value on the
market price of the underlying commodity. Specifically, a futures
contract guarantees the buyer to the right to purchase a set amount of a
commodity at a given price on a given date. In this case we are
examining “regulated stock market index futures” which base their value
on an underlying index of stocks (DAX, EuroStoxx and FTSE to be exact).
A “regulated” derivative is normally referred to as an “exchange traded”
or “listed” derivative. Listed futures contracts differ from other
types of forward contracts in that they can be bought and sold at any
time before their expiration date in a regulated marketplace, have terms
that are standardized by an oversight agency, are guaranteed by neutral
clearing entities and have a standardized settlement procedure. In the
case of stock index futures, the settlement is normally in cash as
opposed to taking delivery of bushels of oranges or ounces of gold.
So an “over the counter” derivative is just like an “Over the Counter”
stock?
Not at all. Over the counter derivatives are custom contracts priced
and negotiated to suit the particular purpose of the entity initiating
the contract. They have no set parameters, are not subject to the same
regulatory oversight and have no guaranteed clearing or settlement
mechanism. Think of it as re-insurance or a bookie laying off one way
action with another book to reduce his exposure. They are normally (if
not always) traded between banks and used to hedge portfolio (forward
contracts or options) or interest rate (swaps) risk. A premium is
normally written into the contract for providing the service.
If Kerviel’s job was to write over the counter forward contracts for the
bank and hedge them with listed futures, then he was clearly authorized
to enter the types of trades he allegedly entered into the bank’s
system.
OK, but what if that wasn’t his job?
Then it’s unlikely that Kerviel was authorized to negotiate (and have in
his position) over the counter trades. It would also mean the over the
counter contracts were the “hedge” against his long futures positions.
Given the complexity of negotiating and premiums paid for over the
counter forward contracts, the probability of this being a winning
trading strategy asymptotically approaches zero. In any case, it’s
certainly not an “arbitrage”.
But obviously Kerviel was putting fake trades in the system. He must
have been hacking right?
Even lacking authorization by the bank to trade over the counter
securities, Kerviel may still have been able to enter these types of
trades into the bank’s order entry system without any other access to
the system than what he walks into work with every day. That some of
his entered trades were fictitious and designed to hide the risk he was
carrying is no more elegant than kiting a check. It certainly doesn’t
require any hacking skills.
So what’s the real issue here?
Simple. The bank should have asked and answered one simple question,
“Is this trader’s position authentic?”
There are only two possible theories for the fraud. One, as pointed out
in the Reuters article, is that Kerviel was removing the bogus over the
counter trades from his position before being checked and then
re-entering them. This would have to take place on (at least) a daily
basis and with very precise timing. The other is that no such
manipulation of the position took place.
If he were removing the “hedge” part of his position from the system,
the incredibly large amount of market risk in his position would have
been exposed. If the position ended up losing $7.2 billion, how many
contracts was he actually long? If the position was never changed in
the system, the bank apparently never got around to checking if the over
the counter trades were valid. All someone in the clearing or risk
department had to do was pick up a phone and call the bank(s) on the
other side of the trade(s).
I’m still not quite clear how this teaches us anything about
authorization versus authentication…
Kerviel was obviously authorized to enter trades into the system. He
was allegedly entering (and perhaps removing and re-entering) bogus
trades to cover the incredible amount of risk to which he was exposing
the bank. Whether the fraudulent trades were entered through
unauthorized means is irrelevant. The trades still appeared in (or
disappeared from) his position. Despite (ostensibly) having controls in
place to either find the risk or expose the bogus trades, the bank
utterly failed to make sure Kerviel’s position was what he said it was.
“Trust but verify” takes on a whole new meaning.
6 Comments
