RIP

bine zis, dar exista o varianta sub 100RON cu N? eu l-as folosi doar pentru teste, acas, doar ca proof of concept, si nu vreau sa investe 300RON

cel mai interesant mi se pare acel D-Link DWL-G122 la doar 60RON l-a incercat cineva in monitoring mode?

A RUSSIAN insecurity outfit has managed to create a zero day exploit for Firefox 3.6 under Windows. The exploit allows attackers to remotely gain control of a Windows PC thanks to a previously unknown flaw in the Windows version of the Firebadger 3.6 browser software. Intevydis develops the commercial VulnDisco add-on for the Canvas exploit toolkit that's marketed by the vendor Immunity. Writing at the company's online forum, Intevydis developer Evgeny Legerov said that his exploit for Windows XP (SP3) and Vista is quite reliable. He said it was an interesting challenge to find the buffer overflow flaw and work out a way to exploit it. The Mozilla Foundation knows about the exploit but has not made an official statement on it yet and has not released a patch for Firefox 3.6 so far. Secunia says the problem is critical. It is not clear whether the exploit was behind an increase in the number of Firefox 3.6 crashes that was noted on February 12th and 13th. While those might not have been caused by a real life exploit, they could have been due to the exploit being tested. Source: theinquirer

frumos ar fi sa poti verifica automat toata lista de id-uri salvate cum era si la budyspy sau cum draq ii zicea

fumat de mult ala, il am pe rss

astia is cei care or facut site-ul Portfolio : Our Work : Aardvark Media Limited nu stiu daca is destul de cunoscuti ca sa gasesti template-uri de la ei ... sau nulled scripts... dar who knows poti incerca totusi am dat un scrut search shi am gasit ceva... mai incearca shi tu ... http://honey-freetemplates4u.blogspot.com/2009/08/aardvark-topsites.html

am facut putin research despre o cunostiinta, shi am dat peste niste forumuri tare ciudate... dpmdv aflasem cu ocazia asta de cati ani avea respectiva probleme cu candida vaginala ... shi ca nu are nici un fel de problema daca ia pastila de a doua zi .. shi alte tampenii ... am ras bine plus ca au o groaza de membri ... multe femei ... Comunitatea femeilor sexy pe Kudika.ro forumul Mayra - Powered by vBulletin Comunitatea Healthy - Sanatate si dieta. precis mai sunt si altele ... draq stie ca nu m-au pasionat niciodata comunitatile din .ro cu atat mai putin astea cu subiecte pentru femei posibil sa fie si facute pe aceasi platforma

ce bine ca inca nu am trecut la 2.9

The buzz was on about google buzz sharing your list of contacts (which they then quickly fixed in their casual we-did-nothing-wrong-these-are-not-the-droids-you’re-looking-for mind trick). Readers of this blog remember when google calendar let you see the full name behind every gmail address. At that time, google ignored, then decided there’s nothing wrong with that feature, then fixed it. Only it still works, on other google services. Of course, these aren’t the droids I’m looking for. Well, here’s a method to DoS a google group user; it was discovered by Shachar Shemesh of lingnu about 18 months ago, who told google and was answered with a strong silence. With google the only disclosure seems to be full-disclosure, so with apologies to you google-group users out there, here is the outline of the attack below. DoS’ing google groups Domain-Key is a good method to prevent spam from coming in, as well as preventing unwanted emails from being handled if they are sent through “the wrong” SMTP server. Google has taken domain-key a step further, with their Domain-Key and Google Groups combo. In this combination, if an email is sent to a Google Groups from an SMTP server who is not listed in the Domain-key record, that email will be banned from writing or accessing the Google Group in question. The banned user will no longer be able to write or read from that group, will not be able to “undo” this change as emails to Google’s technical support regarding this appear to go unanswered. From this background, the attack seems clear. A malicious attacker can get pretty much anyone banned from a certain Google Group. Steps to reproduce: * Subscribe to a Google group. * Look for a victim (Anyone posting to the group from a gmail.com account is fair game). * Configure your email client to send emails with a “From” field that matches this email address, and use an SMTP that is not one of those authorized by the domain key. Your ISP’s SMTP servers will probably suffice. * Use this configurations to send an email to the group. It doesn’t really matter what the email content is, but I recommend making it look like a genuine email to make is harder to filter (and raise ‘plausible deniability’ in case someone comes asking questions). As a result: The victim will be automatically banned from the group. He or She will receive no notification of that fact: not to the fact he or she was banned, and not even to the fact that the email he or she supposedly sent failed Domain key verification. The victim will cease to receive emails from the group. They will only find out about it if they try to send an email, at which point they will receive a brief and unhelpful message saying they were banned, with no explanation why and no means to appeal. Trying to access the group from the web site will result in a “you are banned” message, again, with no helpful information on why the ban was instated nor how to appeal. It is a curious point that even information that is publicly available without registration, such as the group’s archive or description, will be blocked. They will have to sign out of Google to be able to see it(!). The best means to appeal she is likely to find is “Google Help”, which points to an email address where past experience shows the request email will be unceremoniously ignored, just like Shachar’s email notifying google of this vulnerability. Source: Security Team

