<![CDATA[[SecurityRatty] tag: corpus]]> http://securityratty.com/tag/corpus Mon, 17 Sep 2007 05:32:00 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[Wee-Fi: First Starbucks with AT&T? Plus, L.I.-Fi, Panasonic Camera, Corpus Christi Decision]]> http://securityratty.com/article/9a504a1c75e765efa1c52eb2851c4542 http://securityratty.com/article/9a504a1c75e765efa1c52eb2851c4542 AT&T-equipped Starbucks live in San Antonio? Alan Weinkrantz believes he's spotted the first transitioned Starbucks. He saw installers putting in gear, and the login screen shows AT&T Wi-Fi prominently, with T-Mobile's HotSpot logo relegated to a square in the upper right. He may be right. In Seattle and New York at least, the Starbucks login banner shows T-Mobile prominently across the top with AT&T in a square at the upper right, as I noted with Klaus Ernst's help on 10 April 2008. The store is located a few miles from AT&T's HQ.

Suffolk signs contract with E-Path: After yesterday's scathing New York Times article--which I wrote up and elaborated on--you might be surprised to read that Suffolk County's executive Steve Levy has signed a contract with E-Path, the Wi-Fi network builder. As of Monday, Levy was saying that no services would need to be paid for by the county. Now, it's "a price 'as close to zero as possible.'" Apparently the contract doesn't specify any actual purchase of services? While the New York Times was unable to get E-Path's head on the phone, Newsday had no such problem. E-Path's Joe Tortoretti is now saying that an anchor tenant and minimum service commitments are needed to build a network. That's rather a different tune, isn't it? E-Path, a firm that has built no such networks to date, is now going after the Long Island Railroad, too, with Levy's backing. Shouldn't this be bid out again by the county, given all the terms have changed?

lumixtz50.jpgPanasonic adds Wi-Fi camera: The Lumix DMC-TZ50 can upload directly to Google's Picasa photo-sharing service. It's got a 9.1-megapixel sensor, and comes with 12 months of free service at T-Mobile hotspots in the U.S. As I have noted many times before, uploading and "emailing" photos via photo-sharing services from Wi-Fi-enabled cameras typically involves a downsampled or compressed image, and that level of degradation isn't noted in the widely marketed information about the camera.

Corpus Christi to reclaim network: The city council voted 7-0 last night to take its Wi-Fi network back over from EarthLink. As noted yesterday, EarthLink avoids paying $1.59m in fees to the city, but the city gets $3m in improvements, and hundreds of thousands of dollars in additional equipment. The improbably amount of $50,000 in yearly operating expense was once again bandied about in this GigaOm report.

]]> Wed, 16 Apr 2008 08:03:00 +0000 york times article york times starbucks wi-fi network builder wi-fi network york network starbucks login banner noted yesterday Wee-Fi: First Starbucks with AT&T? Plus, L.I.-Fi, Panasonic Camera, Corpus Christi Decision <![CDATA[Corpus Christi Cuts EarthLink's Cord]]> http://securityratty.com/article/ab848a887ec14b0cb3a2bd5842df38fc http://securityratty.com/article/ab848a887ec14b0cb3a2bd5842df38fc The city council of Corpus Christi will move Tuesday night to resume control from EarthLink of its Wi-Fi network: The network was originally built by the city to support municipal purposes, such as meter reading, and was sold to EarthLink for $5.3m plus $340,000 in other revenues, the local paper reports. The sale was reported back in March 2007 as a way for the city to gain better coverage without investing their own money and recoup some of their expense. EarthLink did complete the network in August, but its future--like all of EarthLink's municipal efforts--is completely uncertain. EarthLink is likely to sell, shut down, or abandon all its municipal networks based on statements over the last several months.

Corpus Christi, if it resumes ownership of the network, wouldn't operate ubiquitous public access Wi-Fi, however. It would focus on nine areas of free service currently in place, which could expand in the future; municipal uses would continue.

EarthLink would avoid paying $1.59m remaining in its contract, but the city would get improvements that total $1.76m, as well as $830,000 in additional equipment that were used in building out the network. Yearly operating costs are reported here as $50,000, which seems insanely low. Perhaps with only municipal purposes, there's no backhaul cost. But radios die and equipment needs to be moved. I would expect a cost in the hundreds of thousands for a 147 sq mi network.

]]> Mon, 14 Apr 2008 11:46:27 +0000 support municipal purposes municipal purposes earthlink municipal municipal networks based corpus christi network wi-fi network city council Corpus Christi Cuts EarthLink's Cord <![CDATA[Cached Malware Embedded Sites]]> http://securityratty.com/article/840ac2ff78d7289af74b7104dfbb7f26 http://securityratty.com/article/840ac2ff78d7289af74b7104dfbb7f26 Google, with its almost real-time crawling capabilities, has rarely proved useful while researching malware embedded sites who were cleaned before they could be analyzed, mainly popular sites who get crawled several times daily. However, Yahoo's and MSN's search engines, with MSN providing Archive.org type of historical crawling content, have been an invaluable resource in providing the actionable historical intelligence in the form of what was embedded at the site, where was it pointing, are there many other sites currently embedded by the same campaign etc. This is an interesting opinion stating that cached malware embedded sites are a security problem, well they're, but the bigger problem to me is that it's only Google that's taken efforts to deal with the problem next to the market challengers - Yahoo and MSN - "Google, Yahoo, Microsoft Live search engines contain page-caching flaw, says Aladdin" :

