<![CDATA[[SecurityRatty] tag: constantly]]> http://securityratty.com/tag/constantly Thu, 11 Sep 2008 18:53:55 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[Confidentiality, Integrity, Availability - Pick Any Two]]> http://securityratty.com/article/c60f46f9f63d51e4a5a9e84ddb44cfe9 http://securityratty.com/article/c60f46f9f63d51e4a5a9e84ddb44cfe9 Under Worm Assault, Military Bans Disks, USB Drives


The Defense Department's geeks are spooked by a rapidly spreading worm crawling across their networks. So they've suspended the use of so-called thumb drives, CDs, flash media cards, and all other removable data storage devices from their nets, to try to keep the worm from multiplying any further.


The ban comes from the commander of U.S. Strategic Command, according to an internal Army e-mail. It applies to both the secret SIPR and unclassified NIPR nets. The suspension, which includes everything from external hard drives to "floppy disks," is supposed to take effect "immediately." Similar notices went out to the other military services.

In some organizations, the ban would be only a minor inconvenience. But the military relies heavily on such drives to store information. Bandwidth is often scarce out in the field. Networks are often considered unreliable. Takeaway storage is used constantly as a substitute.


Its almost like we built out a bunch of systems and then connected them to huge networks without building security into the software or something.
]]> Fri, 21 Nov 2008 06:50:19 +0000 networks worm assault huge networks worm flash media cards military bans disks internal army e-mail nipr nets military relies heavily Confidentiality, Integrity, Availability - Pick Any Two <![CDATA[Links List 11.7.08]]> http://securityratty.com/article/005aeccf95461397bcc44aae9976e6f2 http://securityratty.com/article/005aeccf95461397bcc44aae9976e6f2 Government contractors spill their thoughts about how Obama’s historic win will affect the industry. A majority of those questioned agreed to the fact that nothing will change overnight and everything will occur within 2-3 years. Others expressed thoughts on who will lead procurement and acquisition policy at GSA and OMB, as well as a possible hiring freeze for the government workforce. We’re also waiting to see what will happen to FISMA and IPv6 compliance going forward as a new administration and new OMB management sets their own agendas and mandates.

Due to the slow economy, most tech companies are being cautious and ratcheting back sales forecasts for software and hardware. The exception: Infra-Strategy, a company that operates a group of Web sites that help people find a lawyer and info to deal with bankruptcies, divorces and DUI cases. Visits to the sites are booming – with visits to totaldivorce.com, for example, up 112% in October 2008 (I found the picture on the website particularly compelling). Apparently, in bad times, divorce rates go up. Who knew?

Is it always a recession when it comes to IT Operations? Companies are constantly trying to find ways to do more with less in IT – reducing costs but keeping the same or even adding functionality – deploying technologies that drive IT consolidation such as mobile and remote access, unified communications and virtualization. Chris Silva of The Forrester Blog for IT Infrastructure & Operations Professionals is looking for a research panel to find out what fellow IT companies are doing to keep their IT budgets in check. To join the research panel visit: http://itpanel.forrester.com/.

