<![CDATA[[SecurityRatty] tag: prone]]> http://securityratty.com/tag/prone Sun, 15 Jun 2008 19:32:25 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[SSDs are hot, but come with security risks]]> http://securityratty.com/article/fee6f2f40d415eea06a4cd91630c0d92 http://securityratty.com/article/fee6f2f40d415eea06a4cd91630c0d92

]]> Fri, 22 Aug 2008 09:00:00 +0000 data security data traditional hard experts caution issues offer hacks prone SSDs are hot, but come with security risks <![CDATA[Zero-day Microsoft Windows NSlookup.exe Vulnerability Exploited In The Wild]]> http://securityratty.com/article/611a4500bae5305083aff35d9565bcf9 http://securityratty.com/article/611a4500bae5305083aff35d9565bcf9 Fri, 15 Aug 2008 19:07:46 +0000 microsoft windows execute arbitrary code wild nslookup exe attacks prone issue error Zero-day Microsoft Windows NSlookup.exe Vulnerability Exploited In The Wild <![CDATA[Email Hacking Going Commercial - Part Two]]> http://securityratty.com/article/403816e80242e85ea676f8d2be0684b6 http://securityratty.com/article/403816e80242e85ea676f8d2be0684b6 Malware authors seeking financial gains from releasing their trojans often promote them as Remote Access Tools, which if we exclude the built-in anti-sandboxing and antivirus software killing capabilities, could pass for a RAT. In a similar deceptive fashion, email hacking services are pitched as email password recovery services.

Hacking as a Service sites seems to be popping out like mushrooms these days, thanks primarily due to the fact that yesterday's script kiddies are today's entrepreneurs trying to even monetize the process of bruteforcing. Here's their pitch :

"Well.. There is nothing different in our services. Like other group, we simply crack email addresses , and provide you the current password used by the victim to you for a suitable price. Nothing unique that we can brag about....  We don't hack NASA or CIA , we cannot hack a bank and steal a million dollars.. We just crack email password .. AND WE DO A HECK OF A JOB IN IT !! We cannot be as presentable as the other groups, trying to look as formal and corporate, as if they are running a Major Corporate Office. However they present it...password retrieval, online investigation.. access recovery...blah blah blah..  the most simplest way to put it is.. : Email Password Cracking: !! And since everyone else is busy faking it, or trying to be more presentable, we utilize our skills to get you what you want.. i.e. THE EMAIL PASSWORD. No buttering up, no marketing skills..  plain hardcore hacking !! So, since you now know what we do , and want us to do the job for you, please proceed to the order page for your relevant TARGET EMAIL and submit your request. All said and done, we will get the elusive password & send you a couple of proofs. You decide upon the authenticity of the proofs, and let us know if you are comfortable going ahead with the payment. PAY US, AND YOU GET THE PASSWORD !And as they say......."

How much are they charging for the bruteforcing? $150 for starters, which is prone to increase due to their bla bla bla about how sophisticated it was to obtain the password - given they actually manage to deliver the goods : 

"Many groups charge a fixed price for an email cracking. We undertake more kinds of projects than anyone else. Frankly, each email is a different project in itself. We cannot charge you $100, for something which we can do for $50. Subsequently, we cannot charge you $100, for something which should be priced at $200. But we charge a minimum of $150 USD so that we end up taking orders from ONLY those who really need it. It is a small amount for the level of satisfaction, facts/truth and relief that you would ultimately achieve from this.It depends upon the nature of the job, the accessibility factor. and many other reasons likes:-

1- The email service provider
2- The target itself. How net-savvy he/she is.
3- Complexity of the password
4- Urgency of job and many other things collectively.

We will let you know our charges once we have the desired results only. Be assured, we wont charge you the moon. We charge only what we deserve, and is acceptable by you. Trust us !!"

Some of their answers to the frequently asked questions :

" - Who are you? Where are you from?
We are Hire2Hack Group. Member of our group are students in information technology, at some university in England, France, Italy, Japan, Australia, Canada, Brasilia and at United States of America.