"Researchers at Aladdin Knowledge Systems have discovered a “significant” vulnerability in the page-caching technologies of three major search engines, allowing them to deliver malicious pages that have been removed from the web. The researchers discovered the vulnerability when analysing the content of a hacked university website. The site was cleaned, but malicious content was still reachable via search engine caches. The flaw is a "glimpse of the future" of multifaceted web-based attacks, said Ofer Elzam, director of product management at Aladdin."

Let's discuss the current model of dealing with such sites. Whenever Google comes across a site that's potentially malware embedded, they don't just label it "this site may harm you computer" but also remove all the cached copies of the site. By doing so, they protect the "cached surfers crowd", and by doing so, often prompt me to locate the actual cached copies with the embedded malware hopefully still there by using other search engines, ones whose crawling capabilities aren't as fast as Google's.

Therefore, don't put Google in the same row as Yahoo and MSN, since Yahoo and MSN do not provide such in-house built malware embedded sites notification services, and given the slow content crawling, it's among the top reasons why I love using their search engines given I'm aware of a malware embedded site, but couldn't obtain the obfuscated javascript/IFRAME before it got removed.

Here's an example of how useful cached malware sites are for research purposes. Back in September, the U.S Consulate in St.Petersburg was serving malware, and the embedded malware link was removed sooner than I could obtain a copy of the infected page. Best of all - there were still cached copies available serving the malware which lead to the assessment of the campaign. Another great example that the intelligence sharing between the industry, independent reseachers and non-profit organizations, is resulting in far more detailed exposures of various malicious campaigns, compared to a vendor's self-sufficiency mentality.

This is how Google understand the malicious economies of scale, where efficiency gets sacrificed for a short lifecycle of the campaign, a trade-off I've been discussing for a while especially in respect to the Rock Phish Kit :

"Examining our data corpus over time, we discovered that the majority of the exploits were hosted on third-party servers and not on the compromised web sites. The attacker had managed to compromise the web site content to point towards an external URL hosting the exploit either via iframes or external JavaScript. Another, less popular technique, is to completely redirect all requests to the legitimate site to another malicious site. It appears that hosting exploits on dedicated servers offers the attackers ease of management. Having pointers to a single site offers an aggregation point to monitor and generate statistics for all the exploited users. In addition, attackers can update their portfolio of exploits by just changing a single web page without having to replicate these changes to compromised sites. On the other hand, this can be a weakness for the attackers since the aggregating site or domain can become a single point of failure."

Google are clearly aware of what's going on, but are trying to limit the potential for false positives of sites wrongly flagged as ones serving malware, which is where malicious parties will be innovating in the future, while it still remains questionable why they still haven't done so by obvious means - RBN's directory permissions gone wrong for instance.

