Spliced feed for Security Bloggers Network |
Long holiday weekend [StillSecure, After All These Years] Posted: 23 May 2008 07:47 AM CDT I am really looking forward to a long holiday weekend with the family. We are driving up to Orlando to stop in Disney World and SeaWorld. Going to check out the new water park they opened there called Aquatica. It has water rides unlike any we have ever seen. A day there and two days at Disney should have the kids in a great mood. Lets see what kind of mood it leaves me in. Waiting on long lines in the sweltering heat is not a lot of fun, plus I can only imagine what it is going to cost to fill up the gas tank to drive up there! Anyway, won't be much blogging going on this weekend. |
A Chronology of Data Breaches [/dev/random] [Belgian Security Blognetwork] Posted: 23 May 2008 01:50 AM CDT After the Bank of Ireland, the Ulster Bank also loose notebooks with customers information. Data breach becomes more and more an issue today: As all our personal data are stored in electronic form, it’s easy for employers to take data away to work at home or attend external meetings with their laptops. This should be totally prohibited!. It has been proven that even encrypted laptops are not secure! If access to company data must be performed for a good reason, set up a remote access (VPN) with strong encryption and access rights. On privacyrights.org, there is a huge list of reported data breaches (updated weekly). This reference can be useful when you need to present a project to a board of managers not security aware: “Take the right countermeasures to never come on this list!”. |
Let the Airlines Die (please, I beg you) [The Falcon's View] Posted: 22 May 2008 10:12 PM CDT |
Brief Thoughts on American Idol [The Falcon's View] Posted: 22 May 2008 10:01 PM CDT |
Game Theory of Malware article online. [NP-Incomplete] Posted: 22 May 2008 08:59 PM CDT I wrote an article on the game theory of emergent threats that is now online. It is based on presentations from earlier this year. You can grab the article here. As a sidenote, Amrit thinks that security people like to talk about game theory because they like to play video games. I of course strongly disagree. I will have you know the only video game I still like to play is portfolio explosion on e-trade. |
Sophos feeds Tim Greene a line of bull on virtual NAC [StillSecure, After All These Years] Posted: 22 May 2008 08:35 PM CDT I saw Tim Greene's column this morning entitled "Sophos NAC client adapts to virtual environments" and was curious to see if Sophos had taken a similar tact to what we did here at StillSecure in securing multiple virtual machines on the same physical machine. After reading the article though I have to say that Richard Jacobs, CTO of Sophos fed Tim Greene a line of bull. First of all lets start with the obvious. Sophos whole solution around virtual environments and NAC is nothing more than vaporware! Here is how the article leaves off in discussing this "solution" that Jacobs talks about, "Jacobs says the company doesn't have a name yet for this enforcement agent, nor does it have a date when it will become available as a product. Stay tuned." So what exactly are we talking about? Beyond that though, a closer examination of what Jacobs says is the obstacle in providing NAC to virtual environments is bull. Jacobs says the problem is "that in virtual environments, a physical machine that hosts virtual machines already has access to the network". Therefore according to Jacobs, "The switch port that the host machine connects to cannot be used as a NAC policy enforcement point because the host machine's status would determine the NAC policy for itself and for all the virtual machines running on it." He continues with, "That single policy would then have to apply to all the virtual machines running on the host, regardless of the status of the individual virtual machines, he says. A non-compliant virtual machine that tries to come onto the network could change the NAC status of the host, and enforcing that new status would block all the other virtual machines, even if they are compliant." Maybe what Jacobs should have said was that if your NAC is so limited that it will only work by allowing one device on per port with no ability to distinguish devices, OSs, etc beyond that rudimentary one-to-one equation, you are stuck waiting for Sophos to develop something that may work, who knows when. What about the case where someone plugs a computer into the back of a VOIP phone. They are both going through one port on the switch. Does that mean Sophos can't handle that either? That is trouble if you are a Sophos customer. But there is a better way! What about if you have the ability to distinguish access to the network based upon MAC address? My understanding is that each virtual OS in a virtual environment will have its own unique MAC address. So if you are going to assign policy, test and quarantine based upon multiple factors such as IP, domain, MAC address, netbios, etc, you do have the capability to test and allow one OS, while denying another OS, all while they are running on the same physical machine. In fact that is just what we do with Safe Access! I have seen it in action here at our offices in Colorado myself. If you log on with a Macintosh you get checked as a Mac and are allowed on or not depending if you passed the assigned policy test. When you fire up Windows on that Mac, you are tested again and can be denied access, while your Mac is allowed on. Vice versa, you can get on the network with your Window virtual OS, even though your Mac OS was denied, all mind you while you are running on a Macintosh physical box. The moral of the story is don't underestimate that someone else has a better mousetrap than you do. Also, if you are going to go spout off thinking everyone is as limited as you are, at least have the goods and don't be pushing vaporware! |
The VTM & JimTV hack, how did they do it. [Security4all] [Belgian Security Blognetwork] Posted: 22 May 2008 07:50 PM CDT |
This May Be FUD [Emergent Chaos] Posted: 22 May 2008 07:49 PM CDT You may have seen this article from the India Times, "Govt may get keys to your BlackBerry mailbox soon." Many people have been commenting on it, and the hand-wringing should build up to a good storm in a few days. The gist of the article is that the Indian Government has told RIM that if they can't read BlackBerry email, they might just ban all BlackBerries from India, and that RIM is caving. Being the sort of person I am, I called someone who actually knows something. I can't tell you anything more, precisely because they actually know something. What I was told is that this is complete FUD and false. The BlackBerry crypto is real crypto, just like SSL, PGP, S/MIME or anything else. The keys are generated on the handsets and on the BES server. There is end-to-end crypto, using real protocols like SPEKE. RIM doesn't have the keys to give. RIM cannot give the keys over because only the devices have them. Of course, as is true in all hatchet jobs, the lead is with weasel-words: In a major change of stance, Canada-based Research In Motion (RIM) may allow the Indian government to intercept non-corporate emails sent over BlackBerrys. See that? It's the word may. Here's my own text, which I know may be true because I just may have made it up: In a major cryptographic breakthrough, Canada-based Research In Motion (RIM) may soon put quantum cryptography in all new handsets, preventing any interceptions, because it's well, you know, quantum, and quantum is cool. Or this: In a major scientific advancement, Canada-based Research In Motion (RIM) may have accepted an order for 10 million BlackBerrys from space aliens living on Epsilon Erandi. A faster-than-light (FTL) email relay server may be installed at Barnard's Star as part of this groundbreaking, er, space-breaking agreement. And even: In a major economic development, Canada-based Research In Motion (RIM) may have purchased the Large Hadron Collider from CERN. According to officials close to the development, Canadian High Commissioner David Malone may have approved the deal not merely despite, but actually because of the chance that the LHC could create a small black hole that would devour all of France. "Canada is just fed up with the pointy-lips in France making fun of their accents and may have decided to take proactive action. Details on this one will be provided in two or three weeks," sources close to the deal may have told Emergent Chaos. No comment was available from the United Nations at posting time. May, while a merry month, may also be the tool of liars. RIM, I know you're reading this, not only because we are one of the top 25 blogs, and not at all because we speak for the President of the United States, but because Adam used to live in Montréal and is no pointy-lips. Please, please give us a definitive statement. You have to call bullshit on this sort of thing before it becomes destructive. I know and you know that there would be no better publicity for you than to call their bluff and say, "D'accord, pas des mûres pour vous." We would all cheer. BlackBerry sales will soar. |
Brain Rules, The presentationzen slides [Security4all] [Belgian Security Blognetwork] Posted: 22 May 2008 07:36 PM CDT |
Posted: 22 May 2008 06:47 PM CDT Earlier this week we had an internal presentation on Attacking ActiveX Controls. The main reason we had it is because of the ridiculously high hit rate we have whenever we look at controls with a slight security bent.. When building the presentation i dug up an old advisory we never publicly released (obviously we reported it to the vendor who (kinda) promptly fixed the bug (without giving us any credit at all, but hey.. )) While the IEBlog promises updates to IE8 that will minimize the damage caused by owned controls in the future, the fundamental problems with ActiveX today are an attackers dream.
The Background: The Juniper SSL-VPN products make use of an ActiveX Control on the client-side. Previously bugs had been found in the control by eEye and had been subsequently fixed by Juniper. This was a pretty garden variety stack smash and it would appear that Juniper did the right thing and hunted down other instances of these bugs within the control. The Bug(s): The ActiveX control included the functionality to upgrade itself if the server informed it of a new software version. By simply instantiating the control and passing it a high build number and a URL path to a downloadable file, we could cause the client to download our (possibly malicious) file. (click here to enlarge) This was a pretty obvious attack though, and the Control first checked the downloaded file to see if it was signed by Juniper. If it wasnt, then the file was not executed. Drat! The kicker though.. was that this file was not deleted, and was always downloaded to a predictable spot. (C:\predictable_location) Interlude: Now.. the usual attack vectors dont really come through for us.. We cant over-write anything important with this file and simply filling the disk seems pointless. Bug (Continues): When instantiating the control, one of the parameters we can pass is the path to the control's .ini configuration file: (click to enlarge) Now.. We can drop an arb file to the victims machine && we can instantiate the control using any well formed config file on his machine.. hmmm.. Now, in case you dont see it, the config file above has the winning line: UninstallString="calc.exe &&" So.. the writing is on the wall and the full process is this:
Ok.. so the simple deal is.. that much like the eEye find, client visits page and client gets arb. code executed on his machine, but (and this was the point of this whole rant) bugs like this have always been considered "less sexy" than stack smashes. Whats far more important for me however, is that even if our static analysis tools get to the state where they match their marketing hype, they will never find a bug like this.. There are some things that computers are good at, and some things that humans are.. and just because we want this to be a problem thats solvable with technology doesnt mean that the technology to do it will ever exist. This obviously does not mean that such tools are useless, just that they will never be a silver bullet, and that its still difficult to beat a trained set of eyes with high criminal energy.. /mh |
VMMA ITpeople need to read more online news [belsec] [Belgian Security Blognetwork] Posted: 22 May 2008 05:44 PM CDT Today the VMMA people responsable for the IT infrastructure told ZDNET that they didn't know that more websites were still hacked. They said they didn't know if they were re-hacked or were still hacked. First we informed FCCU the first day that more websites were hacked and that the CMS defacement was a very important element to look at Secondly we published from the first day the series of defacement as they were found the same day at zone-h.org. If you would have googled it - what should be your first instinct to find more info - you would have found the other sites also. thirdly VMMA (and maybe others) should really look for real professional monitortools for their websites and secondly think of really sending some staff to some professional trainings (forensics for starters) |
Posted: 22 May 2008 05:31 PM CDT Our Minister of the Interior said today in the parlement that internetcriminality was explosing and that it was a priority of his securityplan. It was however difficult according to the minister for our police forces to arrest those criminals who have their own marketplaces and criminal dumpsites because * they are mostly in Russian * they are blocking IP addresses of police forces * you have to be introduced by a member to gain access |
A very intensive week and so much still to do [belsec] [Belgian Security Blognetwork] Posted: 22 May 2008 05:21 PM CDT |
The Internet changes everything [An Information Security Place] Posted: 22 May 2008 04:08 PM CDT The Internet is a nuisance. Really, it is. It never ceases to amaze me how much "trouble" the Internet causes. Now I will be the first to say that it is possibly the best innovation in human history. But at the same time, it has also caused more problems, headaches, and heartaches than almost any innovation that I can think about. And it continues to redefine everything we do as a society and a race I know this is really not news, but it just struck me when I was poking around the news this morning and ran across this article about some websites looking to sue the state of Oregon over publishing laws online (I have written about issues similar to this about governments and publishing SSN’s online here and here). Here’s some of the opening paragraph:
And as I started to think of something to write about this, it struck me that this was really just a symptom of a larger issue. Basically, the problem is that no one has figured out just how to deal with these issues because we have moved so far so fast in the last 15 years. But why can’t we catch up? Seriously, we have been moving a the speed of light with technology for the last 100 years or more, and we have always been able to catch up with safety and laws pretty fast. Cars were invented, there was the first crash, and then we started figuring out that we need to have some kind of traffic control It may have been a while before it was worth a crap, but we caught up relatively quickly. Then there were airplanes. The Wright Brothers invented it (I have heard that it is debatable), then they crashed it and killed someone, and we figured out that we needed to make this safer. Honestly, I don’t know how quickly people started figuring out that these types of things needed to be regulated. Likely it was all about risk since there weren’t a lot of planes or cars around when they were first invented, so a lot of safety was needed yet. But we got smart eventually. Consider this quote:
The move to adopt the Internet and the rush to make it better and faster just came to quickly. Just like the Wright Brothers probably didn’t imagine planes that could traverse the globe in a matter of hours, the inventors of the Internet never really factored into their design a world wide public network that had to contend with a bunch of thugs trying to steal everyone’s information. They were trusting souls who figured it would just be a bunch of geeks from colleges talking to each other over email because they couldn’t get a date. But it became so much more so much more quickly than anyone imagined. And it pervaded everything. And now it is a struggle to catch up because the people who are really trying to fix the problems are often contending with the bad guys and the people who look like they are doing something and are really just riding the gravy train that the security issues have created (I have been guilty of that and still am in many people’s eyes since I sell security services and products). So how do we fix this stuff? Well, short of bombing us all back to the bronze age ("Stone Age" is so overused, and bronze is shinier), I really don’t know. There are theories abounding. Some people say we need to go back to the people and get them to buy in to doing things right. Some people say we need to leave them out of the equation and just implement technology. Others say we should just start over from scratch and build in security from the ground up. There are books upon books and speakers upon speakers (two more lucrative by-products of bad security) talking about security and the Internet. But it all keeps coming back to one thing: we’re still insecure. What I don’t understand is how the bad guys keep figuring out how to break in when we supposedly have people out there trying to find the flaws before they do. Is it simply a numbers game? Do they have that many more people looking than we do? Do they have a much more lucrative job than we do, so they are better motivated? Is it because the countries in which many bad guys reside don’t give a crap or just don’t have the resources to catch them? All of the above? What else? How do we get ahead of this? How can we put the same amount of resources into this to find the vulnerabilities before the bad guys? People have tried to create communities and projects where they pay for vulnerabilities. But there’s no guarantee that they are the only ones getting the results of their research. You know what? I don’t see and end to this. I think there is really no way to fix it. This simply is a human problem. There have always been bad people, and there always will be. And since humans are imperfect and will make mistakes, the bad guys will find ways to exploit those mistakes. There are smart people on both sides, and they will continue to struggle against each other forever (I know, kind of melodramatic). All this talk about "security should have been built in" is just a pipe dream. Security Nirvana is not possible. There will always be mistakes. Every time we come up with something new, someone figures out how to break it. And yes, part of that may be because it is based on old, insecure technology, but the human element will always creep in. I just don’t see another way. Yes, there can be some model changes when it comes to how stuff is sold and what really works and other things can be factored in to make change happen on a substantial level. But this is really what we have to work from. I know there is a lot of room for discussion here, and I welcome it. Please help me see this differently. But for right now, this is how I see it. I am not being cynical. I am not quitting on security. I just think it is going to be a protracted battle that will require dedication and persistence. Vet |
Posted: 22 May 2008 04:05 PM CDT
I didn't know John Stewart (Cisco Chief Security Officer) was reading my blog :-D |
nsa.gov Offline During a Few Hours [/dev/random] [Belgian Security Blognetwork] Posted: 22 May 2008 03:05 PM CDT The name servers hosting the National Security Agency (aka nsa.gov) were reported unavailable during a few hours around May the 15th. How is this possible? Let start some investigations using dig. When you query a root-server and ask for the name servers (NS records) of the nsa.gov zone, you receive the following information: $ dig nsa.gov ns ; <<>> DiG 9.3.1 <<>> nsa.gov ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6836 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;nsa.gov. IN NS ;; ANSWER SECTION: nsa.gov. 85807 IN NS romulus.ncsc.mil. nsa.gov. 85807 IN NS topscale.nsa.gov. ;; ADDITIONAL SECTION: romulus.ncsc.mil. 85807 IN A 144.51.5.2 topscale.nsa.gov. 86035 IN A 144.51.68.4 ;; Query time: 13 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu May 22 21:50:52 2008 ;; MSG SIZE rcvd: 110 Next step, resolve the two received name servers: $ host romulus.ncsc.mil romulus.ncsc.mil has address 144.51.5.2 $ host topscale.nsa.gov. topscale.nsa.gov has address 144.51.68.4 Finally, query the network information @ ARIN: $ whois -h whois.arin.net 144.51.5.2 OrgName: National Computer Security Center OrgID: NCSC-3 Address: 9800 Savage Road City: Fort George G. Meade StateProv: MD PostalCode: Country: US NetRange: 144.51.0.0 - 144.51.255.255 CIDR: 144.51.0.0/16 NetName: NCSC NetHandle: NET-144-51-0-0-1 Parent: NET-144-0-0-0-0 NetType: Direct Assignment NameServer: ROMULUS.NCSC.MIL NameServer: ZOMBIE.NCSC.MIL NameServer: BARRIER.NCSC.MIL NameServer: GRIZZLY.NRL.NAVY.MIL Comment: RegDate: Updated: 1997-11-17 RTechHandle: AMM32-ARIN RTechName: McCool, Anna M. RTechPhone: +1-301-688-5267 RTechEmail: amm@romulus.ncsc.mil # ARIN WHOIS database, last updated 2008-05-21 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. Both name servers are on the same network! What does it mean? In case of routing issue (bad BGP announce), ACL or configuration issue (blacklist the whole 144.51.0.0/16), nsa.gov will simply be offline! Never put your name servers on the same subnet nor the same ISP! |
Know what you're protecting against [Matt Flynn's Identity Management Blog] Posted: 22 May 2008 01:07 PM CDT You know that advertisement where the CEO (Todd Davis) gives out his social security number and tells you how secure it is because he uses his company's product to protect his identity information? Well, there have been 20 people who used his social security number to get a drivers license. And there was one "guy in Texas who duped an online payday loan operation last year into giving him $500 using Davis' Social Security number". Today, I read a few articles (including this one and this one) that suggest that LifeLock should be chastised because it doesn't protect you against everything that one might think it should. My first reaction was to agree with the writers. I always knew there was no way for a product to protect your SSN against any or all unwanted uses. And they shouldn't claim it does. And ha ha for Mr. Davis' identity being compromised. But, then I read Davis' rebuttal, "There's nothing on my actual credit report about uncollected funds, no outstanding tickets or warrants or anything" and I realized that this isn't really a case of a product not doing what it claims to do. It's a case of mis-aligned expectations about what a product can (or should) do. It reminded me of all the times I've heard that some strong authentication technique isn't effective because it's susceptible to man-in-the-middle techniques. Sure it is, but that's the wrong problem. SSL was developed to solve that problem. There are certainly issues with SSL (mostly around user experience and education about how it works), but strong authentication is not the answer. In the same way, there are problems with relying on SSN as authentication. And LifeLock won't protect against that. But, if it keeps your credit report clean, then maybe it's doing what it's supposed to. I haven't really followed the ads and I have no idea what the company promises its customers, but I thought I'd use this opportunity to remind you of the old cliche – there is no silver bullet. Analyze your risks and know which types of threats a security solution will be effective at protecting you against. Correctly aligned expectations yield happy customers. |
MSSP and NAC - true love or lust? [StillSecure, After All These Years] Posted: 22 May 2008 10:51 AM CDT A recent edition to the Security Bloggers Network (over 50,000 combined subscribers strong now!) is Grant Hartline, CTO of Mirage Networks, Mirage blog. Mirage is a competitor of StillSecure in the NAC marketplace, sometimes (actually we don't run into them very often) but I was happy to see them join the SBN. I have certainly taken shots at them in the past and am glad they are using the blogging medium to put their own point of view out there. Networks like the SBN are strongest when multiple and different points of view are represented. Anyway, Grant has been blogging up a bit over there with some good stuff, especially about post-connect, NAP, Interop and Joel Snyder. Grant's most recent article is called MSSP and NAC - True Love. For the most part I agree with Grant that NAC is a natural for the managed services space. However, I think for the MSSP (managed security services provider) market specifically it may be beyond their current offering levels. Most MSSP offerings today are focused at the perimeter. They have grown from managed firewall to managed IDS/IPS, managed anti-spam and managed content filtering. Now managed UTM is all the rage. However, all of these technologies are perimeter based. If I am not mistaken Mirage's early experience offering a managed service was with AT&T offering it as a behavior based type of intrusion prevention and worm detection. I think moving into the internal network with a more traditional NAC offering might beyond the current scope of most pure MSSPs. However, managed service providers who are already providing desktop management and full network management like an EDS, IBM or HP are indeed natural candidates to provide a managed NAC service. I think we will be seeing much more of managed NAC from these type of providers in the future, but it will be a while until the pureplay MSSPs have managed NAC. |
What version am I on Now?? [An Information Security Place] Posted: 22 May 2008 09:30 AM CDT |
Some other sites phpizabi [belsec] [Belgian Security Blognetwork] Posted: 22 May 2008 09:17 AM CDT Powered by PHPizabi "hacked by" Powered by PHPizabi "ownz" in Google not so many and people are cleaning up in 2007 there was another hackstorm against phpizabi two things to remember always monitor your pages and sites and always patch them immediately if you are hacked, never forget you are going to be attacked again over and over again and if you forget the first rule, you will be hacked again - you will now have no rest, no time-frame, no gap that you can afford It overcomes most of us once in our digital lifetime. It ain't bad if you learn the lessons. So get over it, learn your lesson and get on with it. And spend more money and time and people on security. It is worth every cent most of the time. |
PCI Compliance and Network Segmentation [Matt Flynn's Identity Management Blog] Posted: 22 May 2008 09:09 AM CDT I spoke at a CSO Executive Seminar on PCI Compliance in January. During my talk, I put up a slide showing a PCI reference architecture and went through many of the various security components that could help lock down an infrastructure and mapped each to the related PCI requirements. I covered topics like authentication, access control, IDS/IPS, anti-virus, encryption, key management, policy management, change management, rights audit, user monitoring, and a few others. Before I began with that slide, I gave a disclaimer that there are a few key techniques that I would not include in the reference. One was network segmentation. I hadn't heard others mention it before in reference to PCI, but as I was thinking about my talk and building the reference architecture, it occurred to me that segmentation would be a really useful way to reduce risk in an environment where credit cards are accepted. So, I mentioned it in passing as something that companies should think about in addition to what I had on the screen. Today, I read this article, by Stephen Cobb, in which he discusses PCI compliance and pays specific attention to the topic of network segmentation. I thought it would be a nice supplement to my talk back in January. In retrospect, I might have spent a bit more time on that topic, but I really tried to cover a ton in a short time. So, if anyone from that audience is reading this... Or if you're looking to improve your security or your PCI compliance posture... |
Google Health [Network Security Blog] Posted: 22 May 2008 08:21 AM CDT Eric Irvin, Senior Consultant at IrvTech, suggested I blog about Google’s recent announcement of Google Health and I countered by challenging him to write up a post of his own, and here it is. Eric doesn’t have a blog, so if you want to get in touch with him, leave a comment or contact me and I’ll forward it on to him. Without further ado: Google Health by Eric Irvin: Google has recently offered a service to track and monitor your own personal health records. Google Health provides a centralized manner of health information management, utilizing Google’s signature API. Google has assured users that they will protect and secure the data. The problem is the Health Care Industry already has a standard of privacy and protection with HIPAA. Health portability and privacy has always been a problem in the Health Care Industry. This has been largely due to the industry facing lawsuits due to a lack of privacy regulations, and/or questions relating to how data should be shared between insurance companies, hospitals, and other medical care providers. Out of these legal questions, and lack of clarity, the Health Insurance Portability and Accountability Act was passed in 1996. Google believes that it should not be regulated by HIPAA because they are not a health care provider. Google addresses this in a post from a development blog. “Some have asked how Google Health relates and compares to the privacy protections for patients under the Health Insurance Portability and Accountability Act (HIPAA), a federal law that establishes privacy standards for patient health information. Unlike a doctor or health plan, Google Health is not regulated by HIPAA because Google does not provide health care services.” I disagree with Google’s not wishing to comply with HIPAA regulations, which would apply a baseline of security checks and safeguards to protect customer information. With other industry requirements (such as PCI, SOX), privacy and protections extends itself towards anyone exchanging customer information. While the law, in itself, does not require Google to do so, I think it sets a standard of expectation for people who choose to use the service. Because Google is not subjecting itself to HIPAA, there is no legal requirement for them to keep your information private, other than the terms of service. Google could begin providing information to pharmaceutical companies as to who has which medical problems, and allow them to target advertisements to them. This would be a horrible invasion of privacy, and breach of a basic trust. While Google has not announced any plans to do so, their own terms of service allow them to change their own policies at any time without notice. At least HIPAA requires a vote from Congress to extend, withdraw, or modify any protections or use of said information. While HIPAA was established for the sake of protecting patients rights from Health Providers, Insurance Companies, et al., the question remains, should a third-party company who has access to Health Information be governed by those same rules? |
how VTM probably was hacked and are you also vulnerable [belsec] [Belgian Security Blognetwork] Posted: 22 May 2008 08:18 AM CDT thanx for the info, pentester :) the attackers uses a working exploit of which we don't know yet if it is being published, but the exploit is there in the open for PHPizabi the vulnerability is published on Bugtraq 28954 on 26/04/2008 and lets someone read the MD5 passwords in PHPizabi If you are running PHPizabi it is time to * upgrade * change all passwords * use different passwords for all services, persons, sites, ..... * activate logging and monitoring more this evening, keep the info coming More sites are vulnerable...... up your guard, VTM is a working example.
|
DNS helps typosquatters again [belsec] [Belgian Security Blognetwork] Posted: 22 May 2008 04:55 AM CDT DNS.Be allowed the use of numbers in Belgian domainnames. Several securityresearchers warned against this but this commercial enterprise just wants to sell more and more and more (and as they lower the price of a domainname for the resellers they have to sell more domainnames to win the same amount of money) for firms this poses another problem. You are now being blackmailed in having to order x number of domainnames with numbers in it if you have in your domainname a o it may become an 0 a real life example micros0ft.be if you have in your domainname a l or a I it make become a 1 and for porn filters you will have to filter also p0rn.be and l0ve.be what you can do also ? Complain with the minister quickenborne, speak to your representatives in the parliament. Because to get each typosquatter away you will have to go to court (forget it) or you will have to pay (still a lot but they have already halved the price under pressure) some administrative procedure it is the same old song and it continues.... but it is not for that reason that we will shut up.
|
You are subscribed to email updates from Security Bloggers Network To stop receiving these emails, you may unsubscribe now. | Email Delivery powered by FeedBurner |
Inbox too full? Subscribe to the feed version of Security Bloggers Network in a feed reader. | |
If you prefer to unsubscribe via postal mail, write to: Security Bloggers Network, c/o FeedBurner, 20 W Kinzie, 9th Floor, Chicago IL USA 60610 |
No comments:
Post a Comment