- What services do you provide?
We can hack ANY EMAIL password for you very fast, reliable, secure and worldwide for a suitable price.

- Can you really hack password or just a making a shit scam?
Well, lot of people, lot of groups, companies do this service, but not guaranteed. This is only you can choose which group you want to Order. Be careful with these people. You can believe only on them who claims to provide proof before you really pay them.

- Is there any tool available to crack password?
Yes there is. And we are not giving it to you.

- How long does it takes to crack a password?
Each account is different and hacking time vary. On average, it might take about 1 to 3 days, but it may take anywhere from 24 hours to 30 days or more depending on how difficult is the hacking of each account.

- How can I believe you, that you got password?
We will provide you some good proofs before requesting you to pay us. The proof can be anything, you can decide what kind proof you need.

- Is there person will know that his/her email id has been cracked?
No, we provide you only the original password. That mean the current active password. Your victim/target will not realized that she/he has been hacked. NEVER, we said !

- How I will pay you, I do not have credit card or I do not want to give my credit card number on net?
Well, you can use international money transfer service such as Western Union (www.westernunion.com) or Money Gram (www.moneygram.com). These services immediate transfer money on same day or same hour. You can locate their agents in yours area from their website.

- Do I have to give you my password?
No. Any service which requires your password is simply trying to scam you out of access to your account.

- How will I know you really have the password?
We will show you the proofs.. which are mostly convincing.

- Since you have the password anyway, will you give it to me?
NO. Do not waste your time or ours. We will not release the password until full payment is made - no exceptions. We have had people request our service and once we recover the password, they reset the subject account then ask us for the original password so they can reset it back - the answer will be no. We have also had people ask if they could have the password since we've already recovered it and they cannot pay - the answer will be no. No password will be released until payment has been made in full - no exceptions.

- Will you recover more than one password? Can I request more than one email account?
Yes, but a separate request must be filled out for each one as you will only be billed for each successful recovery. If we have previously recovered a password for you and you have not paid, we will not begin any new request for you until your previous request is paid in full with exceptions for our established clientele. We charge at minimum US $100 for each account hacked.

- Do you reset or change the current password?
No. We do not try to guess the current password or the secret question's answer, we do not change their password. We give you only the Original password, which the victim is currently using.

- Is this confidential? Do you share my information with anyone else?
No, Not at all, Not in any case, its a trust between you and us. Your information will be respected as long as you abide by our Terms and Conditions and Privacy policy. We keep your personal records and requests confidential in our database but we respect your right to privacy and will not rent, share, sell, or trade any personal information unless required by law. But, if you engage in any spamming or fraudulent actives, Your information will be given to the appropriate authorities."

So you've got script kiddies cracking email addresses and probably engaging in the rest of the usual cybercrime activities, who are spam sensitive, and would expose their customers if they start spamming from the cracked emails? Now that's socially responsible, isn't it.

Targeted attacks are sexy, but bruteforcing email accounts no matter the number of proxies and wordlists that they have access to is so irrelevant, that social engineering a potential victim into infecting herself with malware through a live exploit URL seems to be the method of choice, next to a plain simple phishing email of course. In this case, what they're asking for in respect to the victim's details is the victim's country and victim's language, so that a localized social engineering or phishing attack can take place. However, this particular group seems to be using a standard bruteforcing tool.

