[SecurityRatty] tag: pipe

Mamma.com: Insider trading and XSS

Tue, 18 Nov 2008 06:55:00 +0000

Mamma.com's got issues other than Mark Cuban's insider trading allegations. As a point of reference for this conversation, Mamma.com is ranked 4064 on Alexa as of today.
I won't profess to following Mr. Cuban's public life and the occasional antics. Obviously, he's a colorful and popular figure; certainly in Dallas, if not nationally.
What follows is not a judgment of Mr. Cuban or his pending legal challenges. I'm sure the process will play itself out accordingly.
A quick summary and some reference material:
The SEC has filed insider trading charges against Mr. Cuban. "According to the SEC, Cuban dumped 600,000 shares, or all of his 6.3% stake, in the search engine Mamma.com (The Mother of All Search Engines), in June 2004 after learning about private financing that the company was proposing. By selling, he avoided losing $750,000, the SEC alleges."
The whole issue for Mr. Cuban was PIPE financing because it's "dilutive to existing shareholders’ stakes."
That's the long and the short of the current issue, and again, not my real interest here, with the exception of the bet I made with myself regarding the probable web application security posture of mamma.com.
All this talk about a popular site immediately sets off the little bell in my head (I hear it a lot).
"What's wrong with the site?" is always the first question I ask myself.

I was not disappointed.

Mamma.com exhibits the following issues:
1) XSS vulnerability in the utfout variable.

2) XSS vulnerability in the qtype variable.

3) XSS vulnerability in their Mammajobs site at the pid variable. This one's weirder still; if you drop an IFRAME in, it simply redirects to any URL you include in the IFRAME string.

4) The prospect of CSRF (rather pointless here given that its just a search engine, but but still defies best practices) appears likely given that mamma.com blindly accepts updates via GET and POST with no sign of a formkey (canary) in sight.

I figured it best to stop there, and have submitted all these to Copernic (the Momma parent company).
I am however truly disappointed that an enterprise as ambitious and motivated as Momma/Copernic seems to have thrown the baby out with the bath water when it comes to web application security.
With regard to Mark Cuban dumping his shares: maybe he was afraid of getting pwned. ;-) All kidding aside, it's a shame that the whimsical and pessimistic thoughts regarding web site security that bounce around in my head inevitably bear themselves out.

del.icio.us | digg | Submit to Slashdot

Interview with Paul Cannon, Mozy Software Engineer

Wed, 16 Jul 2008 11:00:49 +0000

Mozy Awesome Process
Sometimes people come up to me and say, “Paul, how is it that Mozy has created such an unrelenting output of Awesome?”

Today I have been authorized to share with you some of the unique facets of the Mozy Awesome Process that until now have been tightly controlled trade secrets of Mozy, Inc. It all starts with giant robots (virtually perpetual sources of raw Awesome). We attach them to special Awesome Siphons of our own design and pipe the yield directly into our engineers’ development workstations. Further, peripheral Awesome needs are farmed from old He-Man reruns, a roomful of ninjas wailing on electric guitars, and our captive Happy Fun Ball.

The crude Awesome is skillfully transformed by Mozy engineers into powerful software and hardware configurations, then carefully inspected and regulated according to a host of eldritch acronyms: SWAGs, PMQs, PRDs, and the ever-inspiring CFRRCs. Once a successful creation is stamped with the Seal of Acronymic Approval for Mozy (SAAM), it is subjected to final endorsement by the mystical, revered Mozy Leprecorn*. Finally, a highly trained team of Box Monks put the new Awesomery into place in the Mozy systems, where it becomes available to you, the user.

Our rigorous Awesome Enforcement Policies and Magical Oversight have brought us to what we believe is the most Awesome-efficient development process in the world of backup software.

Be safe,
Paul Cannon
Mozy Software Engineer

*Leprecorn (noun): a rare but phenomenal creature; half Unicorn, half Leprechaun, and all magical.