The Cloud Computing Monopoly debate continues. O’Reilly Media founder Tim O’Reilly and technology writer Nicholas Carr (of “IT Doesn’t Matter” fame/infamy) have been discussing the ‘potential for a single company to achieve monopoly control of the world of cloud computing.’ But what’s even more interesting is the “who will make a lot of money” in cloud computing question.

]]> Fri, 07 Nov 2008 19:49:59 +0000 research panel visit research panel monopoly achieve monopoly control tech companies omb management sets companies omb forrester Links List 11.7.08 <![CDATA[Malware? We don't need no stinking malware!]]> http://securityratty.com/article/cbb029a08a78820b5ef90b69579719a1 http://securityratty.com/article/cbb029a08a78820b5ef90b69579719a1 Written by Oliver Fisher

"This site may harm your computer"
You may have seen those words in Google search results — but what do they mean? If you click the search result link you get another warning page instead of the website you were expecting. But if the web page was your grandmother's baking blog, you're still confused. Surely your grandmother hasn't been secretly honing her l33t computer hacking skills at night school. Google must have made a mistake and your grandmother's web page is just fine...



I work with the team that helps put the warning in Google's search results, so let me try to explain. The good news is that your grandmother is still kind and loves turtles. She isn't trying to start a botnet or steal credit card numbers. The bad news is that her website or the server that it runs on probably has a security vulnerability, most likely from some out-of-date software. That vulnerability has been exploited and malicious code has been added to your grandmother's website. It's most likely an invisible script or iframe that pulls content from another website that tries to attack any computer that views the page. If the attack succeeds, then viruses, spyware, key loggers, botnets, and other nasty stuff will get installed.

If you see the warning on a site in Google's search results, it's a good idea to pay attention to it. Google has automatic scanners that are constantly looking for these sorts of web pages. I help build the scanners and continue to be surprised by how accurate they are. There is almost certainly something wrong with the website even if it is run by someone you trust. The automatic scanners make unbiased decisions based on the malicious content of the pages, not the reputation of the webmaster.

Servers are just like your home computer and need constant updating. There are lots of tools that make building a website easy, but each one adds some risk of being exploited. Even if you're diligent and keep all your website components updated, your web host may not be. They control your website's server and may not have installed the most recent OS patches. And it's not just innocent grandmothers that this happens to. There have been warnings on the websites of banks, sports teams, and corporate and government websites.

Uh-oh... I need help!
Now that we understand what the malware label means in search results, what do you do if you're a webmaster and Google's scanners have found malware on your site?

There are some resources to help clean things up. The Google Webmaster Central blog has some tips and a quick security checklist for webmasters. Stopbadware.org has great information, and their forums have a number of helpful and knowledgeable volunteers who may be able to help (sometimes I'm one of them). You can also use the Google SafeBrowsing diagnostics page for your site (http://www.google.com/safebrowsing/diagnostic?site=<site-name-here>) to see specific information about what Google's automatic scanners have found. If your site has been flagged, Google's Webmaster Tools lists some of the URLs that were scanned and found to be infected.

Once you've cleaned up your website, use Google's Webmaster Tools to request a malware review. The automatic systems will rescan your website and the warning will be removed if the malware is gone.

Advance warning
I often hear webmasters asking Google for advance warning before a malware label is put on their website. When the label is applied, Google usually emails the website owners and then posts a warning in Google's Webmaster Tools. But no warning is given ahead of time - before the label is applied - so a webmaster can't quickly clean up the site before a warning is applied.

But, look at the situation from the user's point of view. As a user, I'd be pretty annoyed if Google sent me to a site it knew was dangerous. Even a short delay would expose some users to that risk, and it doesn't seem justified. I know it's frustrating for a webmaster to see a malware label on their website. But, ultimately, protecting users against malware makes the internet a safer place and everyone benefits, both webmasters and users.

Google's Webmaster Tools has started a test to provide warnings to webmasters that their server software may be vulnerable. Responding to that warning and updating server software can prevent your website from being compromised with malware. The best way to avoid a malware label is to never have any malware on the site!

Reviews
You can request a review via Google's Webmaster Tools and you can see the status of the review there. If you think the review is taking too long, make sure to check the status. Finding all the malware on a site is difficult and the automated scanners are far more accurate than humans. The scanners may have found something you've missed and the review may have failed. If your site has a malware label, Google's Webmaster Tools will also list some sample URLs that have problems. This is not a full list of all of the problem URLs (because that's often very, very long), but it should get you started.

Finally, don't confuse a malware review with a request for reconsideration. If Google's automated scanners find malware on your website, the site will usually not be removed from search results. There is also a different process that removes spammy websites from Google search results. If that's happened and you disagree with Google, you should submit a reconsideration request. But if your site has a malware label, a reconsideration request won't do any good — for malware you need to file a malware review from the Overview page.



How long will a review take?
Webmasters are eager to have a Google malware label removed from their site and often ask how long a review of the site will take. Both the original scanning and the review process are fully automated. The systems analyze large portions of the internet, which is big place, so the review may not happen immediately. Ideally, the label will be removed within a few hours. At its longest, the process should take a day or so.
]]> Fri, 24 Oct 2008 10:25:00 +0000 malware google malware label label malware review tools webmaster tools lists malware label webmaster tools google Malware? We don't need no stinking malware! <![CDATA[Malware? We don't need no stinking malware!]]> http://securityratty.com/article/7b001609aa5afd4ad270a86d179c2f41 http://securityratty.com/article/7b001609aa5afd4ad270a86d179c2f41 Written by Oliver Fisher