I’ve discovered another trick that may surprise some, this time relating to Google’s services. I don’t view the issue as a vulnerability, but it likely goes against user privacy expectations. In short, having a public Google profile (which you might have created when checking out Google Buzz) can allow others to figure out your Gmail address. This really shouldn’t be that surprising, given that your username is generally consistent across Google services, and a public profile is public. But those who currently have numeric profile addresses (e.g. the harmonyguy - Google Profile) might think their profile is not easily tied to their username. But by using Picasa, Google’s photo sharing service, it’s often quite simple to go from a numeric profile address to an actual username. To protect yourself from this access, visit the Picasa settings page. Under “Your gallery URL,” add a new username and select the new username for your gallery URL. Also, you may want to edit your nickname. In my testing thus far, it matters little whether you’ve used Picasa before – if you have a Gmail account, Picasa is also enabled on your account. And while individual Picasa albums have privacy controls, I have not found a way to block simply loading your Picasa home page. With the introduction of Buzz, Google is encouraging users to take advantage of Google profiles. But in the process, Google is tying together services that many users may have treated quite distinctly in the past. If you want your Gmail address to remain private, you need to manage properly the other Google services you use to avoid one of them exposing your Gmail username. Update (Feb. 13): It appears Google has adjusted their services to prevent the original URI trick from working Previously, adding a profile number to picasaweb.google.com (e.g. http://picasaweb.google.com/104424237445852766735) would either load a page with the username visible, the username embedded in the page’s source code (_user.name in JavaScript), or an error page in a few particular instances. One configuration that would simply produce an error page was if you had Picasa setup under a different username than your Gmail username, hence my advice. It now seems that using a numeric Picasa URI will either load an error page if the user does have Picasa setup or a page indicating the user does not have Picasa galleries but with no username anywhere in the page. I’ve already done some preliminary testing to see if Google Reader could also be used to discover usernames, but so far that does not seem possible. Still, it’s wise to be cautious when using a tool that interacts with so many other services. Source: theharmonyguy

Looks like the Internet Assigned Numbers Authority (IANA) has recently assigned two more IP prefixes to the American Registry for Internet Numbers (ARIN): 50.0.0.0/8 and 107.0.0.0/8 For those of you that maintain IP Bogon Filters, you may want to adjust your filters accordingly. http://www.iana.org/assignments/ipv4-address-space/ Source: SANS Internet Storm Center

There should be a 9-minute film on Newsnight tonight (10:30pm, BBC Two) showing some research by Steven Murdoch, Saar Drimer, Mike Bond and me. We demonstrate a middleperson attack on EMV which lets criminals use stolen chip and PIN cards without knowing the PIN. Our technical paper Chip and PIN is Broken explains how. It has been causing quite a stir as it has circulated the banking industry privately for over 2 months, and it has been accepted for the IEEE Symposium on Security and Privacy, the top conference in computer security. (See also our FAQ and the press release.) The flaw is that when you put a card into a terminal, a negotiation takes place about how the cardholder should be authenticated: using a PIN, using a signature or not at all. This particular subprotocol is not authenticated, so you can trick the card into thinking it’s doing a chip-and-signature transaction while the terminal thinks it’s chip-and-PIN. The upshot is that you can buy stuff using a stolen card and a PIN of 0000 (or anything you want). We did so, on camera, using various journalists’ cards. The transactions went through fine and the receipts say “Verified by PIN”. It’s no surprise to us or bankers that this attack works offline (when the merchant cannot contact the bank) — in fact Steven blogged about it here last August. But the real shocker is that it works online too: even when the bank authorisation system has all the transaction data sent back to it for verification. The reason why it works can be quite subtle and convoluted: bank authorisation systems are complex beasts, including cryptographic checks, account checks, database checks, and interfaces with fraud detection systems which might apply a points-scoring system to the output of all the above. In theory all the data you need to spot the wedge attack will be present, but in practice? And most of all, how can you spot it if you’re not even looking? The banks didn’t even realise they needed to check. This attack is both academically and practically significant. We get reports weekly from different victims of phantom withdrawals, and these include large numbers of stolen cards used to make purchases in the window between theft and the cancellation of the card. Currently these victims are denied refunds by their banks, but this attack could explain some of the frauds we are seeing. The fact the receipt says “PIN Verified” when actually it wasn’t raises a whole load of legal and evidential questions which call into question the banking industry’s claim that their systems work (and log) properly. Merchants will be none too pleased either; the system no longer protects their interests but only those of the issuing bank. There’s been some confusion, possibly even misinformation, about our attack and its effects. Cartes Bancaires in France were so concerned that they briefed the press way in advance of our plans for publication. We can set the record straight on a few things: * the attack applies to cards used online (where the merchant POS contacts the bank) as well as offline; * the attack works regardless of the amount of money spent (not just for small value amounts that are below floor limit); * the attack doesn’t work once a card has been cancelled by the bank — just like stolen cards in the past can only be used for a certain window of time once the cardholder discovers the loss; * the attack doesn’t work at ATMs (cash machines); * the failure applies to bank card schemes based on EMV – the most widely deployed standard for smartcard payments. Older national smartcard schemes may or may not be vulnerable; we don’t know. So what went wrong? In essence, there is a gaping hole in the specifications which together create the “Chip and PIN” system. These specs consist of the EMV protocol framework, the card scheme individual rules (Visa, MasterCard standards), the national payment association rules (UK Payments Association aka APACS, in the UK), and documents produced by each individual issuer describing their own customisations of the scheme. Each spec defines security criteria, tweaks options and sets rules – but none take responsibility for listing what back-end checks are needed. As a result, hundreds of issuers independently get it wrong, and gain false assurance that all bases are covered from the common specifications. The EMV specification stack is broken, and needs fixing. We’re really worried that if something isn’t done to fix this problem, and the many others we’ve found in EMV, other regions adopting it (like the USA) are going to make the same mistakes again and again – and that means customers stay vulnerable. That’s why again we’re arguing that Chip and PIN is broken. We don’t want people keeping their money in shoe boxes – we want the problems fixed. That means getting decent governance for the system that involves all the stakeholders – banks, regulators, merchants and customers. Update (2010-02-11): ZDNet UK have some in-depth press coverage, and the story has also been picked up by the Telegraph and Daily Mail. Source: Light Blue Touchpaper

If you spend enough time looking for Cross-Site Scripting (XSS) vulnerabilities, you are bound to come across a cookie-based version eventually -- where the script injection is located in the Cookie header. The problem is there’s no good way (in a modern browser) to force a victims browser to send an HTTP request with a modified Cookie value (to include HTML/JS). While the website or Web application is still technically vulnerable to XSS this is usually considered unimplementable since no PoC code can be created and the risk/threat is therefore lowered. I was having this conversation with Rob Tate, a member of WhiteHat’s Engineering team, who enlightened to something I hadn’t previously considered. Cookie-based XSS can be made very useful after all! Consider an online bank with an XSS through a username Cookie parameter. After successful login the resulting page would read something like, "Hello ." Cookie: username= Setting the Cookie will most likely require another (non-persistent) XSS vulnerability, which as we know is extremely common. By combining these two vulnerabilities, an unimplementable and non-persistent XSS, you could create a persistent XSS scenario. What the attacker could do is use the non-persistent XSS to inject a data mining JavaScript function into the browser’s Cookie username parameter via document.cookie. Afterwards every time the victim logs-in the JavaScript will execute in the DOM. Now you have an a persistent XSS attack sticking with the browser over multiple sessions. Update: Related work by Mike Bailey, Cross-subdomain Cookie Attacks: Screen1, Screen2 Source: Jeremiah Grossman's Blog

Phishing is usually be categorized under social engineering rather than a technical hack. It is inherently about tricking the user to click a link, or visit a web page. However, if the victim is tricked into visiting the phished page, even while they are on a genuine site should be a cause of concern. Since the victim did not initiate to move to the phished page, they are caught off guard. This post is about a possible attack on Google Wave which could at the least disrupt the wave experience, if not steal the credentials. This attack is similar to the one on Orkut Opensocial that I had published earlier. I am sure someone somewhere would have already figured this out, but I chose to post this anyway since I got some time off FlashPlus, my Google Chrome extension. The hack can be done by anyone anonymously and on public waves. 1. Create a phished Google Login page. You could check out tackle. 2. Search for public waves 3. Reply to one of the messages, insert a gadget in your reply 4. The gadget sets the top.location to the phished page. 5. The victim now visits the wave and opens this unread wave 6. The gadget kicks in, redirects the user to a phished page 7. Since the victim was still inside and browsing wave, they may not suspect a phished page. They may think that they were simply logged out. A couple of ways to anonymize the attacker could be * Make the gadget to set top.location after a window.setTimeout, instead of doing it immediately. * Do not redirect all users. Redirect them if a certain cookie is not set. If a cookie is set, they were already phished. * Create anonymous accounts on Gmail, host gadget and phished page using Google Gadget Editor on iGoogle. This shows the wave URL on a gmodules.com domain, something that's more believable. * Submit credentials from the phished page to a form created using Google spreadsheets. I am not sure how harmful this hack can get. I have pinged a friend ay Google about this. The following video shows these steps: Source: axemclion