Visit Mozy now for a great reliable online backup service, I use it myself.

Vote for Mozy
Lifehacker is currently holding an online backup showdown. Show your love for Mozy. Vote now.

Can you hear me now?

Fri, 27 Jun 2008 06:56:10 +0000

Verizon released a very interesting Data Breach report that analyzes over 500 forensic reports on their system over a number of years. It is great work by Verizon to gather this data and to publish it. Of course a consultant I go into lots of companies where they could learn a lot just by being more open and talking through issues with peers in other companies. Would be great to see other companies follow Verizon's lead.

I suggest you read their report, and I would like to add a little color to their findings from the perspective of the swamp I spend most of my time in - Web services security. Granted it is just one report, but the data run counter to a lot of conventional security "wisdom":

Who is behind data breaches?

73% resulted from external sources
18% were caused by insiders
39% implicated business partners
30% involved multiple parties

The internal/external divide is pretty silly these days, as is companies' recanting "inside the firewall and outside the firewall", I spend most of time hooking things up together precisely _so_ they intereoperate remotely. The firewall is a speed bump at best. At any rate external sources is a primary concern in Web services security, because - hey look our Web service front end just made your Mainframe/As400/Unix DB/ CICS/whatever accessible remotely. This is great from a functionality standpoint, but the issue is that these back end systems were never designed with anything remotely resembling an Internet threat model. Additionally, the Verizon team's findings around business parties and multiple parties strikes at the heart of a number of popular misconceptions in Web services security - "well its just B2B and its behind a firewall."

How do breaches occur?

62% were attributed to a significant error

59% resulted from hacking and intrusions

31% incorporated malicious code

22% exploited a vulnerability
15% were due to physical threats

A couple of things to note here - malicious code in my opinion is likely to be the biggest problem in Web services security going forward. There is a large gap waiting to be exploited here. You have no control over the other end of the pipe plus a massive attack surface, the only thing lacking is the attacker's ability to find and exploit which I strongly suspect is just a matter of time. Wrt hacking an intrusions we have the remote, passive nature of web security to blame here in Web services world. Paraphrasing Jeff Williams, the problem is that an attacker can just try an attack if it doesn't work, try again, again, and so on. This partially because of the loosely coupled nature of the systems, but it is also because commonly used information security protocols have diverged from reality are modeled using an object-centric mentality, where you "own" the object you are protecting and can afford to put passive controls around.

What commonalities exist?

66% involved data the victim did not know was on the system
75% of breaches were not discovered by the victim
83% of attacks were not highly difficult
85% of breaches were the result of opportunistic attacks
87% were considered avoidable through reasonable controls

Many of the attacks against Web Services are not difficult, in my training class, we'll typically execute 8-10 different attacks in a two day period. But the big one from this list is the first one - the amazing amount of attack surface offered up by Web services. Brad Hill has done a good job articulating these issues in SOAP/XML/WS-*, but at an enterprise its even bigger than those standards - the thing is we use Web services to make stuff interoperate, to make stuff reusable, and to virtualize endpoints. Great stuff if what you want to do is decentralize your business, but this creates oceans of space for attackers to roam. When you look beyond the Visio and the IDE view of web services, and get to the runtime there is an amazing amount of detritus left behind by all these layers.

SQL injections compromise Balmar e-commerce site

Mon, 23 Jun 2008 18:07:43 +0000

Technorati Tag: Security Breach

Date Reported:
6/3/08

Organization:
Balmar Incorporated
Arts Education Partnership ("AEP")

Contractor/Consultant/Branch:
Unnamed hosting provider

Victims:
Online customers

Number Affected:
Unknown

Types of Data:
Names, addresses, telephone numbers, emails, and credit card information.

Breach Description:
Balmar Incorporated notified the Maryland State Attorney General of a breach that occurred sometime between April 4, 2008 and April 30, 2008, in which sensitive customer information was compromised through their ecommerce site.

Reference URL:
Maryland State Attorney General breach notification