"This site may harm your computer"
You may have seen those words in Google search results — but what do they mean? If you click the search result link you get another warning page instead of the website you were expecting. But if the web page was your grandmother's baking blog, you're still confused. Surely your grandmother hasn't been secretly honing her l33t computer hacking skills at night school. Google must have made a mistake and your grandmother's web page is just fine...



I work with the team that helps put the warning in Google's search results, so let me try to explain. The good news is that your grandmother is still kind and loves turtles. She isn't trying to start a botnet or steal credit card numbers. The bad news is that her website or the server that it runs on probably has a security vulnerability, most likely from some out-of-date software. That vulnerability has been exploited and malicious code has been added to your grandmother's website. It's most likely an invisible script or iframe that pulls content from another website that tries to attack any computer that views the page. If the attack succeeds, then viruses, spyware, key loggers, botnets, and other nasty stuff will get installed.

If you see the warning on a site in Google's search results, it's a good idea to pay attention to it. Google has automatic scanners that are constantly looking for these sorts of web pages. I help build the scanners and continue to be surprised by how accurate they are. There is almost certainly something wrong with the website even if it is run by someone you trust. The automatic scanners make unbiased decisions based on the malicious content of the pages, not the reputation of the webmaster.

Servers are just like your home computer and need constant updating. There are lots of tools that make building a website easy, but each one adds some risk of being exploited. Even if you're diligent and keep all your website components updated, your web host may not be. They control your website's server and may not have installed the most recent OS patches. And it's not just innocent grandmothers that this happens to. There have been warnings on the websites of banks, sports teams, and corporate and government websites.

Uh-oh... I need help!
Now that we understand what the malware label means in search results, what do you do if you're a webmaster and Google's scanners have found malware on your site?

There are some resources to help clean things up. The Google Webmaster Central blog has some tips and a quick security checklist for webmasters. Stopbadware.org has great information, and their forums have a number of helpful and knowledgeable volunteers who may be able to help (sometimes I'm one of them). You can also use the Google SafeBrowsing diagnostics page for your site (http://www.google.com/safebrowsing/diagnostic?site=<site-name-here>) to see specific information about what Google's automatic scanners have found. If your site has been flagged, Google's Webmaster Tools lists some of the URLs that were scanned and found to be infected.

Once you've cleaned up your website, use Google's Webmaster Tools to request a malware review. The automatic systems will rescan your website and the warning will be removed if the malware is gone.

Advance warning
I often hear webmasters asking Google for advance warning before a malware label is put on their website. When the label is applied, Google usually emails the website owners and then posts a warning in Google's Webmaster Tools. But no warning is given ahead of time - before the label is applied - so a webmaster can't quickly clean up the site before a warning is applied.

But, look at the situation from the user's point of view. As a user, I'd be pretty annoyed if Google sent me to a site it knew was dangerous. Even a short delay would expose some users to that risk, and it doesn't seem justified. I know it's frustrating for a webmaster to see a malware label on their website. But, ultimately, protecting users against malware makes the internet a safer place and everyone benefits, both webmasters and users.

Google's Webmaster Tools has started a test to provide warnings to webmasters that their server software may be vulnerable. Responding to that warning and updating server software can prevent your website from being compromised with malware. The best way to avoid a malware label is to never have any malware on the site!

Reviews
You can request a review via Google's Webmaster Tools and you can see the status of the review there. If you think the review is taking too long, make sure to check the status. Finding all the malware on a site is difficult and the automated scanners are far more accurate than humans. The scanners may have found something you've missed and the review may have failed. If your site has a malware label, Google's Webmaster Tools will also list some sample URLs that have problems. This is not a full list of all of the problem URLs (because that's often very, very long), but it should get you started.