One thing's for sure - cybercrime is getting easier to outsource, and with potential customers starting to have access to services they didn't a couple of years ago, fake scammers are also emerging in between the real ones.
]]> Fri, 08 Aug 2008 10:31:54 +0000 crack password crack crack email password email password password original password current password password retrieval email Email Hacking Going Commercial - Part Two <![CDATA[McAfee's Site Advisor Blocking n.runs AG - "for starters"]]> http://securityratty.com/article/980eb4d1bd34b658bcb6d139b3d762f1 http://securityratty.com/article/980eb4d1bd34b658bcb6d139b3d762f1 Following the recent, and now fixed false positive blocking sans.org due to the already considered malicious dshield.org and giac.org it's also interesting to note that n.runs AG (nruns.com), whose research into vulnerabilities in antivirus products received a lot of attention lately, is also flagged as a dangerous site.

Excluding the conspiracy theories, a false positive when your solution is integrated in the second most popular search engine is bad, especially when other automated crawling approaches are successfully detecting the site as a non-malicious one. How come? It's all a matter of how you define malicious activity, and what exactly are you trying to protect your users from.

In this case, Site Advisor seems to be trying to protect the end user from herself, but flagging sites hosting some sort of hacking/pen-testing tool in a clear directory structure, since SiteAdvisor isn't capable of automatically flagging a SQL injected site as a malicious one, the approach it takes for assessing whether or not a specific site is malicious is flawed, namely integrating McAfee's signatures based malware database and flagging a site hosting anything detected as malware as a badware site itself. McAfee's comments:

"Our tests are very accurate," Dowling said. "The frequency of false positives is fewer than one a month. Changes in classifications we make are almost always because sites have changed their behaviour. "The email tests are the ones than have the most false positives. Users can have confidence in our ratings."

There are even more surprising false positives, such as, Hack in the Box security conference, Defcon.org, Zone-H France, Invisiblethings.org, AME Info - Middle East business and financial news and more :
milw0rm.com
hackinthebox.org
defcon.org
hitb.org
invisiblethings.org
zone-h.fr
ussrback.com
ameinfo.com

Take for instance the Hack in the Box security conference, which is considered as the download publisher of a file hosted at packetstormsecurity.org. What's interesting to point out is that just like a huge percentage of already flagged as potentially harmful sites that haven't been re-checked in months, with Hack in the Box's case the link was last checked in February, 2008. And since hitb.org is now distributing spyware, any site that it links to is also flagged as badware, like hackinthebox.org itself :

"When we tested this site we found links to hitb.org, which we found to be a distributor of downloads some people consider adware, spyware or other potentially unwanted programs.'

These sites aren't SQL injected, IFRAME-ed or embedded with malware whatsoever, so it's like flagging a gun store as a malicious store because of the inventory there - wrong generalization aiming to bring order into the underground chaos at the first place is prone to result in lots of false positives, a wrong mentality that certain countries are starting to embrace.

The bottom line - is the "do not visit unknown or potentially harmful sites" security tip on the verge of extinction? Probably, as these days, exploited legitimate sites are hosting or redirecting to more malware than potentially harmful sites are.
]]> Mon, 04 Aug 2008 05:42:49 +0000 site site advisor org due org dangerous site specific site malicious harmful sites sites McAfee's Site Advisor Blocking n.runs AG - "for starters" <![CDATA[Are the Inmates Running the Jails in Maryland?]]> http://securityratty.com/article/7a0898f4cc7afa75149ce8450c4807bf http://securityratty.com/article/7a0898f4cc7afa75149ce8450c4807bf
The Post lists a number of correction officers who have been investigated, suspended and even jailed for wrong doings. One 13 year veteran was convicted on second degree assault after he beat a woman so badly that he broke her rib. That was not his first violent outburst however. In the late '90s his then wife had to get three protective orders issued against him.

In 2004, he pleaded guilty to breaking a woman's rib. The woman whose rib he broke was pregnant with his child. A judge put him on probation for that assault and ordered him to take anger management classes. The child that the woman was carrying was not so lucky. She miscarried days afer the beating.

The jail which incarcerates 1500 inmates, is said to be overcrowded by Government reports. The jail was built to hold 1330 inmates. One hundred and seventy extra inmates is hardly a serious "overcrowding" problem. The reported number of correction officers at 450, means that the ratio of imates to officers is not even 4:1. Compare that to a place like Riker's Island in New York City where the ratio of inmates to officers is probably closer to 25:1 and you will see that the officers in Maryland should not have many reasons to complain.