Report Credit:
Maryland State Attorney General

Response:
From the online source cited above:

Balmar Incorporated ("Balmar") recently experienced a data security breach in its e-commerce site server.

Balmar has reason to believe that the personal information of seven (7) of its online customers who reside in the State of Maryland may have been accessed sometime between April 4, 2008 and April 30, 2008 without proper authorization.
[Evan] The sensitive information may have been accessed sometime during the 26 days listed above, but as you will read later on in the notification, the attack started as early as March 27th.

The personal information affected may include customer names, addresses, telephone numbers, emails, and credit card information.

Balmar has determined that at least one fraudulent credit card transaction has occurred as a result of this incident.
[Evan] This is likely confirmation that the sensitive information WAS accessed, not "may have been" as stated previously.

A full analysis of our e-commerce server logs revealed on March 27, 2008, an individual initiated several SQL-injections queries on the main page of our e-commerce website from an IP address in Viet Nam.
[Evan] I am pleased to read that Balmar had/has implemented enough logging to determine the type and source of the attack. I am curious to know why the e-commerce site was under attack from March 27th until as late as April 30th without detection? Either the Balmar e-commerce site was not protected by intrusion detection/prevention or information security personnel didn't know how to use intrusion detection/prevention. IDS/IPS is a must-have for e-commerce platforms in most circumstances. Part of using IDS/IPS is to review and investigate alerts ASAP.

Random queries were attempted over time through March 31st.

By March 31st, the individual had gathered enough information to pipe the queries to a search bot.

By April 4th, the search bot was able to access and transfer data from our e-commerce server to a web page.

Once discovered, Balmar immediately undertook the following actions:

Reported the incident to the Virginia State Police and the FBI;
Contacted the web page host to demand that the page be disabled;
Removed all credit card information from the affected area of our database and moved it to a secured area of the database that cannot be accessed by the method used during the incident;
Installed an additional database security solution to detect and prevent any future attempted security breaches;
Sent notice to affected customers by letter and e-mail

Balmar's investigation of this incident is ongoing.

We sincerely apologize to you for this situation and want to assure you that protecting the security and privacy of your information remains our top priority.
[Evan] This letter is signed by the President of Balmar, Bruce Seger. I respect a business leader that speaks (or writes) about information security issues. It demonstrates his/her ownership.

We have made and will continue to make significant investments in security software, systems, and procedures, and will remain vigilant in protecting you.

For more information, contact us by telephone at 1 (800) 265-2724 or by email at bseger@balmar.com.

Commentary:
Was this an e-commerce site running code that was susceptible to SQL injection attacks and no host or network intrusion detection/prevention?

Past Breaches:
Unknown

Tucson area Domino's Pizza customer information exposed

Wed, 18 Jun 2008 06:43:34 +0000

Technorati Tag: Security Breach

Date Reported:
6/18/08

Organization:
Domino's Pizza

Contractor/Consultant/Branch:
Unnamed former owner of 24 Tucson area locations

Victims:
Customers

Number Affected:
Unknown

Types of Data:
Names and credit card numbers

Breach Description:
Hundreds of credit card receipts dating back as many as five years were found "blowing in the wind" after a former owner of 24 Domino's Pizza stores in the Tucson, Arizona area was found to have been discarding boxes of old records near her home.

Reference URL:
KVOA Channel 4 News

Report Credit:
Tom McNamara, KVOA Channel 4 News

Response:
From the online source cited above:

Investigators found credit card numbers blowing in the wind for anyone to see.

These piles and papers strewn across the alley contain hundreds of old receipts from Domino's Pizza stores.

When we got a call about this, we went down to University Avenue and Euclid and saw these receipts were three, four, and even five years old.
[Evan] Is there any business reason to keep credit card receipts for this period of time? I suppose a case could be made that these should be kept for up to seven years for tax purposes.