Finally, don't confuse a malware review with a request for reconsideration. If Google's automated scanners find malware on your website, the site will usually not be removed from search results. There is also a different process that removes spammy websites from Google search results. If that's happened and you disagree with Google, you should submit a reconsideration request. But if your site has a malware label, a reconsideration request won't do any good — for malware you need to file a malware review from the Overview page.



How long will a review take?
Webmasters are eager to have a Google malware label removed from their site and often ask how long a review of the site will take. Both the original scanning and the review process are fully automated. The systems analyze large portions of the internet, which is big place, so the review may not happen immediately. Ideally, the label will be removed within a few hours. At its longest, the process should take a day or so.
]]> Fri, 24 Oct 2008 10:25:00 +0000 malware google malware label label malware review tools webmaster tools lists malware label webmaster tools google Malware? We don't need no stinking malware! <![CDATA[MS08-067 and the SDL]]> http://securityratty.com/article/df5eba2c21ebdf631d2dd9fbe82532ab http://securityratty.com/article/df5eba2c21ebdf631d2dd9fbe82532ab Hi, Michael here.

No doubt you are aware of the out-of-band security bulletin issued by the Microsoft Security Response Center today, and like all security vulnerabilities, this is a vulnerability we can learn from and, if necessary, can use to shape future versions of the Security Development Lifecycle (SDL).

Before I get into some of the details, it's important to understand that the SDL is designed as a multi-pronged security process to help systemically reduce security vulnerabilities. In theory, if one facet of the SDL process fails to prevent or catch a bug, then some other facet should prevent or catch the bug. The SDL also mandates the use of security defenses, because we know full well that the SDL process will never catch all security bugs. As we have said many times, the goal of the SDL is to "Reduce vulnerabilities, and reduce the severity of what's missed."

In this post, I want to focus on the SDL-required code analysis, code review, fuzzing and compiler and operating system defenses and how they fared.

Code Analysis and Review

I want to start by analyzing the code to understand why we did not find this bug through manual code review nor through the use of our static analysis tools. First, the code in question is reasonably complex code to canonicalize path names; for example, strip out ‘..' characters and such to arrive at the simplest possible directory name. The bug is a stack-based buffer overflow inside a loop; finding buffer overruns in loops, especially complex loops, is difficult to detect with a high degree of probability without producing many false positives. At a later date I will publish more of the source code for the function.

The loop inside the function walks along an incoming string to determine if a character in the path might be a dot, dot-dot, slash or backslash and if it is then applies canonicalization algorithms.

The irony of the bug is it occurs while calling a bounded function call:

_tcscpy_s(previousLastSlash, pBufferEnd - previousLastSlash, ptr + 2);

This function is a macro that expands to wcscpy_s(dest, len, source); technically, the bug is not in the call to wcscpy_s, but it's in the way the arguments are calculated. As I alluded to, all three arguments are highly dynamic and constantly updated within the while() loop. There is a great deal of pointer arithmetic in this loop. Without going into all the gory attack details, given a specific path, and after the while() loop has been passed through a few times, the pointer, previousLastSlash, gets clobbered.

In my opinion, hand reviewing this code and successfully finding this bug would require a great deal of skill and luck. So what about tools?  It's very difficult to design an algorithm which can analyze C or C++ code for these sorts of errors.  The possible variable states grows very, very quickly.  It's even more difficult to take such algorithms and scale them to non-trivial code bases. This is made more complex as the function accepts a highly variable argument, it's not like the argument is the value 1, 2 or 3! Our present toolset does not catch this bug.

Ok, now I'm really going out on a limb with this next section.

