crashes and burns upon launch The Commonwealth of Massachusetts has a convoluted(*) unemployment insurance system, under which employers are required to make various quarterly and annual filings and quarterly payments involving at least two different state agencies. This system is administered by the Department of Unemployment Assistance (DUA), who decided to replace their old, paper-based system with a Web-based system called QUEST ("Quality Unemployment System Transformation"). The DUA promised QUEST would bring countless improvements: one-stop shopping, filings for all agencies in one place, faster filings, less wasted paper, reduced printing and postage costs, reduced data entry costs, no more data transcription errors, etc., etc. You've no doubt heard it all before. QUEST went live at the beginning of 2010. As of the go-live date, the usage of QUEST for all employer unemployment insurance transactions was mandatory; paper filings were no longer permitted. I.e., the DUA went straight from paper filings only to on-line filings only, with no transition period or overlap.(**) It would be an understatement to say that QUEST is having some problems. It would probably be more accurate to say that it is a disaster. Some examples of the issues I've experienced trying to use the new system today to do my filing for the last quarter of 2009: * I received an e-mail message informing me that there was correspondence in my QUEST inbox, and I should log into QUEST to read it. When I log into QUEST and click on the link for the correspondence in question, I get a .NET error page. * When I attempted to enter my quarterly filing numbers, I was asked to fill in the fields "UI gross wages", "UI taxable wages", and "UHI taxable wages", with no explanation on the form or anywhere else on the site of what these terms mean or how to determine the correct amounts. A DUA employee with whom I spoke today informed me that those words were supposed to be links that I could click on for definitions, but for some reason the links were missing from the page. * The two DUA employees with whom I spoke today both said that the new system is having innumerable problems across the board. * The first phone number I called today in an attempt to get help with QUEST was so swamped that I was not even given the option of waiting on hold — a recording told me they were too busy to help me and I should call back later, and then I was disconnected. * A little while ago I tried to click on the QUEST login link on the DUA Web page and instead reached a DUA Web site error page indicating that the page I was trying to access had moved or was temporarily unavailable, or some such thing. * Some time after that, I tried again, and this time I actually got into the QUEST application, at which point I was greeted with a different error: "Error: You have reached the Commonwealth of Massachusetts Department of Unemployment Assistance. The Quest Unemployment System is temporarily unavailable due to scheduled maintenance in order to better serve you. Please try your request again later. We appreciate your understanding." Given everything else that's going on, it seems highly unlikely to me that it is any way accurate to claim that this outage was "scheduled". * Earlier today, a new message showed up on the DUA Web site: *Additional Time for 4th Quarter Filing and Account Activation* Two-week grace period for filing 4th Quarter Employment and Wage Detail Report. New deadline: *February 16, 2010*. Penalties apply after deadline. ... Although the January 8th deadline has passed, you can still activate your account without a late penalty. Please activate your account as soon as possible to avoid the expected high volume of calls and Web traffic near the filing deadline. More. http://www.mass.gov/Elwd/docs/dua/quest/empl_%26_wage_detail_filing_1st_reminder.pdf As is typical in government bureaucracies facing epic disasters, there has been no public disclosure of the fact that there is a problem, or of what is being done to fix it, or of the ETA for when it will be fixed. It remains to be seen whether anything will be disclosed later, or whether any heads will roll at the DUA in recognition of this monumental cock-up. 1. Perhaps the system does not seem so convoluted to businesses, but it does to me, a "household employer" who is required to participate in it only because I've made the seemingly naive decision of attempting to abide by the law while employing a babysitter for six hours per week. 2. At least, requiring QUEST filing as of 1/1/2010 seems to have been their original plan. However, a letter sent to employers January 14 encourages the use QUEST for filing 4Q2009 reports, which would seem to imply that not using QUEST is in fact an option. If so, it's a difficult option to exercise, since all instructions and forms for filing on paper appear to have been removed from website, or at least cunningly hidden. <http://www.mass.gov/Elwd/docs/dua/quest/empl_%26_wage_detail_filing_1st_reminder.pdf>
The long URL tells the story nicely. Two downtown billboard video screens caused traffic to "jerk.. to a standstill" for 20 minutes, until Panno.ru removed the content. They claim it was the result of either "hooligan hackers" or "advertising competitors". [Thanks to Herb Lin and Steve Bellovin for this one. PGN] http://www.switched.com/2010/01/16/russian-commuters-treated-to-free-roadside-pornography/ Steve Bellovin has noted various sign-hacking events. http://www.foxnews.com/story/0,2933,484326,00.html (see RISKS-25.53) http://www.i-hacked.com/content/view/274/48/ (ADDCO) http://www.nytimes.com/2006/05/08/business/media/08sign.html ("Stephen Harper Eats Babies") and a very amusing official posted sign ("Do not take any risks.") http://www.woostercollective.com/2009/06/culture_jamming_on_the_london_tube.html RISKS has noted other cases of spoofed signs in the past, notably dating back to the 1984 Rose Bowl scoreboard (Caltech vs MIT). PGN]
As if we didn't have enough bad drivers out there ... To the dismay of safety advocates already worried about driver distraction, automakers and high-tech companies have found a new place to put sophisticated Internet-connected computers: the front seat. [Source: Ashlee Vance and Matt Richtel, *The New York Times*, 7 Jan 2010.] http://www.nytimes.com/2010/01/07/technology/07distracted.html
The title of this article gives you a strong clue as to its content. The Web page includes many readers' comments, so I won't try to capture the entire discussion — which should be very familiar to RISKS readers. John Markoff and Ashlee Vance, Fearing Hackers Who Leave No Trace, *The New York Times*, dated 19 Jan 2010 http://www.nytimes.com/2010/01/20/technology/20code.html
POSIX says support for ++ and — is "not required", but doesn't say how to deal with ++b and --b when they aren't supported. So we end up with $ bash -c 'b=5; echo $((--b)); echo $((--b))' 4 3 $ dash -c 'b=5; echo $((--b)); echo $((--b))' 5 5 --b is being parsed here as a double-negation! http://bugs.debian.org/508602
Source: http://www.washingtontimes.com/news/2010/jan/16/network-flaw-causes-scary-web-error/ 2010 Network flaw causes scary Web error A woman in Georgia using a Nokia phone connected to facebook.com, and found herself logged in to a stranger's account, without ever having been prompted to log in. She asked her mother & sister, both with the same model phone to try it, and both also ended up in the accounts of other unknown parties. They sent an e-mail from Facebook as evidence that what they described really happened. I want to emphasize that the error isn't specifically a Facebook problem, but an AT&T network issue. Facebook could fix the problem by using a secure connection. Excerpt: The glitch — the result of a routing problem at the family's wireless carrier, AT&T — revealed a little known security flaw... In each case, the Internet lost track of who was who, putting the women into the wrong accounts... It's not clear whether such episodes are rare or simply not reported... The women, who live together in East Point, Ga., outside Atlanta, had recently upgraded to the same model of phone and all used the same carrier, AT&T... AT&T spokesman Michael Coe said its wireless customers have landed in the wrong Facebook pages in "a limited number of instances" and that a network problem behind those episodes is being fixed. This is, of course, a serious problem. But it's not clear to me that there's any way for bad guys to intentionally exploit it. Steven J Klein, A+ and Apple Certified, Your Mac & PC Expert (248) YOUR-MAC
If you happen to be on Facebook today and spot a group that is called, "WE'RE AGAINST THE 4.99 A MONTH CHARGE FOR FACEBOOK FROM JUNE 30TH 2010,? be sure to keep away from it. If you don't - instead of finding a friendly group of people that are there to discuss ideas or similar interests, a user could potentially end up with loads of malware garbage on their computer. http://www.geek.com/articles/news/fraudulent-facebook-group-leads-to-malware-scam-20091229/
As you may already know, GSM phone conversations are encrypted with the 20+ years old A5/1 and A5/2 stream ciphers. The ciphers were repeatedly shown to be weak, but in absence of a publicly available decryption tools the GSM Association was able to claim that the attacks are not practical. Last December the completion of tables needed for breaking A5/1 was announced and now the GSM Association intends to speed up the transition to A5/3. This A5/3 block cipher is KASUMI, which is a modified version of the MISTY cryptosystem. Recently (2010-01-10) it was publicly shown that it is possible to derive the complete 128-bit key of the full KASUMI by using only 4 related keys, 2^26 data, 2^30 bytes of memory, and 2^32 time (two hours on a single PC). <http://eprint.iacr.org/2010/013.pdf> Authors of the attack note: neither our technique nor any other published attack can break MISTY in less than the 2^128 complexity of exhaustive search, which indicates that the changes made by the GSM Association in moving from MISTY to KASUMI resulted in a much weaker cryptosystem. Never attribute to malice that which can be adequately explained by stupidity.
As noted in the Bogleheads investing forum, the S&P 500 index plummeted 97.7 points or 8.53% in the last instant of trading on Monday, January 11th, 2010... as shown by Google Finance and other online charts. An actual 8.53% drop would of course have generated screaming headlines, but perfunctory Googling suggests that this glitch has escaped the notice of the financial press. The obvious RISK is that an investor might take action on erroneously reported information, especially when that information could be "confirmed" by more than one source. This particular glitch is obvious enough to make such a thing unlikely, but it does place into question the reliability of our financial reporting channels. Why does such a thing ever happen? How difficult is it to calculate the average of 500 numbers... and to omit reporting the result if any of them are missing? Here is a screenshot of the glitch as shown by Google Finance. The glitch was not limited to Google, however. http://img31.imageshack.us/img31/6914/sp8.png The arrow points to the plummet. The chart displays a dynamic readout when you point to places on the curve, and the circled number is the readout for the right end of the curve. Fortunately, all of the summary numbers are displayed correctly, showing that it was a gratifyingly dull day. Bogleheads discussion: Bogleheads link: http://www.bogleheads.org/forum/viewtopic.php?t=48592&mrr=1263297139
A good friend wanted to rent a trailer to haul heavy stuff about 1,000 miles. The website of a reputable company had a tool for matching vehicle towing capacity, trailer weights, and trailer cargo capacity. He found a trailer that just met all his requirements, and reserved the trailer online. Except it seemed a little too good to be true. A couple days before leaving, he dug deeper on that company's website. Under the specifications for that trailer, he found the trailer weight listed at 1,000 pounds higher! He called customer service. The first agent tried to convince him through some dubious logic that the extra weight would not be a problem. He called again to get a second agent, who confirmed an error in the Web tool, and promised to get it fixed. My friend rented a truck instead. If he had trusted the Web tool, or the first agent, he could have suffered a serious crash through overloading. Lessons: A trailer rental database error could have killed people. And some customer service agents are more trustworthy than others.
An Australian man has died after computer equipment fell on him as it was being unloaded from a truck according to a local paper... "It appears the man was helping others unload a large computer server from the back of a truck,'' ambulance clinical support officer Mark Lamb said. http://www.news.com.au/breaking-news/man-dies-after-being-crushed-by-compute rs-in-melbourne/story-e6frfku0-1225818578320 Darryl Smith, VK2TDS POBox 169 Ingleburn NSW 2565 Australia www.radio-active.net.au/blog/ - www.radio-active.net.au/web/tracking/
For many years I've been a member of an organization that has a website that has negligible risk, but requires a login for some purposes. The organization (let's call it XYZZY) has always used the members' surname as a password. On January 16th, I received the following e-mail (slightly altered to obscure the organization [and the sender! PGN]). Dear Mr. Coy, Due to website maintenance, the "member/guest only" sections of the XYZZY website will not be available until after Jan. 26. As part of this maintenance, we are increasing security measures. Passwords now must be at least five characters in length. Your current password does not meet this security requirement and you will be unable to log in. Please call XYZZY's Member Service Center at (800) 555-1212 from 8 a.m. to 6 p.m. EST or e-mail firstname.lastname@example.org to update your password. We apologize for this inconvenience. I. Mostly Clueless, Deputy Director/Web Manager Of course, I've sent e-mail requesting that they change my password. I'm anticipating that they will send my new password by email. [PGN says, not so Coyly, you should request a password of "Coyote" as in "Don Coyote", Or you could change your name. That would certainly increase your security! But they will probably change your NAME and PASSWORD for you. I remember the 1108 operating system password, which was also the same as your user name. If you attempted to change your password, as I recall it would tell you that your desired password change was already in use if it belonged to another user. Now that's what we mean by REAL security!]
http://www.darkreading.com/insiderthreat/security/vulnerabilities/showArticle.jhtml?articleID=222300408 Kelly Jackson Higgins, DarkReading, 11 Jan 2010 Yet another botnet has been shut down as of today as researchers joined forces with ISPs to cut communications to the prolific Lethic spamming botnet — a development that illustrates how botnet hunters increasingly are going on the offensive to stop cybercriminals, mainly by disrupting their valuable bot infrastructures. For the most part researchers monitor and study botnets with honeypots and other more passive methods. Then security vendors come up with malware signatures to help their customers scan for these threats. But some researchers are turning up the heat on the bad guys' botnet infrastructures by taking the lead in killing some botnets: Aside from last weekend's takedown by Neustar of Lethic, which is responsible for about 10 percent of all spam, FireEye last November helped shut down the MegaD botnet. And researchers at the University of California at Santa Barbara in May revealed they had taken the offensive strategy one step further by infiltrating the Torpig botnet, a bold and controversial move that stirred debate about just how far researchers should go to disrupt a botnet. Back in 2008 after two major ISPs halted traffic to malicious hosting provider McColo, spam worldwide dropped around 70 percent because McColo had been the main home to most botnet command and control (C&C) servers. But deploying more offensive tactics to stop botnets and bad guys is not so straightforward: Researchers walk a fine line as to how far they can go legally and ethically, and sometimes taking down a botnet actually backfires, either with the bad guys returning the favor with a denial-of-service (DoS) attack, or learning how to better evade investigators next time. There's the danger that getting inside a botnet will just give its operators more tools and insight into how to strengthen their operations; botnet operators are notorious for reinventing themselves with stealthier botnets and new forms of malware. [...]
http://archive.midrange.com/bpcs-l/201001/msg00012.html BPCS-L discussion group has found out about a Y2K+10 problem in Business Planning and Control System (BPCS) version 8.1.00 where Trusted Link Enterprise (TLE) version 3.2.01 substitutes 1910 for 2010 in Electronic Data Interchange (EDI). The vendor (Infor) knows about it, and is working on a fix.
Should be no surprise, given RISKS 25.89 and 25.90, but.... according to Cnet, there's reports of a glitch on Windows Mobile that some devices are putting the wrong date on incoming SMS messages - using 2016 rather than 2010. Microsoft has acknowledged the problem, but I haven't seen any reports of fixes. Source: http://news.cnet.com/8301-13860_3-10425455-56.html
"This [everything-begins-again-with-us] dating system — which reflects the habits of the imperial dynasties, isn't just a quaint local custom, its continued use is heading Taiwan toward its very own type of Y2K problem on 2011/1/1, when Taiwan's calendar reaches the age of 100 and has to jump to three-digit years, Taiwan will likely experience what I like to call the Y1C problem. (Yes, I know: I'm mixing systems in that C represents hundred in a system that uses M, not K, for 'thousand.' But that's the best I could come up with. I'm open to suggestions for catchy but correct names.)" North Korea too, the very same day. http://pcofftherails101.blogspot.com/2010/01/is-there-y1c-computer-glitch-in-taiwans.html http://pinyin.info/news/2006/taiwans-y1c-problem http://en.wikipedia.org/wiki/Y1C_Problem http://en.wikipedia.org/wiki/Minguo_calendar http://en.wikipedia.org/wiki/Juche#Calendar
Them Astray (Grady: Risks 25:89) Part of this problem can be caused by poor-quality data in the underlying map database used by the GPS. I found a similar error while reviewing a web page which has a link to Google Maps to give directions from Berkeley to the University of California's forestry camp in Plumas County. The printed map directed users to take a Forest Service road as the shortest route; the road is dirt and not suitable for passenger cars. I contacted Tele Atlas (the firm which supplies the basic road data used by Google Maps), and found that they did not know that the road was dirt. They have updated the database, which fixed the problem. But all of these incidents (remember the Stolpa family in 1993?) just point out that all the technology and maps in the world are no substitute for common sense...
While these traffic risks are not computer-related, they do help point out how hard it can be to get it right. So how difficult is it to construct a good road sign? 1) Snow can stick to signs. I recall driving near Penticton, British Columbia, Canada one night and being very thankful that I knew the road. The highway has some switchbacks as it descends into the Okanagan Valley from Keremeos. The turns are signed. They are very visible three seasons of the year. In snow, the signs can be barely visible and not readable at all. *I* knew to slow down. What about someone else? Heated signs anyone? 2) In the same area and in others, it can be very windy. I have seen signs mounted so that they turn in the wind. I would not have thought that necessary. I wonder if anyone has been injured by a sign that broke loose in the wind.
BKINTBRE.RVW 20091012 "Into the Breach", Michael J. Santarcangelo, 2008, 978-0-9816363-0-6 %A Michael J. Santarcangelo email@example.com %C New York, USA %D 2008 %G 978-0-9816363-0-6 0-9816363-0-6 %I Catalyst Media %O www.intothebreach.com %O http://www.amazon.com/exec/obidos/ASIN/0981636306/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0981636306/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0981636306/robsladesin03-20 %O Audience i+ Tech 1 Writing 2 (see revfaq.htm for explanation) %P 110 p. %T "Into the Breach" The introduction states that security (which seems to be limited to disclosure or breaches) is a "people" problem, and therefore requires social solutions. This addresses a common problem: security professionals, and even non-technical managers, concentrate on breaches in systems and thus miss the real heart of the matter: people. Although not overtly stated, part one seems to be related to the first stage in the Strategy to Protect Information, understanding information. Chapter one repeats the position that breaches are a human problem. Security awareness is promoted in chapter two. In chapter three an analogy is drawn between faddish security and crash dieting, noting that neither works. Chapter four addresses risk management. Part two suggests managing people. Chapter five outlines the aforementioned Strategy to Protect Information: understand your information assets, manage and communicate with your people, and optimize your processes and systems. Implementing this strategy is seen, in chapter six, as a five step process: learn the jobs, gather information, prioritize, plan, and communicate. Steps seem to be missing, such as dividing your data or systems into elements for the process. Guidance for planning is limited. Chapter seven suggests making a trial run with a pilot project, which is a good idea. Measurement of the success of the project is discussed in chapter eight. Part three deals with improvement. Chapter nine notes that the strategy benefits overall management, which is unsurprising, since it is basically a general management process. Costs of compliance with regulations or standards are also partially covered, as is mentioned in chapter ten, since a significant portion of the initial cost of compliance relies on the type of research and analysis demanded by the strategy. (However, a great deal of the content simply emphasizes the importance of compliance.) The advice about outsourcing, in chapter eleven, seems to be to audit the vendor. Chapter twelve closes off the book with an exhortation to act. Although generic, the strategy proposed is sound and likely useful. This slim volume would help a significant number of managers and security practitioners who are caught up in the latest security fad or device, to the detriment of actual business (and personnel) needs. copyright Robert M. Slade, 2009 BKINTBRE.RVW 20091012 firstname.lastname@example.org email@example.com firstname.lastname@example.org victoria.tc.ca/techrev/rms.htm blog.isc2.org/isc2_blog/slade/index.html http://blogs.securiteam.com/index.php/archives/author/p1/ http://twitter.com/NoticeBored http://twitter.com/rslade
Please report problems with the web pages to the maintainer