We contacted the former owner of 24 Domino's Pizza stores in Tucson.
[Evan] This could have been a very risky breach in terms of overall potential impact considering the number of affected persons. 24 stores, x number of credit card transactions per year, and 5 years could add up to a pretty significant number.

She won't talk with us on-camera, but told us she'd been discarding boxes of old records near her home and somehow all those receipts got loose.
[Evan] Incidents like this tear me up. I very much doubt that this lady had any malicious intention behind her actions, but nonetheless her actions could have caused considerable inconvenience (and possible loss) to a number of individuals. I presume that she just didn't know any better.

We found Scott Brumage's name and credit card number on one of those receipts in the alley.

Tom McNamara asks him, "See that? Recognize that name? Recognize the number?" Scotts nods, "Uh huh."

Tom asks, "Well how'd you feel when we called you out of the blue and told you what we'd found? What went through your mind?"

"It was just kind of surreal at first because I like to think I can trust using my card [because of] the convenience and everything of course."

Scott was startled to see his name and card numbers on our screen.

He says he's ordered a lot of pizzas over the years and expects privacy and protection when he pays for his pepperoni pie.
[Evan] Is this an unreasonable expectation? Maybe it is an unreasonable expectation, given the current environment and considering the bigger picture (merchants, processors, banks, "the system", etc.). I don't think that it is an unreasonable requirement, but requirements, expectations and practices are not in alignment.

Scotts tells us, "I don't know. [I'm] just dumbfounded, other than they need to figure a better way of disposing."
[Evan] It is dumbfounding, isn't it. I often wonder what people are thinking when they do some of the things they do.

The Investigators contacted the Federal Trade Commission in Washington and they say thieves could potentially use discarded credit card numbers even if the card has expired. The numbers on the card in many cases are still the same.

They say there could be enough information on the receipt to help a thief reveal more information about you, such as your social security number.

It's small comfort for Scott. He says, "I'm hoping this is a one time only [situation]. They might have just lost a loyal customer."
[Evan] The impact to the victim is usually pretty clear and easy to quantify. The impact to the business (or organization) is not usually as easy to measure. In a competitive business like pizza sales, companies need to identify and communicate differentiators like ingredient quality, service, taste, price, location, etc. Maybe if customers viewed information security practices as an important differentiator, businesses would put more time and effort into securing information. Pipe dream?

In this case, the Investigators contacted Tucson Police and several officers came to collect the records we found and have them destroyed.

Commentary:
This breach reminds me of a recent discussion I had online with Benjamin Wright in the comments section of the "Cotton Traders confirms that their website was compromised" breach. He makes a very good argument regarding accountability in credit card breaches. My responses to him are included.

Past Breaches:
Unknown

Wee-Fi: Detroit Update, Home Network-Fi, Piggyback-Fi, PHL Free-Fi

Mon, 16 Jun 2008 07:21:48 +0000

The Detroit Free Press rounds up free and fee Wi-Fi efforts around it: The city and its suburban and exurban surroundings could use more broadband, but Wi-Fi has arrived only slowly as an option. It hasn't disappeared outright, and it's made inroads in some places. The project to unwire Oakland County is on hold as even though the county and cities secured pole rights for a firm to build service, that firm is still searching for capital. A county-wide network might be a better model, but the density is always the issue: mounting locations and assets coupled with homes passed and their median income.

GigaOm's Michael Wolf rounds up what other forms of networks are needed in a home beyond Wi-Fi: Ethernet, HomePlug, MoCA, HomePNA, Wireless HD, personal networks (Bluetooth), and automation controls. (My home is a very stupid home, thank you very much.)

He who steals my Wi-Fi steals hash: Mike Rogoway at the (Portland) Oregonian poses the question as to whether using a neighbor's unsecured Wi-Fi is borrowing, stealing, or nothing at all. I pipe in noting that more people are securing their networks. In my current office, where I've been three years, I spotted over a dozen networks when I arrived, most unsecured. Today, all the networks are secured (only some are small business networks), and many of the names have changed. The reasons? Better security wizards, widespread use of WPA, improved Wi-Fi network setup in Windows Vista and XP SP2, start of use of WPS, and general fear of security issues. Rogoway also runs through what the options for connectivity in Portland are as MetroFi is about to hit its network shutdown date.

