You claim it's not a transponder, but admit it's an active system, so that implies some sort of RF transmitter -- which opens up the question of spectrum access.
You claim that it operates below the RF floor. That implies it knows the signal it should be looking for, otherwise there's some fancy DSP footwork going on that smells like the wrong end of a cow in the size and weight you're talking about, particularly if you include the power and antenna setup for a transceiver, and still have the range you're talking about.
If you are making an SSR-type system, then that saves on power / weight, but you're in the class of TCAS, IFF, ADS-B, TACAN (Air-to-Air), and back into the world of transponders.
If there's two elements to the sense component, you've recreated the sense rails from an NDB / ADF, but that doesn't provide ranging, even with a known rate of crossing, and signal strength alone is never relied upon for ranging in the airborne environment.
If it's below the RF floor as you claim, then fit it to two mountain bikes and ride them at each other for the testing, as it's unlikely to have much of a RADHAZ distance. Or, fit it to your car. Or anything. You don't go and test things like this by bolting it to aircraft straight up. You'll also get more repeatable and falsifiable results.
I'm not saying it's impossible, or whether what you've come up with is close to anything else that already exists. I suspect it's the latter but, unless you've spent a lot of time around those sort of systems, you're not going to know what does and doesn't exist.
Yeah, the article is lacking in details, which is unfortunate. Here is a nice little summary of not only the article, but also the speculation and arguments that have formed around the claims on a number of mailing lists.
Or, alternatively - $162 Million to Stop Aussies Looking at Porn.
Considered part of the campaigning for this year's Federal election in Australia, the Australian Prime Minister, John Howard, announced a $162 million USD plan to protect Australian Internet users against various Internet nasties, including porn, during a web video address to a number of Australian churches. The address was also joined by the leader of the Opposition, which suggests that the proposed plan will be left in place if they succeed in taking power later this year.
With plans to provide free internet filtering software for families, more funds for online predator detection, opportunities to lean on ISPs to stop allowing access to objectionable content, and a working group to work out ways around the privacy protection enjoyed by predators (but apparently not by the people they are supposed to protect), it is likely to become a $162 million dollar black hole, for a number of reasons.
It is important to consider who the presentation was pitched to, and who supported it. Unfortunately most of the dissenting voices from within parliament seem to be based on lines of religion (i.e. die-hard atheists complaining that Christian representatives spoke to Christian gatherings), and not on the technological shortfalls of the plan.
While some of the iPhone material that I have covered has been up on slashdot over the last couple of weeks, this is relatively new. My own article on this particular report was written a couple of days ago, reflecting material that was about 36 hours old at the time of writing.
The solution is in there, along with the report. Even when disclosing content that is extremely time sensitive, that information will always be available from our site.
Further to the above post, if we can convince the world to let us control the mineral and resources rights in our maritime area of responsibility, then us Aussies will get to pwn the world.
Because of our outlying islands and dependencies (Christmas, Cocos, Norfolk, Heard, Macquarie), our Maritime area of responsibility (where we have a commitment to provide SAR responsibilities) covers almost a third of the Earth's surface.
Have you actually looked at the territorial claims on Antarctica? Us Aussies have the biggest section by far. If we can invade the white bits that the Frogs and Kiwis have claimed, then we should control a contiguous zone of at least 1/2 of Antarctica.
Sorry to burst the bubble, but you're tilting at windmills with this approach.
The prime security weakness lies with the web service providers, who are failing to adequately secure their backend systems, not the credit card companies. It is the same problem as eating at a restaurant where they are skimming cards in the back room - you just can't be sure that your card has remained safe after every transaction. The logistics of ensuring a brand new card number for each and every transaction for each and every card holder (and ensuring card systems understand it) are immense, costly, and practically impossible (even if they are theoretically acheivable).
Because your financial providers and credit card companies have ensured that they do not shoulder liability in the event of a credit card breach, and that account holders are generally protected against all but a nominal amount, it is the merchants who lose out every time there is a breach or a fraudulent transaction. There is no financial incentive for VISA, AMEX, MasterCard, etc to do anything about fixing the underlying problem. The resources that they will need to apply to fixing the issue will not generate any appreciable ROI, so there is not much that can be done to force them to do anything. VISA will point to their PCI initiative, which is designed to ensure that VISA approved merchants have sufficient security mechanisms in place to limit the risk of fraudulent transactions / card data theft.
Search engines aren't the only way to find compromised lists of credit card numbers. Some hacking groups are also notorious for failing to ensure their systems are adequately protected against leaking information to anyone who comes looking.
Even if merchants are applying 'industry best practices', it doesn't take much to lead to a loss of data, and once it has happened nothing can unleak it. The same risks apply to your bank account numbers and online banking authentication data, which the average user is more likely to have compromised.
No, you haven't been the only one to notice that CERT has some timeliness issues when it comes to reporting on threats. Other CERTs, such as AusCERT, have the same sort of problem - particularly when you consider their public notification data (separate from their paid-for disclosure lists). Accepting that it takes time to analyse and report information, and accepting that they are disclosing to their fee-paying / sponsoring clients first, the recorded dates of information discovery are often significantly incorrect. This particular report comes as quite a surprise to us. We had always considered that variable-width encoding was relatively well understood by InfoSec companies, especially those that provide services in multiple languages. It always seemed more self-evident than HTTP-Request/Response splitting, for example.
The timeliness same problem also affects moderated sources such as BT and the various SecFocus sources, where there can be a several day delay between initial disclosure and appearance on those sources (if not longer - one particular list has recently developed a delay of > 1 week for new posts). Plus, you always get the problem of identifying what sources are accurate and relevant (hint: the CitiBank Screencap argument is about 2 years too late).
So, where do you look for additional resources? You could always look at companies like Secunia, FrSIRT, eEye, Symantec, or McAfee, but it is possible to time threat disclosure so that there is an approx 72 hour delay before they pick up on the threat, and there is always the question of coverage - McAfee will always have a focus on virus, worm and some malware threats.
We have a number of established free and fee-based services that deliver timely, relevant and accurate information about current and emerging threats. They effectively cut out the irrelevant noise that is most of the massive amount of data (across a number of different information channels) that is Information Security disclosure.
We have no vendor affiliation, do not rely on sponsorship or advertising in order to deliver our services, and strive to be platform neutral when analysing and reporting on issues. We know that our services are already being used by companies to augment their Incident Response Team information sources (as well as to validate the data coming from their more expensive, less-timely data sources), and for some clients our services form the core of their security response strategies.
Why not get in touch? We're more than happy to have someone chat to you about your InfoSec needs.
MOBB - Established and run mainly by HD Moore (who most people seem to accept does things relatively well). Moore also withholds the nastiest of exploit code (despite giving sufficient detail on how to go further), makes an effort to pre-notify the vendors, and generally does enough to be seen as one of the 'Good Guys'.
MOKB - The spate of wireless driver vulnerabilities and associated linked exploit code at first glance seems to be a follow on from the Secureworks debacle at the Black Hat Briefings (and so probably draws more of the vicious responses). There are decreasing levels of vendor notification and more cases of complete exploit code readily available. At least one of the vulnerabilities and associated exploit code is publicly torn apart by another researcher (who also suggests that the original researchers need more time learning to interpret the debugger output).
WOOB - Relatively unknown researcher tries to spend the first week of December releasing Oracle bugs and previously-unknown Oracle 0-day code. It is assumed by many that Oracle applied legal pressure to stop the process (numerology fans might want to check out the binary code behind the message cancelling the project, and compare it to the text of the message).
MOAB - LMH (capabilities now established due to participation in MOKB) and KF set out to release exploit code and vulnerability details for issues that have not been previously notified to the vendor (as the FAQ clearly states). Most observers are quite willing to wait and see something come out that targets OS X specifically (despite being called MOAB). With the first vulnerability being a problem with protocol handling in a media codec (installed by default), and the second a protocol handling problem in cross-platform software that is not even shipped with OS X, many observers are starting to question the capability of the researchers (and that is coming from people within the industry, not necessarily OS X fanatics).
When you are going to target something that is protected / supported by fanatical and vocal supporters, you really need to make sure that what you provide is bullet-proof and can stand up to criticism, else it will end up in a quagmire of flaming. Guess what hasn't happened so far?
If it is anything like the recent 'exploits' targeting the platform, then it is possible that the whole month will be taken up with vulnerable InputMangers, variations to the MachOMan PoC from ROY.G.BIV, vulnerabilities in third party code that is not enabled by default (such as against the installed PHP version), or vulnerabilities in image processing code (something that some researchers are focussing on).
All of these are known about and relatively trivial to uncover. Finisterre has received coverage in the past for claiming that he has numerous OS X vulnerabilities that Apple are refusing to acknowledge, and LMH's MoKB effort seemed to have an unhealthy focus on OS X (and there is debate over the effectiveness of some of those disclosed vulnerabilities and analysis).
Announcing this project via Brian Krebs, instead of on security mailing lists and disclosure sites, appears nothing more than self-promotion. This does nothing to help those who are opposed to this project, or these researchers, but is more than likely to lead to a major flamefest and could end up like the disclosure of the 'Remote Apple Wireless vulnerability' disclosed at the Black Hat Briefings in August - a small grain of truth, but a huge slab of self-promotion and wild-ass guessing to follow up.
It hasn't received much coverage (it was only made public a couple of weeks ago), but there is an exploitable buffer overflow vulnerability that affects Links. Technically, it affects the libpng library that Links links against, but the exploit / vulnerability development was focussing on Links as the vector to achieved the buffer overflow.
It seems that eEye are only linking to the '0-day' (for loose definitions of 0-day) vulnerabilities that their products can detect and protect against. There are many, many more 0-days that are out there, including an.asx 0-day (a true 0-day) which is more serious than this, and older as well. The only difference is that it doesn't target WMP.
The recent coverage of ASX Playlist issues in various security mailing lists and forums seems somewhat strange. For the uninitiated, here is a quick wrapup:
XMPlay ASX buffer overflow PoC code posted to milw0rm - 21 November
This PoC demonstrated an exploitable buffer overflow condition in the handling of 'ref href' URIs. A CVE entry (CVE-2006-6063 - though this only identifies the.m3u method of exploiting the vulnerability) appears around the same time, and reporting is carried by the usual third parties. With no fix present, this remains an effective 0-day (plus, with existing malware targeting.asx files it could make for interesting real-world use).
Windows Media Player DoS code posted to BugTraq - 22 November
Oddly, this code represented an almost exact duplicate of the buffer overflow demonstrated the day before, only with the exploit payload removed and replaced with a bunch of 'A's, and fails to draw much interest from third parties. It isn't until eEye publishes data on this issue (and increases the perceived threat posed) on their 0-day reporting / information site that it attracts some attention from other reporting parties (such as FrSIRT on 7 December), though uptake is slow.
Leaving Chinese Soup's critique (BugTraq) of eEye's analysis aside (why they haven't identified on the XMPlay vulnerability is another question), users need to be aware that if they replace WMP with XMPlay as the default handler of.asx content, then they are potentially creating a much riskier environment than if they accept the current DoS risk against their platform.
If this particular code release had appropriate accompanying documentation, it would be possible to work out whether it is a derivative of the earlier code, or fortuitous timing on something found independently.
Criticism has been recently levelled against third party reporting bodies for failing to adequately investigate reports (after one of the recent MoKB OS X corrupted.dmg file handling errors), and the way that information is flowing between, and being distributed by, third party reporting bodies in this case is showing similar patterns.
In summary:
- There is a known 0-day targeting a vulnerability in XMPlay's handling of malicious.asx (and other content types) data passed via 'ref href' that can lead to arbitrary code execution.
- There is a known DoS targeting WMP that is exploited via a long string passed via 'ref href' and using the.asx media type
- There has been no proven link between the two disclosures
- It has yet to be shown that the WMP vulnerability leads to arbitrary code execution
- The advice to replace WMP as the default.asx filetype handler can lead to an increased security risk if the replacement application is XMPlay (accepting arbitrary code execution in an effort to avoid a DoS).
If you look at the history of.asx file exploitation, there has been malware in the wild targeting various.asx vulnerabilities since at least Easter this year. This particular issue was publicly disclosed on November 22, and was only a DoS at the time. There are suspicions that it is a derivative of other code published publicly the day before, which targeted the XMPlay player (the exploits are very, very, very similar).
Either way, it probably won't see much of a change, though it is disappointing to see all the 'respected' InfoSec companies suckered in by eEye's dubious description (concerns have been raised on at least one security mailing list).
The recent coverage of ASX Playlist issues seems somewhat strange. For the uninitiated, here is a quick wrapup:
XMPlay ASX buffer overflow PoC code posted to milw0rm - 21 November
This PoC demonstrated an exploitable buffer overflow condition in the handling of 'ref href' URIs. A CVE entry (CVE-2006-6063 - though this only identifies the.m3u method of exploiting the vulnerability) appears around the same time, and reporting is carried by the usual third parties. With no fix present, this remains an effective 0-day (plus, with existing malware targeting.asx files it could make for interesting real-world use).
Windows Media Player DoS code posted to BugTraq - 22 November
Oddly, this code represented an almost exact duplicate of the buffer overflow demonstrated the day before, only with the exploit payload removed and replaced with a bunch of 'A's, and fails to draw much interest from third parties. It isn't until eEye publishes data on this issue (and increases the perceived threat posed) on their 0-day reporting / information site that it attracts some attention from other reporting parties (such as FrSIRT on 7 December), though uptake is slow.
Leaving Chinese Soup's critique (BugTraq) of eEye's analysis aside (why they haven't identified on the XMPlay vulnerability is another question), users need to be aware that if they replace WMP with XMPlay as the default handler of.asx content, then they are potentially creating a much riskier environment than if they accept the current DoS risk against their platform.
If this particular code release had appropriate accompanying documentation, it would be possible to work out whether it is a derivative of the earlier code, or fortuitous timing on something found independently.
Criticism has been recently levelled against third party reporting bodies for failing to adequately investigate reports (after one of the recent MoKB OS X corrupted.dmg file handling errors), and the way that information is flowing between, and being distributed by, third party reporting bodies in this case is showing similar patterns.
In summary:
- There is a known 0-day targeting a vulnerability in XMPlay's handling of malicious.asx (and other content types) data passed via 'ref href' that can lead to arbitrary code execution.
- There is a known DoS targeting WMP that is exploited via a long string passed via 'ref href' and using the.asx media type
- There has been no proven link between the two disclosures
- It has yet to be shown that the WMP vulnerability leads to arbitrary code execution
- The advice to replace WMP as the default.asx filetype handler can lead to an increased security risk if the replacement application is XMPlay (accepting arbitrary code execution in an effort to avoid a DoS).
Yes, JavaScript is an evil, evil thing in the hands of the malcontent, but having scripting support deactivated in your browser isn't really going to stop much. Some of the most recent work being carried out by Jeremiah Grossman and others who like to dabble in the area has shown that it is possible to enumerate systems on internal LANs via the browser of a visitor to an external website that the attacker controls.
Without Scripting enabled.
While the developed technique is still quite noisy and fairly obvious, there has been some work at making it more efficient. But, if you add enough shiny elsewhere on the page, then history has shown that people will be happy to put up with almost anything to get at the shiny.
Outside of the LAN, and with scripting support disabled, it is trivial to develop a network scanner that hits every port of every IP on the network segment that a site visitor is coming from, and which triggers only when the site is visited by the victim.
The bigger threat to AJAX in recent months has been the widely published (amongst security researchers) issues affecting the core AJAX components for Internet Explorer and Firefox. IE had threats affecting the XMLHTPPRequest ActiveX object (sort of core to the whole AJAX experience) as well as other threats targeting different scripting support, while Firefox had a number of issues affecting JavaScript support. Most of these issues had public exploit code and actively circulating exploits (though only in small numbers). Had something been developed which was aggressive in attacking these flaws, Web 2.0 could rapidly have become Web 0.2 for many users. Before you claim that trusted sites should be safe, the WMF vulnerabilities from last December / January showed that once an adhost gets compromised, it is game over for many many many sites that should otherwise be trusted.
I think it is more the case that Symantec and the other well-established Information Security vendors are like dinosaurs stuck in hot tar. The environment around them is rapidly changing, and the smarter of them are now starting to recognise that their existing income streams are becoming less relevant - as Microsoft makes security improvements to their OS, and the attackers continually test against the security products to improve their ability to avoid detection. Now that they are identifying it, it is still going to take some time for them to adjust to the new environment and results are going to be mixed (when was the last major discovery by Microsoft's much-acclaimed honey-monkeys?).
The third group of malware that you predict is out there and steadily gaining strength. Malware such as Haxdoor is used to extract as much juicy information as possible, before becoming a second stage malware (the money siphon). With the presence of significant botnets, easily written spiders / robots, it becomes a matter of how you define 'malware'. For example, some security vendors are classifying the distributed SETI client as malware, because clients are too lazy to block it via policy or other enforcement methods.
Of course, there are InfoSec companies out there that have been focussed on the changing environment from the very start.
When we first came across this information a few days ago, it was also linked to Mashable.com, which claims that up to 3,000 logins may have been compromised, and that they only recently became more successful in running the attack (having initially screwed up the inserted script). The other aspect is that Mashable appears to be talking about a slightly different phishing attack, which is still functional (using MySpace bulletins to spam other users).
Filtering based on blacklists (as you are suggesting MySpace admins do) doesn't always work. In this case, the URL that Netcraft discovered is only one of many being used to perpetrate the attack - as soon as one gets blacklisted, another will pop up. As to why it was left up for so long after discovery and notification? I guess people and companies just don't care as much about their security as they should.
If you want to see what we picked up on, you can always look here, or in my/. Journal.
Surely compromising the privacy for almost 10% of the nation, and that percentage being those that have served the country on the field of battle (as far back as WWII), would be more of a career limiting move than a voter influence program.
There are plenty of concerning aspects to the VA breach, and it would be really sad if that was the case.
Thanks for the response, I was concerned that you might not have realised how simple it can be to track someone down.
I know you are link #1 on Google (it is in your header on/., after all). Although your site (and subdomains) don't carry a lot of personally identifying information, and I doubt you are trying to spam mobile phone forum boards (as another networkboy does), you have left personal information out in the open in the past which can be correlated with your posts on/..
Unfortunately, a lot of the ability to track down personal information is the result of people / agencies who have been entrusted with that information not being able to secure it effectively - just ask your nearest vet if they are full of love for the VA Department at the moment.
Uh, I came to that conclusion without the help of Google's second link. Just because Google lists it, doesn't mean it's relevant. How certain are YOU that Google's second link is our original poster?
The original poster was claiming safety because of his technological boundaries that were anonymising his location, but it was worth pointing out that the same technology anonymising his location could be used to find out a huge amount of information about them.
Now, I stopped looking before I got to the personal info - publishing that wasn't going to prove my point any further. Plus, Google isn't the source to turn to for that - it was a breadcrumb buried deep in a forgotten part of the web which gave that clue. I was pointing out that the clue did exist and the dedicated researcher can find it if they have the patience.
Asshat or not, that's what it takes, and it's what people do - there's no need to descend to name calling.
Okay, so how's life working for an ILEC? And, how's the Dell 8100 holding up?
Let's just say there are enough breadcrumbs to follow to determine:
- Family status
- State, City
- Interests
- Reasonable initial estimate at real name and ethnicity
It could probably go a lot further than that, but I stopped there. The point is that if you have been online long enough, you will leave a trail that can be followed through the Internet mists, even if you only use a nom de guerre.
If you can excuse the small amount of self promotion, I think that this is essentially an ethical decision.
With my company (http://www.beskerming.com), we run no ads on our site, and our free mailing list is just that, free. There are no subscription fees, no advertising, no vendor pitches (besides our own occasional announcement), no spam, and no vendor sponsorship. It keeps our readers happy, and we have seen our influence stretch to over 400 million people via those responsible for their information and financial security, without really pimping the service to all and sundry. So long as we've keep our overheads low, it doesn't matter how many people receive our message from that service. Sure, we'd like to make more money, grow the company and all that other stuff, but it all goes back into the company - improving the services we provide our clients.
Faith in humanity keeps the list free, and it breeds some responses in kind. After the list started getting spammed with pump'n'dump scams (at least the moderator was spammed - no messages made it on the list), we sent out a simple request for recipients to review their system security and to ask anybody they had forwarded a copy of our messages to to do the same. Within 18 hours, the spam stopped. No subscriber has ever unsubscribed, and even after polling them for what they wanted to have done with the list, most responded that they enjoyed having access to a truly free list and wanted it kept that way.
We originally started the list to build credibility and reputation in the eyes of the market, and to show some of our capabilities, and even though we only recently started spreading word about it, we have attracted some quality readership who are firm supporters (at least of our free work).
Yeah, it would be easy to spam the list silly with ads, sell the subscriber list, and otherwise bleed the readership dry, but that is not ethically or morally justifiable and so long as I control the ethical path of the company, it will never happen.
One argument that is often used to support the nepotism that used to take place in large family-owned companies is that the family had a vested interest in keeping the company solvent, and knew what it took from generation to generation to support and maintain the wealth and health of the company. Never mind that by the third generation things usually went pear shaped, as that generation was far enough removed from the founders who created the wealth so as to not understand what sacrifice and effort was required for the health of the company. Basically, the ethical decisions that created and grew the company in the first place were discarded for short term enjoyment of the wealth.
Slashdot Mirror
You claim it's not a transponder, but admit it's an active system, so that implies some sort of RF transmitter -- which opens up the question of spectrum access.
You claim that it operates below the RF floor. That implies it knows the signal it should be looking for, otherwise there's some fancy DSP footwork going on that smells like the wrong end of a cow in the size and weight you're talking about, particularly if you include the power and antenna setup for a transceiver, and still have the range you're talking about.
If you are making an SSR-type system, then that saves on power / weight, but you're in the class of TCAS, IFF, ADS-B, TACAN (Air-to-Air), and back into the world of transponders.
If there's two elements to the sense component, you've recreated the sense rails from an NDB / ADF, but that doesn't provide ranging, even with a known rate of crossing, and signal strength alone is never relied upon for ranging in the airborne environment.
If it's below the RF floor as you claim, then fit it to two mountain bikes and ride them at each other for the testing, as it's unlikely to have much of a RADHAZ distance. Or, fit it to your car. Or anything. You don't go and test things like this by bolting it to aircraft straight up. You'll also get more repeatable and falsifiable results.
I'm not saying it's impossible, or whether what you've come up with is close to anything else that already exists. I suspect it's the latter but, unless you've spent a lot of time around those sort of systems, you're not going to know what does and doesn't exist.
Yeah, the article is lacking in details, which is unfortunate. Here is a nice little summary of not only the article, but also the speculation and arguments that have formed around the claims on a number of mailing lists.
Or, alternatively - $162 Million to Stop Aussies Looking at Porn.
Considered part of the campaigning for this year's Federal election in Australia, the Australian Prime Minister, John Howard, announced a $162 million USD plan to protect Australian Internet users against various Internet nasties, including porn, during a web video address to a number of Australian churches. The address was also joined by the leader of the Opposition, which suggests that the proposed plan will be left in place if they succeed in taking power later this year.
With plans to provide free internet filtering software for families, more funds for online predator detection, opportunities to lean on ISPs to stop allowing access to objectionable content, and a working group to work out ways around the privacy protection enjoyed by predators (but apparently not by the people they are supposed to protect), it is likely to become a $162 million dollar black hole, for a number of reasons.
It is important to consider who the presentation was pitched to, and who supported it. Unfortunately most of the dissenting voices from within parliament seem to be based on lines of religion (i.e. die-hard atheists complaining that Christian representatives spoke to Christian gatherings), and not on the technological shortfalls of the plan.
Perhaps this (http://www.beskerming.com/commentary/2007/07/27/2 33/iPhone_Access_Update) is a better link. No advertising, and it honours the requests of the webmasters (while still directing interested people to the right sources).
While some of the iPhone material that I have covered has been up on slashdot over the last couple of weeks, this is relatively new. My own article on this particular report was written a couple of days ago, reflecting material that was about 36 hours old at the time of writing.
Well, there is always:F irefox_-_Remote_hacker_automatic_control
http://www.beskerming.com/security/2007/07/11/35/
The solution is in there, along with the report. Even when disclosing content that is extremely time sensitive, that information will always be available from our site.
Further to the above post, if we can convince the world to let us control the mineral and resources rights in our maritime area of responsibility, then us Aussies will get to pwn the world.
Because of our outlying islands and dependencies (Christmas, Cocos, Norfolk, Heard, Macquarie), our Maritime area of responsibility (where we have a commitment to provide SAR responsibilities) covers almost a third of the Earth's surface.
Have you actually looked at the territorial claims on Antarctica? Us Aussies have the biggest section by far. If we can invade the white bits that the Frogs and Kiwis have claimed, then we should control a contiguous zone of at least 1/2 of Antarctica.
Sorry to burst the bubble, but you're tilting at windmills with this approach.
The prime security weakness lies with the web service providers, who are failing to adequately secure their backend systems, not the credit card companies. It is the same problem as eating at a restaurant where they are skimming cards in the back room - you just can't be sure that your card has remained safe after every transaction. The logistics of ensuring a brand new card number for each and every transaction for each and every card holder (and ensuring card systems understand it) are immense, costly, and practically impossible (even if they are theoretically acheivable).
Because your financial providers and credit card companies have ensured that they do not shoulder liability in the event of a credit card breach, and that account holders are generally protected against all but a nominal amount, it is the merchants who lose out every time there is a breach or a fraudulent transaction. There is no financial incentive for VISA, AMEX, MasterCard, etc to do anything about fixing the underlying problem. The resources that they will need to apply to fixing the issue will not generate any appreciable ROI, so there is not much that can be done to force them to do anything. VISA will point to their PCI initiative, which is designed to ensure that VISA approved merchants have sufficient security mechanisms in place to limit the risk of fraudulent transactions / card data theft.
Search engines aren't the only way to find compromised lists of credit card numbers. Some hacking groups are also notorious for failing to ensure their systems are adequately protected against leaking information to anyone who comes looking.
Even if merchants are applying 'industry best practices', it doesn't take much to lead to a loss of data, and once it has happened nothing can unleak it. The same risks apply to your bank account numbers and online banking authentication data, which the average user is more likely to have compromised.
No, you haven't been the only one to notice that CERT has some timeliness issues when it comes to reporting on threats. Other CERTs, such as AusCERT, have the same sort of problem - particularly when you consider their public notification data (separate from their paid-for disclosure lists). Accepting that it takes time to analyse and report information, and accepting that they are disclosing to their fee-paying / sponsoring clients first, the recorded dates of information discovery are often significantly incorrect. This particular report comes as quite a surprise to us. We had always considered that variable-width encoding was relatively well understood by InfoSec companies, especially those that provide services in multiple languages. It always seemed more self-evident than HTTP-Request/Response splitting, for example.
The timeliness same problem also affects moderated sources such as BT and the various SecFocus sources, where there can be a several day delay between initial disclosure and appearance on those sources (if not longer - one particular list has recently developed a delay of > 1 week for new posts). Plus, you always get the problem of identifying what sources are accurate and relevant (hint: the CitiBank Screencap argument is about 2 years too late).
So, where do you look for additional resources? You could always look at companies like Secunia, FrSIRT, eEye, Symantec, or McAfee, but it is possible to time threat disclosure so that there is an approx 72 hour delay before they pick up on the threat, and there is always the question of coverage - McAfee will always have a focus on virus, worm and some malware threats.
Or, you could always use our services (http://www.beskerming.com).
We have a number of established free and fee-based services that deliver timely, relevant and accurate information about current and emerging threats. They effectively cut out the irrelevant noise that is most of the massive amount of data (across a number of different information channels) that is Information Security disclosure.
We have no vendor affiliation, do not rely on sponsorship or advertising in order to deliver our services, and strive to be platform neutral when analysing and reporting on issues. We know that our services are already being used by companies to augment their Incident Response Team information sources (as well as to validate the data coming from their more expensive, less-timely data sources), and for some clients our services form the core of their security response strategies.
Why not get in touch? We're more than happy to have someone chat to you about your InfoSec needs.
What job are you after? Details can be sent to listed email address.
MOBB - Established and run mainly by HD Moore (who most people seem to accept does things relatively well). Moore also withholds the nastiest of exploit code (despite giving sufficient detail on how to go further), makes an effort to pre-notify the vendors, and generally does enough to be seen as one of the 'Good Guys'.
MOKB - The spate of wireless driver vulnerabilities and associated linked exploit code at first glance seems to be a follow on from the Secureworks debacle at the Black Hat Briefings (and so probably draws more of the vicious responses). There are decreasing levels of vendor notification and more cases of complete exploit code readily available. At least one of the vulnerabilities and associated exploit code is publicly torn apart by another researcher (who also suggests that the original researchers need more time learning to interpret the debugger output).
WOOB - Relatively unknown researcher tries to spend the first week of December releasing Oracle bugs and previously-unknown Oracle 0-day code. It is assumed by many that Oracle applied legal pressure to stop the process (numerology fans might want to check out the binary code behind the message cancelling the project, and compare it to the text of the message).
MOAB - LMH (capabilities now established due to participation in MOKB) and KF set out to release exploit code and vulnerability details for issues that have not been previously notified to the vendor (as the FAQ clearly states). Most observers are quite willing to wait and see something come out that targets OS X specifically (despite being called MOAB). With the first vulnerability being a problem with protocol handling in a media codec (installed by default), and the second a protocol handling problem in cross-platform software that is not even shipped with OS X, many observers are starting to question the capability of the researchers (and that is coming from people within the industry, not necessarily OS X fanatics).
When you are going to target something that is protected / supported by fanatical and vocal supporters, you really need to make sure that what you provide is bullet-proof and can stand up to criticism, else it will end up in a quagmire of flaming. Guess what hasn't happened so far?
If it is anything like the recent 'exploits' targeting the platform, then it is possible that the whole month will be taken up with vulnerable InputMangers, variations to the MachOMan PoC from ROY.G.BIV, vulnerabilities in third party code that is not enabled by default (such as against the installed PHP version), or vulnerabilities in image processing code (something that some researchers are focussing on).
All of these are known about and relatively trivial to uncover. Finisterre has received coverage in the past for claiming that he has numerous OS X vulnerabilities that Apple are refusing to acknowledge, and LMH's MoKB effort seemed to have an unhealthy focus on OS X (and there is debate over the effectiveness of some of those disclosed vulnerabilities and analysis).
Announcing this project via Brian Krebs, instead of on security mailing lists and disclosure sites, appears nothing more than self-promotion. This does nothing to help those who are opposed to this project, or these researchers, but is more than likely to lead to a major flamefest and could end up like the disclosure of the 'Remote Apple Wireless vulnerability' disclosed at the Black Hat Briefings in August - a small grain of truth, but a huge slab of self-promotion and wild-ass guessing to follow up.
It hasn't received much coverage (it was only made public a couple of weeks ago), but there is an exploitable buffer overflow vulnerability that affects Links. Technically, it affects the libpng library that Links links against, but the exploit / vulnerability development was focussing on Links as the vector to achieved the buffer overflow.
It seems that eEye are only linking to the '0-day' (for loose definitions of 0-day) vulnerabilities that their products can detect and protect against. There are many, many more 0-days that are out there, including an .asx 0-day (a true 0-day) which is more serious than this, and older as well. The only difference is that it doesn't target WMP.
.m3u method of exploiting the vulnerability) appears around the same time, and reporting is carried by the usual third parties. With no fix present, this remains an effective 0-day (plus, with existing malware targeting .asx files it could make for interesting real-world use).
.asx content, then they are potentially creating a much riskier environment than if they accept the current DoS risk against their platform.
.dmg file handling errors), and the way that information is flowing between, and being distributed by, third party reporting bodies in this case is showing similar patterns.
.asx (and other content types) data passed via 'ref href' that can lead to arbitrary code execution. .asx media type .asx filetype handler can lead to an increased security risk if the replacement application is XMPlay (accepting arbitrary code execution in an effort to avoid a DoS).
The recent coverage of ASX Playlist issues in various security mailing lists and forums seems somewhat strange. For the uninitiated, here is a quick wrapup:
XMPlay ASX buffer overflow PoC code posted to milw0rm - 21 November
This PoC demonstrated an exploitable buffer overflow condition in the handling of 'ref href' URIs. A CVE entry (CVE-2006-6063 - though this only identifies the
Windows Media Player DoS code posted to BugTraq - 22 November
Oddly, this code represented an almost exact duplicate of the buffer overflow demonstrated the day before, only with the exploit payload removed and replaced with a bunch of 'A's, and fails to draw much interest from third parties. It isn't until eEye publishes data on this issue (and increases the perceived threat posed) on their 0-day reporting / information site that it attracts some attention from other reporting parties (such as FrSIRT on 7 December), though uptake is slow.
Leaving Chinese Soup's critique (BugTraq) of eEye's analysis aside (why they haven't identified on the XMPlay vulnerability is another question), users need to be aware that if they replace WMP with XMPlay as the default handler of
If this particular code release had appropriate accompanying documentation, it would be possible to work out whether it is a derivative of the earlier code, or fortuitous timing on something found independently.
Criticism has been recently levelled against third party reporting bodies for failing to adequately investigate reports (after one of the recent MoKB OS X corrupted
In summary:
- There is a known 0-day targeting a vulnerability in XMPlay's handling of malicious
- There is a known DoS targeting WMP that is exploited via a long string passed via 'ref href' and using the
- There has been no proven link between the two disclosures
- It has yet to be shown that the WMP vulnerability leads to arbitrary code execution
- The advice to replace WMP as the default
If you look at the history of .asx file exploitation, there has been malware in the wild targeting various .asx vulnerabilities since at least Easter this year. This particular issue was publicly disclosed on November 22, and was only a DoS at the time. There are suspicions that it is a derivative of other code published publicly the day before, which targeted the XMPlay player (the exploits are very, very, very similar).
Either way, it probably won't see much of a change, though it is disappointing to see all the 'respected' InfoSec companies suckered in by eEye's dubious description (concerns have been raised on at least one security mailing list).
The recent coverage of ASX Playlist issues seems somewhat strange. For the uninitiated, here is a quick wrapup:
.m3u method of exploiting the vulnerability) appears around the same time, and reporting is carried by the usual third parties. With no fix present, this remains an effective 0-day (plus, with existing malware targeting .asx files it could make for interesting real-world use).
.asx content, then they are potentially creating a much riskier environment than if they accept the current DoS risk against their platform.
.dmg file handling errors), and the way that information is flowing between, and being distributed by, third party reporting bodies in this case is showing similar patterns.
.asx (and other content types) data passed via 'ref href' that can lead to arbitrary code execution. .asx media type .asx filetype handler can lead to an increased security risk if the replacement application is XMPlay (accepting arbitrary code execution in an effort to avoid a DoS).
XMPlay ASX buffer overflow PoC code posted to milw0rm - 21 November
This PoC demonstrated an exploitable buffer overflow condition in the handling of 'ref href' URIs. A CVE entry (CVE-2006-6063 - though this only identifies the
Windows Media Player DoS code posted to BugTraq - 22 November
Oddly, this code represented an almost exact duplicate of the buffer overflow demonstrated the day before, only with the exploit payload removed and replaced with a bunch of 'A's, and fails to draw much interest from third parties. It isn't until eEye publishes data on this issue (and increases the perceived threat posed) on their 0-day reporting / information site that it attracts some attention from other reporting parties (such as FrSIRT on 7 December), though uptake is slow.
Leaving Chinese Soup's critique (BugTraq) of eEye's analysis aside (why they haven't identified on the XMPlay vulnerability is another question), users need to be aware that if they replace WMP with XMPlay as the default handler of
If this particular code release had appropriate accompanying documentation, it would be possible to work out whether it is a derivative of the earlier code, or fortuitous timing on something found independently.
Criticism has been recently levelled against third party reporting bodies for failing to adequately investigate reports (after one of the recent MoKB OS X corrupted
In summary:
- There is a known 0-day targeting a vulnerability in XMPlay's handling of malicious
- There is a known DoS targeting WMP that is exploited via a long string passed via 'ref href' and using the
- There has been no proven link between the two disclosures
- It has yet to be shown that the WMP vulnerability leads to arbitrary code execution
- The advice to replace WMP as the default
Yes, JavaScript is an evil, evil thing in the hands of the malcontent, but having scripting support deactivated in your browser isn't really going to stop much. Some of the most recent work being carried out by Jeremiah Grossman and others who like to dabble in the area has shown that it is possible to enumerate systems on internal LANs via the browser of a visitor to an external website that the attacker controls.
Without Scripting enabled.
While the developed technique is still quite noisy and fairly obvious, there has been some work at making it more efficient. But, if you add enough shiny elsewhere on the page, then history has shown that people will be happy to put up with almost anything to get at the shiny.
Outside of the LAN, and with scripting support disabled, it is trivial to develop a network scanner that hits every port of every IP on the network segment that a site visitor is coming from, and which triggers only when the site is visited by the victim.
The bigger threat to AJAX in recent months has been the widely published (amongst security researchers) issues affecting the core AJAX components for Internet Explorer and Firefox. IE had threats affecting the XMLHTPPRequest ActiveX object (sort of core to the whole AJAX experience) as well as other threats targeting different scripting support, while Firefox had a number of issues affecting JavaScript support. Most of these issues had public exploit code and actively circulating exploits (though only in small numbers). Had something been developed which was aggressive in attacking these flaws, Web 2.0 could rapidly have become Web 0.2 for many users. Before you claim that trusted sites should be safe, the WMF vulnerabilities from last December / January showed that once an adhost gets compromised, it is game over for many many many sites that should otherwise be trusted.
I think it is more the case that Symantec and the other well-established Information Security vendors are like dinosaurs stuck in hot tar. The environment around them is rapidly changing, and the smarter of them are now starting to recognise that their existing income streams are becoming less relevant - as Microsoft makes security improvements to their OS, and the attackers continually test against the security products to improve their ability to avoid detection. Now that they are identifying it, it is still going to take some time for them to adjust to the new environment and results are going to be mixed (when was the last major discovery by Microsoft's much-acclaimed honey-monkeys?).
The third group of malware that you predict is out there and steadily gaining strength. Malware such as Haxdoor is used to extract as much juicy information as possible, before becoming a second stage malware (the money siphon). With the presence of significant botnets, easily written spiders / robots, it becomes a matter of how you define 'malware'. For example, some security vendors are classifying the distributed SETI client as malware, because clients are too lazy to block it via policy or other enforcement methods.
Of course, there are InfoSec companies out there that have been focussed on the changing environment from the very start.
When we first came across this information a few days ago, it was also linked to Mashable.com, which claims that up to 3,000 logins may have been compromised, and that they only recently became more successful in running the attack (having initially screwed up the inserted script). The other aspect is that Mashable appears to be talking about a slightly different phishing attack, which is still functional (using MySpace bulletins to spam other users).
Filtering based on blacklists (as you are suggesting MySpace admins do) doesn't always work. In this case, the URL that Netcraft discovered is only one of many being used to perpetrate the attack - as soon as one gets blacklisted, another will pop up. As to why it was left up for so long after discovery and notification? I guess people and companies just don't care as much about their security as they should.
If you want to see what we picked up on, you can always look here, or in my /. Journal.
Surely compromising the privacy for almost 10% of the nation, and that percentage being those that have served the country on the field of battle (as far back as WWII), would be more of a career limiting move than a voter influence program.
There are plenty of concerning aspects to the VA breach, and it would be really sad if that was the case.
Thanks for the response, I was concerned that you might not have realised how simple it can be to track someone down.
/., after all). Although your site (and subdomains) don't carry a lot of personally identifying information, and I doubt you are trying to spam mobile phone forum boards (as another networkboy does), you have left personal information out in the open in the past which can be correlated with your posts on /..
I know you are link #1 on Google (it is in your header on
Unfortunately, a lot of the ability to track down personal information is the result of people / agencies who have been entrusted with that information not being able to secure it effectively - just ask your nearest vet if they are full of love for the VA Department at the moment.
Uh, I came to that conclusion without the help of Google's second link. Just because Google lists it, doesn't mean it's relevant. How certain are YOU that Google's second link is our original poster?
The original poster was claiming safety because of his technological boundaries that were anonymising his location, but it was worth pointing out that the same technology anonymising his location could be used to find out a huge amount of information about them.
Now, I stopped looking before I got to the personal info - publishing that wasn't going to prove my point any further. Plus, Google isn't the source to turn to for that - it was a breadcrumb buried deep in a forgotten part of the web which gave that clue. I was pointing out that the clue did exist and the dedicated researcher can find it if they have the patience.
Asshat or not, that's what it takes, and it's what people do - there's no need to descend to name calling.
Okay, so how's life working for an ILEC? And, how's the Dell 8100 holding up?
Let's just say there are enough breadcrumbs to follow to determine:
- Family status
- State, City
- Interests
- Reasonable initial estimate at real name and ethnicity
It could probably go a lot further than that, but I stopped there. The point is that if you have been online long enough, you will leave a trail that can be followed through the Internet mists, even if you only use a nom de guerre.
If you can excuse the small amount of self promotion, I think that this is essentially an ethical decision.
With my company (http://www.beskerming.com), we run no ads on our site, and our free mailing list is just that, free. There are no subscription fees, no advertising, no vendor pitches (besides our own occasional announcement), no spam, and no vendor sponsorship. It keeps our readers happy, and we have seen our influence stretch to over 400 million people via those responsible for their information and financial security, without really pimping the service to all and sundry. So long as we've keep our overheads low, it doesn't matter how many people receive our message from that service. Sure, we'd like to make more money, grow the company and all that other stuff, but it all goes back into the company - improving the services we provide our clients.
Faith in humanity keeps the list free, and it breeds some responses in kind. After the list started getting spammed with pump'n'dump scams (at least the moderator was spammed - no messages made it on the list), we sent out a simple request for recipients to review their system security and to ask anybody they had forwarded a copy of our messages to to do the same. Within 18 hours, the spam stopped. No subscriber has ever unsubscribed, and even after polling them for what they wanted to have done with the list, most responded that they enjoyed having access to a truly free list and wanted it kept that way.
We originally started the list to build credibility and reputation in the eyes of the market, and to show some of our capabilities, and even though we only recently started spreading word about it, we have attracted some quality readership who are firm supporters (at least of our free work).
Yeah, it would be easy to spam the list silly with ads, sell the subscriber list, and otherwise bleed the readership dry, but that is not ethically or morally justifiable and so long as I control the ethical path of the company, it will never happen.
One argument that is often used to support the nepotism that used to take place in large family-owned companies is that the family had a vested interest in keeping the company solvent, and knew what it took from generation to generation to support and maintain the wealth and health of the company. Never mind that by the third generation things usually went pear shaped, as that generation was far enough removed from the founders who created the wealth so as to not understand what sacrifice and effort was required for the health of the company. Basically, the ethical decisions that created and grew the company in the first place were discarded for short term enjoyment of the wealth.