Of course, they should not have any reason to break the law either, but they do. Take the case of Renardo Humphrey, for instance. He was jailed this week after being convicted of armed robbery. Along with four others, he held up a couple of teenagers. Then there is Officer Kenneth Paul St. Clair, who joined the Department in 2004. This oxygen thief was convicted of second degree child abuse involving an 11 month old baby boy.

According to Police reports, the baby suffered multiple rib fractures, a skull fracture, internal bleeding, bruises on his face, chest, forehead and a bite mark on his shoulder. If I ever receive a call from a telemarketer tying to solicit money from me to support the fine upstanding members of the Prince George's Correction Department, I will make sure I tell him the story of the the little baby boy that was brutalized by one of his clients.

You may wonder why supervisors do not take more action and do not closely monitor the staff who apparently have a lot of anger management problems. Some Departments admitted that they only do background checks when officers are going for promotion. Therfore, if an officer is prone to beating up little babies and pregnant women, he just might go about his merry way without ever coming to notice - just so long as he does not seek promotion.

It would seem that all is not well with the Maryland Penal system. Perhaps a good overhaul is called for. It is not too much for society to expect that those who are entrusted with great authority do not abuse that authority. If they do and start behaving like those who have been removed from society, then they too should suffer the same fate.
Visit Sexton Executive Security at www.sextonsecurity.com
]]> Sat, 26 Jul 2008 00:29:00 +0000 officers correction officers maryland multiple rib fractures rib baby baby boy anger management classes anger management Are the Inmates Running the Jails in Maryland? <![CDATA[Are Stolen Credit Card Details Getting Cheaper?]]> http://securityratty.com/article/a67e13e215d163e122340bffab059502 http://securityratty.com/article/a67e13e215d163e122340bffab059502
What is shaping the prices of stolen credit card details? The investments the cybercriminals or real life scammers ( through credit card cloning or ATM skimming) put into the process of obtaining the details, or can we even talk about investments being made where an experienced scammer has just purchased 1GB of raw credit cards data from a novice botnet master who isn't really aware of the actual value of his "botnet output"?

Depends on which economic theory you believe in, or whether or not you'll take the "bottom-up approach" or the "top-down" one. And since I'm not aware of the existence of "the invisible hand of the underground market" and centralized power to increase the supply or decrease it to boost prices for the stolen credit card details, also indicating the existence of underground cartels putting everyone in a "price taker" position.

The basics of demand and supply for anything underground will always apply unless of course, The more they want, the cheaper it gets, the less they want, the higher the price on per credit card basis gets, since the investment on behalf of the malicious party that originally stolen them is virtually the same, and he can theoretically break-even in every single case since the credit card details were obtained efficiently. It's up to the seller to follow or entirely ignore economic behavior, and do what they feel like doing with this good which must on the other hand reach its market liquidity as soon as possible, else it becomes obsolete. The current market model can be further explained as a good example of competitive equilibrium :

"Competitive market equilibrium is the traditional concept of economic equilibrium, appropriate for the analysis of commodity markets with flexible prices and many traders, and serving as the benchmark of efficiency in economic analysis. It relies crucially on the assumption of a competitive environment where each trader decides upon a quantity that is so small compared to the total quantity traded in the market that their individual transactions have no influence on the prices."

This can be easily explained in a single sentence - it's a mess and every participant is doing whatever they want to, so generalizing on the prices charged for stolen credit card numbers would be unrealistic, since it's the price a single seller with no real impact on the "average" market price for the same good. As for the average market price itself, it would be hard to measure it depending on the quality of the sample you want to rely on, since this is a type of market where sellers don't have to report price changes in their goods for the purpose of statistical research.

A recently released report by Finjan, with whom I've been on the same page of several high profile incidents so far, touches this very same topic :