Philadelphia's mixed free airport Wi-Fi: I somehow missed this story months ago, but PHL (Philadelphia's airport) is offering free Wi-Fi on the weekends to every one, and free Wi-Fi on the weekdays to college students. Students go to an information counter, show their valid student ID, and get an access code. This is a very neat idea. The airport is otherwise $8 for 24 hours or $40 per month, although it's part of much cheaper roaming plans from Boingo Wireless and iPass.

Google has your back against your ISP

Sun, 15 Jun 2008 20:06:15 +0000

Its been a while now since word got out that Comcast for sure and possibly other large ISPs were filtering and throttling traffic to their customers. Now Steve Musil over on C/Net is reporting on a report in the Register that Google will be releasing tools that they have developed which will allow users to monitor and identify this type of filtering by your broadband carrier. I am far from a Google fan boy, but I have to give Google a pat on the back for this one.

The ISPs have tried to stop the government from stepping in here and preventing them from limiting and filtering traffic like this. It is part of the whole net neutrality thing. The ISPs response is the government doesn't have to step in, the market will take care of itself. Yeah, just like the oil companies say about the price of gas.

Ultimately I think the ISPs know they are going to lose this fight. Their next play is to start charging you based upon how much bandwidth you use. We have already seen the noise around that one. It reminds me of my web hosting days. Some hosts charged you by the bandwidth you used per month. Others gave you unlimited bandwidth but put you on a crowded machine where you had to fight for CPU time and hooked that up to a small pipe that was saturated. So you did not pay for extra bandwidth, but you couldn't use any either. Bottom line after a long period of access being cheap and plentiful, the ISP game is back. You can pay them now or pay them later, but you will pay them.

Google has your back against your ISP

Sun, 15 Jun 2008 19:06:15 +0000

Cotton Traders confirms that their website was compromised

Wed, 11 Jun 2008 06:45:54 +0000

Technorati Tag: Security Breach

Date Reported:
6/10/08

Organization:
Cotton Traders Ltd.

Contractor/Consultant/Branch:
None

Victims:
Customers

Number Affected:
"thought to be up to 38,000"*

*Cotton Traders claims this figure is "widely inaccurate" but isn't supplying the correct figure

Types of Data:
"addresses and credit card details"

Breach Description:
"Clothing firm Cotton Traders has confirmed that customers’ addresses and credit card details were stolen during a hack on its website in January."

Reference URL:
BBC News
Information Age
CNET Networks (Silicon.com)
The Register

Report Credit:
BBC News and an informed reader of The Breach Blog

Response:
From the online sources cited above:

The credit card details of up to 38,000 customers of clothing firm Cotton Traders were stolen following a hack of its website

It was initially reported that 38,000 card details were stolen. Cotton Traders claim the number is "substantially less" but refuse to confirm the actual number.
[Evan] Why is Cotton Traders not disclosing the number of persons affected by the breach? I think they do more damage to their reputation by not appearing open and honest about the breach. I can't think of any significant risk in sharing this information.

The firm has not confirmed the size of the breach but it has acknowledged the site was attacked early this year.

Barclaycard was contacted as soon as it learned of the attack, and most cards were stopped in January

"Those involved were notified at the time and card replaced,"
[Evan] Really? In what manner were the people involved notified? Typically, when people are notified, they talk and/or share their experiences. BBC News reports about this breach ~5 months after the incident, so I wonder if people really were notified "at the time".

The payment industry's trade body said it was serious because hackers accessed details for "card not present" fraud

customer addresses were also stolen in the hack

a specialist police force was investigating the case