Over the last year or so I've noticed that the security vulnerabilities across Microsoft, but most noticeably in Windows have become bugs of a class I call "onesey - twosies" in other words, one-off bugs. There is a good side and a bad side to this. First the good news; I think perhaps we have removed a good number of the low-hanging security vulnerabilities from many of our products, especially the newer code. The bad news is, we'll continue to have vulnerabilities because you cannot train a developer to hunt for unique bugs, and creating tools to find such bugs is also hard to do without incurring an incredible volume of false positives. With all that said, I will add detail about one-off bugs to our internal education; I think it's important to make people aware that even with great tools and great security-savvy engineers, there are still bugs that are very hard to find.

Fuzz Testing

I'll be blunt; our fuzz tests did not catch this and they should have. So we are going back to our fuzzing algorithms and libraries to update them accordingly. For what it's worth, we constantly update our fuzz testing heuristics and rules, so this bug is not unique.

Defenses

If you want the full details of the defenses, and how they come into play on Windows Vista and Windows Server 2008, I urge you to read teh SVRD team's in-depth analysis once it is posted.

A big focus of the SDL is to define and require defenses because we have no allusions about finding or preventing all security vulnerabilities by attempting to get the code right all the time, because no-one can do that. No one.  See my comment above about one-off bugs!

Let's look at each SDL mandated requirement and how they fared in light of this vulnerability.

-GS

The -GS story is not so simple. A lot of code is executed before a cookie check is made and the attacker can control the overflow because the overflow starts at an offset before the stack buffer, rather than at the stack buffer itself. So the attacker can overwrite other frames on the call stack, corresponding to functions that return before a cookie check is made. That's a long way of saying that -GS was not meant to prevent this type of scenarios.

ASLR and NX

The code fully complies with the SDL, and is linked with /DYNAMICBASE and /NXCOMPAT on Windows Vista and Windows Server 2008. There are great defenses when used together, and reduce the chance of a successful attack substantially. Also, the stack offset is randomized too, making a deterministic attack even more unlikely.

Service Restart Policy

By default the affected service is marked to restart only twice after a crash on Windows Vista and Windows Server 2008, which means the attacker has only two attempts to get the attack right. Prior to Windows Vista, the attacker has unlimited attempts because the service restarts indefinitely.

Authentication

Thanks to mandatory integrity control (MIC) settings (which comes courtesy of UAC) the networking endpoint that leads to the vulnerable code requires authentication on Windows Vista and Windows Server 2008 by default. Prior to Windows Vista, the end point is always anonymous, so anyone can attack it, so long as the attacker can traverse the firewall. This is a great example of SDL's focus on attack surface reduction; requiring authentication means the number of attackers that can access the entry point is dramatically reduced.

Firewall

We enabled the firewall by default in Windows XP SP2 and later, this was a direct learning from the Blaster worm. By default, ports 139 and 445 are not opened to the Internet on Windows XP SP2, Windows Vista and Windows Server 2008.

Summary

The $64,000 question we ask ourselves when we issue any bulletin is "did SDL fail?" and the answer in this case is categorically "No!" No because as I said earlier the goal of the SDL is "Reduce vulnerabilities, and reduce the severity of what you miss." Windows Vista and Windows Server 2008 customers are protected by the defenses in the operating system that have been crafted in part by the SDL. The development team who built the affected component compiled and linked with the appropriate settings as described in "Windows Vista ISV Security" and Writing Secure Code for Windows Vista so that their service is protected by the operating system.

The team did not poke holes through the firewall unnecessarily, in accordance with the SDL.

The team reduced their attack surface, in accordance with the SDL, by requiring authenticated connections rather than anonymous connections by default.

We know that the SDL-mandated -GS has very strict heuristics so some functions are not protected by a stack cookie, but in this case, there is no buffer on the stack, so there will be no cookie. We know this. There are no plans to remedy this in the short term.

Fuzzing missed the bug, so we will update our fuzz testing heuristics, but we continually update our fuzzing heuristics anyway.