The bottom line - cached malware embedded sites are a valuable resource in the arsenal of tools for the security researcher/malware analyst to use, and not necessarily a threat if it's Google's approach of removing the cached copies we're talking about, prior to notifying of the infection. Which leads us to more realistic attack tactic than the one discussed in the article, where an attacker will supposedely embedd malware at different sites, let the search engines crawl and cache it, than remove the sites and wait for the visitors to use the cache, thereby infecting themselves. Case in point - the U.S Consulate's site for instance wasn't even flagged by Google as malware embedded one, which is hopefully the result of their fast crawling capabilities, but the ugly attack tactic I have in mind is not just embedding the IFRAME, but embedding an obfuscated IFRAME that leads to the usual obfuscated exploit URL, which is what happend in the Consulate's case, an obfuscated IFRAME by itself.
]]> Sun, 16 Dec 2007 15:18:26 +0000 sites sites wrongly web sites malware malicious site site single site offers sites notification services popular sites Cached Malware Embedded Sites <![CDATA[Information flow tracing and software testing]]> http://securityratty.com/article/3c56ee518b4f0794f66ee670bb37a390 http://securityratty.com/article/3c56ee518b4f0794f66ee670bb37a390 Posted by Will Drewry, Security Team

Security testing of applications is regularly performed using fuzz testing. As previously discussed on this blog, Srinath's Lemon uses a form of smart fuzzing. Lemon is aware of classes of web application threats and the input families which trigger them, but not all fuzz testing frameworks have to be this complicated. Fuzz testing originally relied on purely random data, ignorant of specific threats and known dangerous input. Today, this approach is often overlooked in favor of more complicated techniques. Early sanity checks in applications looking for something as a simple as a version number may render testing with completely random input ineffective. However, the newer, more complicated fuzz testers require a considerable initial investment in the form of complete input format specifications or the selection of a large corpus of initial input samples.

At WOOT'07,I presented a paper on Flayer, a tool we developed internally to augment our security testing efforts. In particular, it allows for a fuzz testing technique that compromises between the original idea and the most complicated. Flayer makes it possible to remove input sanity checks at execution time. With the small investment of identifying these checks, Flayer allows for completely random testing to be performed with much higher efficacy. Already, we've uncovered multiple vulnerabilities in Internet-critical software using this approach.

The way that Flayer allows for sanity checks to be identified is perhaps the more interesting point. Flayer uses a dynamic analysis framework to analyze the target application at execution time. Flayer marks, or taints, input to the program and traces that data throughout its lifespan. Considerable research has been done in the past regarding information flow tracing using dynamic analysis. Primarily, this work has been aimed at malware and exploit detection and defense. However, none of the resulting software has been made publicly available.

While Flayer is still in its early stages, it is available for download under the GNU Public License. External contributions and feedback are encouraged!]]> Mon, 17 Sep 2007 05:32:00 +0000 input flayer marks initial input samples flayer fuzz fuzz testers require checks dynamic analysis framework sanity checks Information flow tracing and software testing <![CDATA[Information flow tracing and software testing]]> http://securityratty.com/article/a7d6dc5592aff250cf08f6f4236b0ed6 http://securityratty.com/article/a7d6dc5592aff250cf08f6f4236b0ed6 Posted by Will Drewry, Security Team

Security testing of applications is regularly performed using fuzz testing. As previously discussed on this blog, Srinath's Lemon uses a form of smart fuzzing. Lemon is aware of classes of web application threats and the input families which trigger them, but not all fuzz testing frameworks have to be this complicated. Fuzz testing originally relied on purely random data, ignorant of specific threats and known dangerous input. Today, this approach is often overlooked in favor of more complicated techniques. Early sanity checks in applications looking for something as a simple as a version number may render testing with completely random input ineffective. However, the newer, more complicated fuzz testers require a considerable initial investment in the form of complete input format specifications or the selection of a large corpus of initial input samples.

At WOOT'07,I presented a paper on Flayer, a tool we developed internally to augment our security testing efforts. In particular, it allows for a fuzz testing technique that compromises between the original idea and the most complicated. Flayer makes it possible to remove input sanity checks at execution time. With the small investment of identifying these checks, Flayer allows for completely random testing to be performed with much higher efficacy. Already, we've uncovered multiple vulnerabilities in Internet-critical software using this approach.

The way that Flayer allows for sanity checks to be identified is perhaps the more interesting point. Flayer uses a dynamic analysis framework to analyze the target application at execution time. Flayer marks, or taints, input to the program and traces that data throughout its lifespan. Considerable research has been done in the past regarding information flow tracing using dynamic analysis. Primarily, this work has been aimed at malware and exploit detection and defense. However, none of the resulting software has been made publicly available.

While Flayer is still in its early stages, it is available for download under the GNU Public License. External contributions and feedback are encouraged!
]]> Mon, 17 Sep 2007 05:32:00 +0000 input flayer marks initial input samples flayer fuzz fuzz testers require checks dynamic analysis framework sanity checks Information flow tracing and software testing