"Prices charged by cybercriminals selling hacked bank and credit card details have fallen sharply as the volume of data on offer has soared, forcing them to look elsewhere to boost profit margins, a new report says. Researchers for Finjan, a Web security firm, said the high volumes traded had led to bank and credit card information becoming "commoditized" - account details with PIN codes that once fetched $100 or more each might now go for $10 or $20. In its latest quarterly survey of Web trends, the California-based company said cybercrime had evolved into "a major shadow economy ruled by business rules and logic that closely mimics the legitimate business world."

Excluding the presence of price discrimination for a while, as well as open topic offers in the lines of "how much for X amount of Y?" answered as "how much are you willing to pay?", it's all a matter of the seller in a particular situation.

Furthermore, in real-life market there's always the scarcity problem, however, in the underground market there's no shortage of resources despite the ever growing wants of the buyers. Generalizing even more, take for instance the butterfly effect of a price change in petrol, and result of which is inevitable increase of prices in every single aspect of your life, but in the underground market mostly due to the malicious economies of scale achieved, a price increase in renting a botnet would have no effect in the prices charged for the stolen credit card details obtained through the infected hosts. How come? Basically, the price and resources for malware infection are prone to decrease, if we take a malware infected host as a static foundation for the basis of any upcoming cybercrime activities using it.

Perhaps the most disturbing part is that the market for stolen credit card details is so mature, and its entry barriers so low these days, that the confidential data that cannot be efficiently obtained through real-life means like credit card cloning or ATM skimming on a large scale, is now purchased online for the purpose of abusing it in real-life by embedding the valid information into plastic cards.
]]> Tue, 15 Jul 2008 11:36:12 +0000 price average market price market price credit card credit card details details market competitive market equilibrium credit card basis Are Stolen Credit Card Details Getting Cheaper? <![CDATA[Cloudsecurity.org Interviews Guido van Rossum: Google App Engine, Python and Security]]> http://securityratty.com/article/a2cf6f2181968ed75532873c1bdb09fe http://securityratty.com/article/a2cf6f2181968ed75532873c1bdb09fe Guido Homepage

In this interview, cloudsecurity.org talks to Guido van Rossum about Python, Google App Engine and security.

Guido is the creator of the Python programming language and more recently, Google App Engine team member.  His involvement with the App Engine project was pretty late - the code “was almost ready for release” when he get involved.  The security architect of App Engine was primarily project lead, Kevin Gibbs, supported by the rest of the App Engine crew and the Google Security Team.

The Interview

cloudsecurity.org: What security principles did you follow for App Engine?

GvR: While I can’t share any specifics on what we’re doing to secure App Engine, I can say that the main principle we’ve followed could be called “defense in depth”. We’re not relying exclusively on a secure interpreter, or any other single security layer, to protect our users.

cloudsecurity.org: Please provide some examples of how those principles played out in terms of the current implementation?

GvR: Sorry, we don’t divulge such information.

cloudsecurity.org: What criteria did you apply to Python module selection?

GvR: We first looked for modules that were useful and straightforward to audit. If a module was large or complex, we’d only audit it (fixing things we found) if it was deemed essential or at least useful for a large number of users; otherwise we’d exclude it.

cloudsecurity.org: What do you see as the security risks inherent in exposing an interpreter runtime in a shared environment?

GvR: I presume you’re asking about risks to users, like providing accidental access to data belonging to another app. We’ve taken extensive measures to isolate different apps from each other. For example, each app runs in a separate process, and the datastore prevents an app from accessing data belonging to other apps.

cloudsecurity.org: I recently attended a fascinating talk by Justin Ferguson (a Seattle based security consultant) at eusecwest in London.  He gave a great talk exploring security vulnerabilities in language interpreters and specifically highlighted some security weaknesses in Python App Engine.  What are your thoughts on his research and specifically the Python issues he highlighted?  When do you anticipate they will get fixed?

GvR: We’ve anticipated all of the possibilities raised in Justin’s talk, and took measures to protect our users. Justin highlighted weaknesses in Python, but not in App Engine. Furthermore, our security model does not rely solely upon protections within the Python interpreter; there are additional protections that these external analyses have missed.