In short, based on what we know right now, Windows Vista and Windows Server 2008 customers are protected because of the SDL-mandated defenses in the operating system, and because the development team adhered to the letter of the SDL to take advantage of those defenses.

Chalk one up for Windows Vista and later and the SDL!

As usual, questions and comments are very welcome.

]]> Wed, 22 Oct 2008 21:09:00 +0000 manual code review code review vulnerabilities reduce security vulnerabilities sdl windows windows server sdl process fails sdl process MS08-067 and the SDL <![CDATA[$20M Cameras at New York's Freedom Tower are Pretty Sophisticated]]> http://securityratty.com/article/1854e20c6c17653e3ad8d28eb7bdb765 http://securityratty.com/article/1854e20c6c17653e3ad8d28eb7bdb765 They're trying to detect anomalies:

If you have ever wondered how security guards can possibly keep an unfailingly vigilant watch on every single one of dozens of television monitors, each depicting a different scene, the answer seems to be (as you suspected): they can't.

Instead, they can now rely on computers to constantly analyze the patterns, sizes, speeds, angles and motion picked up by the camera and determine -- based on how they have been programmed -- whether this constitutes a possible threat. In which case, the computer alerts the security guard whose own eyes may have been momentarily diverted. Or shut.

An alarm can be raised, for instance, if the computer discerns a vehicle that has been standing still for too long (say, a van in the drop-off lane of an airport terminal) or a person who is loitering while everyone else is in motion. By the same token, it will spot the individual who is moving rapidly while everyone else is shuffling along. It can spot a package that has been left behind and identify which figure in the crowd abandoned it. Or pinpoint the individual who is moving the wrong way down a one-way corridor.

Because one person's "abnormal situation" is another person's "hot dog vendor attracting a small crowd," the computers can be programmed to discern between times of the day and days of the week.

Certainly interesting.

]]> Thu, 25 Sep 2008 02:32:08 +0000 person hot dog vendor security guards individual unfailingly vigilant constantly analyze security guard detect anomalies television monitors $20M Cameras at New York's Freedom Tower are Pretty Sophisticated <![CDATA[Malware Infected Spam Threatens To Suspend Internet Access]]> http://securityratty.com/article/ad4479003627ad415e178e7393d28fb4 http://securityratty.com/article/ad4479003627ad415e178e7393d28fb4 Wed, 17 Sep 2008 16:47:32 +0000 malicious file attachment internet time spam email trendlabs reports malicious files simple social scare people tactics Malware Infected Spam Threatens To Suspend Internet Access <![CDATA[The Importance of Trust]]> http://securityratty.com/article/a237a38c2b93a16a5d0702327c562838 http://securityratty.com/article/a237a38c2b93a16a5d0702327c562838
Integrity, Honor, Loyalty - all of these fine characteristics are the building blocks upon which reputations are raised. It is of the utmost importance in any walk of life to "live by your word", but in the security profession - especially where the protecting of life is concerned, it is everything.

I attended National Stadium last night and watched the Washington Nationals beat the New York Mets. I was fortunate to have been invited to enjoy the game from the president's box. During the pre-dinner networking, I ran into a business owner whom I had met a few years previously. He had been introduced to me at that time as his business involved him being around some area celebrity sporting stars.

Being interested in a chance to possibly offer executive protection services to these stars, I arranged to meet with this business owner to discuss how we might be able to assist one another. I remember it was during the winter and the roads were a little suspect in places as I drove the 25-30 miles to be closer to his location.

I arrived a little early, as is my custom and waited for him to arrive. It became clear after about an hour that he was experiencing some difficulty or had some other reason for being so late. I left a few voice mails and called it quits after around 90 minutes. He never returned any of my calls but when I reached him about a week later he admitted that something else had come up. Unfortunately, he did not think it worth his while to let me know this with a phone call.

So, here I am last night and this same person is introduced to me once again. Maybe he didn't remember back three years ago because he started to tell me about some connection that he knew that may be a "good fit" for my company. His small talk fell on deaf ears. He had already lost all credibility with me and eventhough I have not thought about it once in the inetrvening years, as soon as I saw him it came back as clear as day.