In a statement, Cotton Traders said all of its customers' credit card data was encrypted on the website
[Evan] Hmmm. How and where was the data encrypted? Due to the lack of disclosed details, we are left to speculate. I can tell you from my past experiences that encryption is typically used for data in transit (from the front-end web server to the client) and sometimes where data is at rest (stored in the database). It is not uncommon for data to flow unencrypted between the back-end (database) and front-end (web server). Let's assume that this was a well architected ecommerce platform (from an information security standpoint), and that data is encrypted between the front and back end components. The information still exists for a some amount of time on the front-end server in a non-encrypted state. If the front-end web server were compromised, it is completely conceivable that the information confidentiality was compromised. I am not even going to speculate where and how encryption keys could be managed, but obviously this is another critical component of the architecture.

Cotton Traders, a specialist clothing outfit founded by ex-England rugby stars Fran Cotton and Steve Smith, said the potential to misuse the data is low because the credit card information was encrypted.
[Evan] See my comments above. More information is required before a claim like the "potential to misuse the data is low" can be verified.

Earlier this year we identified a security issue. We immediately brought in industry security experts to resolve the problem.
[Evan] Who are the "industry security experts"?

"Cotton Traders have recently upgraded all security on their website which has been validated by leading Industry experts."

"We would like to reassure all our customers that their data is secure and that the Cotton Traders website meets all leading Industry security standards."

The exact method used to hack the Cotton Traders website is not known.

Cotton Traders warned that other major retailers would be vulnerable to the same attack saying its website has always met "leading security standards".
[Evan] How do you make a claim like this and not share?! If other major retailers "would be vulnerable to the same attack", then shouldn't they and the information security industry be notified ASAP? Maybe they/we have, but I don't think so. The fact that the bad guys share information so much better than us good guys has been an "industry vulnerability" that has existed for many years. This seems like another example of the communication barrier that still exists between "industry experts".

The firm has said customers worried about their cards should contact their card provider.

Security groups say the attack highlights the need for laws governing companies' response to breaches, as called for by silicon.com's Full Disclosure campaign.
[Evan] Unfortunately, we need laws to force organizations to do the right things that they should have been doing all along. If organizations were managed well globally, would we need laws like breach notification statutes, SOX, HIPAA. etc.? The chances of organizations being well managed globally is a pipe dream.

Commentary:
I don't know what irks me more about breaches like this, the breach itself or the poor response.

Past Breaches:
Unknown

Wireless: Using Light APs Across a WAN

Thu, 22 May 2008 13:45:54 +0000

I get asked this question a lot….. “Can we have our wireless controller at the central office and APs at the other offices?”

The answer to this is usually “yes and no”. I know, helpful, right?

The first thing we have to understand before answering is- is this a completely light AP solution, or is it ‘semi-light’. These are my terms and each manufacturer has their own verbiage they’ll use, but the concepts are the same.

In a completely light AP product, the controller has the brains, and the APs are dumb. For all practical purposes here, the APs are just radio antennas. They know nothing, and every packet is sent back through the controller for processing. Generally a fully light AP will not even have an IP address.

With a semi-light AP product, the controller does most of the work (usually anything routed or not local) and the APs have enough sense to process local traffic.

Scenario. Imagine a controller at a central office, connected to a light AP at another location (across the WAN). If it’s a completely light AP, it will send every bit of traffic over the WAN, to the controller. Not a great idea if you have medium-heavy wireless usage and a small WAN pipe. You’ll find you can quickly eat your bandwidth with your wireless traffic. If it’s a semi-light solution, the AP can process local traffic, for example a wireless user that wants to send a print job locally.

Processing local requests at the AP cuts down on the amount of traffic that has to traverse the WAN and is generally the way to go if you want a single central controller and remote APs.

If you decide you just have to run a completely light AP solution across the WAN, be sure your pipe is big enough and your usage low enough to support that configuration. Note that ‘big enough’ and ‘low enough’ are always relative and you’ll need to do a little experimenting to get the right threshold for your environment.

# # #