cloudsecurity.org: How do you contain an attacker that exploits bugs in App Engine from exploiting the underlying OS and potentially interfering with other users processes or attacking backend systems?

GvR: You are correct that there are strong measures in place, but I’m not at liberty to discuss details.

cloudsecurity.org: Python was the first language to get the App Engine treatment, what language is next and what are some of the language specific security challenges the team has had to deal with?

GvR: Although I can’t comment on what language is next, we are working on this, and have gotten a lot of great feedback from our developers. As far as language-specific security challenges, they stemmed mostly from the complexity of the Python interpreter. We spent a lot of time auditing this, and did a great deal more than just identifying buffer overflows.  I can also add that Google is actively researching the security of interpreted languages.  Google engineers routinely contribute security fixes to open source projects, including but not limited to Python.

cloudsecurity.org: How does the team decide when ‘enough is enough’ in terms of hardening the interpreter?

GvR: That’s not really how we approach it. We realize that security is an ongoing effort, and try to stay ahead of threats through continuous monitoring and testing.

cloudsecurity.org: Some commentators have suggested that perhaps the difficulty of auditing the implementation led to some modules being more heavily restricted than perhaps necessary.  What are your thoughts on that and what plans, if any, are there to bring back code objects/functions that were eliminated in the initial release?  (with the benefit of hindsight).

GvR: The only thing we are likely to put back is the _ast module, which was not audited based upon an underestimation of its usefulness (see my answer to question #3 above).  We will also put back some dummy functions and other objects whose absence currently prevents some popular frameworks from being loaded without modifications. For example, some harmless functionality in the imp module will come back. We’re also looking into making urllib2 work (to some extent), though that’s not really a security issue but merely a matter of API adjustment.

cloudsecurity.org: It is reported that Google encourages small groups to go off and create.  How involved were the Google security team with App Engine in terms of design and implementation review/testing?  Given the dynamics, is it possible to have a meaningful security process that shadows the development process?

GvR: The Google Security team is involved in everything we do. They have been extremely helpful.

cloudsecurity.org: How can people report security weaknesses they discover in App Engine?  What commitment does Google give in terms of dealing vulnerability reports?

GvR: There is a standard process for submitting security issues. See http://www.google.com/corporate/security.html. Google moves very fast to protect its users when a verifiable security vulnerability is reported.

cloudsecurity.org: One concern is the potential misuse of App Engine to exploit security vulnerabilities in visitors browsers.  This is not a new problem per se, shared hosting providers know all about this.  But with Google and other Cloud providers, the scalability potential is much higher.  What are your thoughts on this and what pro-active steps is Google taking to detect and terminate evil apps?

GvR: This is high on our list of concerns. We deal with this through a combination of restrictions on what you can do (e.g. certain HTTP headers and ports are off-limits) and, again, monitoring.

cloudsecurity.org: Beyond App Engine, what role do you think Python will play in the Cloud both now and in the future?

GvR: Sorry, I’m not prone to philosophizing about the future.

cloudsecurity.org: Trust is often cited as a barrier to enterprise adoption of Cloud Computing.  What role do you personally think Google can play in building that trust?

GvR: I think trust is built up over a long period of experience. Our actions in terms of being open to our users will be the most important factor in establishing trust. Of course, Google’s reputation also helps: everybody understands that Google doesn’t want its name associated with a bad product.

cloudsecurity.org: Looking at the Cloud Computing landscape beyond Google, what are your thoughts on the current state of Cloud Computing and Security?

GvR: It’s obvious that Cloud Computing is only just taking off. The next few years will be very exciting.

cloudsecurity.org: Lastly, what are some of your favourite App Engine apps?

GvR: There are too many to enumerate. If you insist on a highlight, well, I like Rietveld (http://codereview.appspot.com), a tool for collaborative code review which I (largely) wrote myself. It is open source and includes some essential components from Mondrian, a similar internal tool which I created before I joined the App Engine team.

Thanks

My thanks to Guido for his time and sharing his views.

]]> Tue, 01 Jul 2008 15:03:10 +0000 app engine google app engine app app engine treatment security app engine project app engine crew secure app engine security vulnerabilities Cloudsecurity.org Interviews Guido van Rossum: Google App Engine, Python and Security <![CDATA[Decrypting and Restoring GPcode Encrypted Files]]> http://securityratty.com/article/e39ad499bbe55c20aca17c7ba23989b4 http://securityratty.com/article/e39ad499bbe55c20aca17c7ba23989b4
The futile attempt to directly attack the encryption algorithm used by the GPcode ransomware, is prompting Kaspersky Labs to invest in a more pragmatic solutions to the problem, with a new version of the StopGpcode tool released last week. More info :