In his book; "The Speed of Trust", the author Stephen M.R. Covey sums it up best - "keeping commitments is based on the principles of integrity, performance, courage and humility. It is the perfect balance of character and competence. Particularly, it involves integrity (character) and your ability to do what you say you are going to do (competence)."
Visit Sexton Executive Security at www.sextonsecurity.com
]]> Tue, 16 Sep 2008 15:46:00 +0000 importance business business owner integrity involves integrity utmost importance competence security profession deaf ears The Importance of Trust <![CDATA[Wee-Fi: Routing Out an Address; Badger-Fi]]> http://securityratty.com/article/47e82ddcf180a1e8e117a5087166b7f3 http://securityratty.com/article/47e82ddcf180a1e8e117a5087166b7f3 Slashdot breathlessly posts an item by coderrr that Skyhook Wireless is exposing people's addresses: Yeah, whatever. Skyhook has accidentally offered an API that lets you query their Wi-Fi positioning system for latitude and longitude using a MAC address. Skyhook constantly drives major cities around the world and integrates scans created by users of their systems as well. The poster defines a non-existent problem: first, a scammer needs to get someone's MAC address; then you need to pair a rough lat/long with their street address; then, coderrr says, you'd get a phishing email with your home address. Whatever. If my machine is compromised enough that you can obtain my MAC address and then launch a phishing attack, I have worse problems already than my street address being in the email--which is unlikely given that most Wi-Fi scans will be in urban areas. It's likely Skyhook will modify their systems to prevent submission of such queries, or perhaps open their API further.

Madison Wi-Fi network sold to Atlanta firm: Xiocom purchases Mad City Broadband, a firm that has suffered significant criticism over the performance of its Wi-Fi network in Madison, Wisc. The press release from Xiocom (some quoted in the Badger Herald article) are a bit over the top about a network that reportedly has few users, inconsistent performance, and covers only a fraction of the city.

]]> Fri, 12 Sep 2008 07:34:26 +0000 wi-fi network madison wi-fi network madison wi-fi network mac address skyhook skyhook wireless skyhook constantly Wee-Fi: Routing Out an Address; Badger-Fi <![CDATA[Who is "dodacrazy" and what is a "montize buddy"?]]> http://securityratty.com/article/1cc25691e6f3d8a040ab59fc022a20c8 http://securityratty.com/article/1cc25691e6f3d8a040ab59fc022a20c8 Check this out:

http://blogs.technet.com/steriley/archive/2008/06/25/directly-connect-to-your-corpnet-with-ipsec-and-ipv6.aspx#3122377

Hey Steve you and your montize buddy Scott will soon have your hands full after the federal officers come down on your data scams and as for your educational acts i'm not buying it and if others are willing to trade your data for their profits guess there are fools born everyday tunnels oh I see drug dealers right Stevo

Normally I delete spam from my comments, and have occasionally deleted mindless ranting criticism (I encourage vigorous discussion of ideas, but won't allow personal attacks). However, this guy's comment is just...weird.

  • What's a "montize buddy Scott"? I know lots of Scotts, and once even admired a particular "Montgomery Scot." But "montize"? Maybe it's a new kind of malt.
  • I don't believe I'm perpetuating any data scams, none that I know of, anyway. If any of you, my readers, feel that I'm scamming your data, I guess I haven't concealed that fact well enough. Oops, sorry! We'll have to add another item to the constantly-growing list of data breaches.
  • While it's true that some of my conference appearances aren't free, no one is certainly forced to buy any of my "educational acts." A lot of my presentations you can download for free!
  • I never look in tunnels for my supplies, they're too dark and you can never be totally certain of what you're getting.

Thanks, dodacrazy, for a good Thursday morning laugh!

]]> Thu, 11 Sep 2008 18:53:55 +0000 data data breaches data scams educational acts buddy scott tunnels everyday tunnels encourage vigorous discussion montgomery scot Who is "dodacrazy" and what is a "montize buddy"?