"It turns out that if a user has files that are encrypted by Gpcode and versions of those same files that are unencrypted, then the pairs of files (the encrypted and corresponding unencrypted file) can be used to restore other files on the victim machine. This is the method that the StopGpcode2 tool uses.

Where can these unencrypted files be found? They may be the result of using PhotoRec. Moreover, these files may be found in a backup storage or on removable media (e.g., the original files of photographs copied to the hard disk of a computer that has been attacked by Gpcode may still be on a camera’s memory card). Unencrypted files may also have been saved somewhere on a network resource (e.g., films or video clips on a public server) that the Gpcode virus has not reached."

As the customer support desk behind GPcode pointed out in an interview, the malware is prone to evolve, and the simplistic file deletion process will be replaced by secure file deletion in order to render all data recovery tols useless, unless of course backups of the affected data are available. They often aren't, and depending on the importance of the files encrypted, the successful ransom is all a matter of the momentum.

"A person, presumably the author of Gpcode, contacted at one of the e-mail addresses left behind by the program stated that future development efforts will likely increase the key size to 4,096 bits, "if AV companies or other (people) crack the current key, but (that's) impossible. The self-proclaimed author, who used the name "Daniel Robertson," also said that other standard techniques to defeat antivirus will be added, including polymorphic encryption, anti-heuristic features and the ability to self propagate, turning the program into a computer virus. It well pays back itself," he said"

There are even more pragmatic approaches to dealing with this problem, next to backups undermining their business model. Try following the virtual money for instance.
]]> Tue, 01 Jul 2008 04:26:39 +0000 files gpcode original files gpcode virus gpcode ransomware file secure file deletion computer virus key Decrypting and Restoring GPcode Encrypted Files <![CDATA[Visit the New SDL (Security Development Lifecycle) Web Site]]> http://securityratty.com/article/5158bd712f2f52104c2f58be02341162 http://securityratty.com/article/5158bd712f2f52104c2f58be02341162 sdl-site

I wanted to mention to folks that a new Security Development Lifecycle (SDL) web site went up earlier this month on microsoft.com.  Amazingly, you can navigate to it via http://www.microsoft.com/sdl, instead of some long name you'd never remember.

Of course, once you navigate to that URL, you get redirected to a long url that you'll never remember that is on the MSDN subsite, which is encouraging when you think about it.

I have it on reasonably good authority (aka the site owner), that there are plans for the site content to grow this year and that this will be one of the main starting points to learn more about Microsoft efforts to improve developer's ability to write code that is less prone to security problems.

While I'm on this topic, I may as well provide some other pointers to related content, lifted from the SDL Home page:

Considering the large amount of customer software that is developed in-house at large companies, I think SDL-like processes are becoming a critical need beyond vendor-developed software.  If your company hasn't started this process already, these resource might provide a good starting point.

Regards ~ Jeff

Share this post :
]]> Thu, 19 Jun 2008 20:08:18 +0000 sdl sdl tools repository sdl process guidance sdl home page security security development lifecycle sdl-like processes web site process Visit the New SDL (Security Development Lifecycle) Web Site <![CDATA[Sensitive Columbia University student information exposed for 16 months]]> http://securityratty.com/article/23f3cad1ddf4eede3bc3b1874ca1dcf4 http://securityratty.com/article/23f3cad1ddf4eede3bc3b1874ca1dcf4 Security Breach

Date Reported:
6/12/08

Organization:
Columbia University

Contractor/Consultant/Branch:
None

Victims:
Current and former students

Number Affected:
5,000

Types of Data:
Housing information including Social Security numbers

Breach Description:
"On June 3, Columbia University's Housing and Dining department was informed that one archival database file containing the housing information of approximately 5,000 current and former undergraduate students was found on a Google-hosted website."

Reference URL:
New York, The Sun
The BWOG
Columbia Housing & Dining SSN Security Breach petition

Report Credit:
The BWOG

Response:
From the online sources cited above:

On June 3, Columbia University's Housing and Dining department was informed that one archival database file containing the housing information of approximately 5,000 current and former undergraduate students was found on a Google-hosted website.
[Evan] Columbia University was informed by an alumna.  The URL for the information was code.google.com/p/cu-super-hw2/downloads/list.  To see how the page looked on 5/23/08, see here (this is a cached site that does not allow for any disclosure of information, and may not be available for long).

Google removed this file, at our request, that same day.
[Evan] Some students reported that some of the personal information was available in cached indexes for some time.

Columbia Public Safety investigators have concluded that this security breach was unintentional.

No financial data was included in the file in question, and we have no evidence of wrongdoing or identity theft.

It appears that the file was inadvertently posted by a former student employee in February 2007.
[Evan] The question people are asking is why did a student have access to such sensitive information and what kind of training was provided for handling confidential information.  Obviously mistakes are much more common in situations where people are not well trained.

Columbia would not identify the student, saying only that the person had worked in the university's housing office.

it is important for you to be aware that your name and Social Security Number were included in the file.

We are very sorry for this occurrence.

Columbia University is continually strengthening its measures to protect Social Security Numbers where they are required in our systems.

Housing & Dining manually eliminated Social Security Numbers from its online room
selection process and contracts in April 2007.
[Evan] This was a good move in my opinion.  Social Security numbers shouldn't be required for housing selection at college.

Further, in spring 2008, Columbia Housing and Dining implemented a new software system to manage and improve the housing assignment, contract, and billing processes which also does not use Social Security Numbers.
[Evan] Another good move.  Automated processes are much less error prone.

Columbia has arranged for you to receive a free two-year subscription to a credit monitoring service

We sincerely apologize for the inconvenience this has caused you.

If you should have any questions or comments, please contact us by calling 1(888) 882-7331 or by emailing studentservices-assist@columbia.edu (mailto:studentservices-assist@columbia.edu).

Several students yesterday created an online petition and posted it to the main campus Web log, demanding that the university investigate the former employee and issue a report explaining how security will be increased.
[Evan] The petition site is located at this URL: www.petitiononline.com/breach/petition.html

style="font-weight: bold;">Commentary:
The cause of this breach seems obvious.  It seems that a poorly trained, part-time student-employee posted confidential information online and probably gave little thought to any potential security implications.  Poorly trained, part-time employees will probably make more mistakes than well trained, full-time employees.  Makes sense.  It's probably not a good idea to allow poorly trained, part-time employees to handle sensitive information.

I am glad to read that Columbia University Housing & Dining services no longer uses Social Security numbers in "online room selection process and contracts" or "housing assignment, contract, and billing processes".

I suggest that readers take a look at the comments on The BWOG article.

Past Breaches:
April, 2007 - "three databases containing students' addresses and Social Security numbers were online" according the The Sun story (referenced above)

]]> Sun, 15 Jun 2008 19:32:25 +0000 columbia information university evan columbia university evan security protect social security personal information columbia university Sensitive Columbia University student information exposed for 16 months