http://www.israelnationalnews.com/News/News.aspx/179572 By Ari Soffer Israel National News 4/13/2014 Israeli hackers have gone on the offensive against their anti-Israel opponents in revenge for the #OpIsrael hacking attack against Israeli sites and servers. After the failed “operation” by members of the “Anonymous” hacker network, Israeli hackers from Israel Elite Force took the fight to them – robbing them of their anonymity by posting details and even photos of some of the hackers on their website. The hacker behind the counterattack, an Israeli known as “Buddhax”, said that he did it to make anti-Israel hackers “think twice” before attacking Israeli sites, and to expose them as amateurs. Israeli hackers had already responded to attempts last week to infiltrate Israeli and Jewish sites by taking down or defacing anti-Zionist and Muslim sites. But Buddhax has gone a step further. [...]



Tags: , , ,
Tagged with:
 

http://www.wired.com/2014/04/att-hacker-conviction-vacated/ By Kim Zetter Threat Level Wired.com 04.11.14 A hacker sentenced to three and a half years in prison for obtaining the personal data of more than 100,000 iPad owners from AT&T’s unsecured website is about to go free, after a ruling today that prosecutors were wrong to charge him in a state where none of his alleged crimes occurred. Andrew “Weev” Auernheimer was in Arkansas during the time of the hack, his alleged co-conspirator was in California, and the servers that they accessed were physically located in Dallas, Texas and Atlanta, Georgia. Prosecutors therefore had no justification for bringing the case against Auernheimer in New Jersey, a federal appeals panel ruled this morning. The appeal was closely watched in cyber law and civil liberties circles, and Auernheimer had a powerhouse legal team that handled his case pro-bono. “Venue in criminal cases is more than a technicality; it involves ‘matters that touch closely the fair administration of criminal justice and public confidence in it,’” the judges wrote in their opinion (.pdf). “This is especially true of computer crimes in the era of mass interconnectivity. Because we conclude that venue did not lie in New Jersey, we will reverse the District Court’s venue determination and vacate Auernheimer’s conviction.” [...]

Tags: , , , , , , , , , , , , ,
Tagged with:
 

http://www.smh.com.au/it-pro/security-it/who-is-robin-seggelmann-and-did-his-heartbleed-break-the-internet-20140411-zqtjj.html By Lia Timson smh.com.au April 11, 2014 German computer programmer Robin Seggelman has been outed as the man whose coding mistake, now known as Heartbleed, has left millions of internet users and thousands of websites vulnerable to hackers. The discovery, by Google engineers, has prompted experts to call on people to change their passwords to most, if not all, websites they subscribe to after site owners have fixed their vulnerabilities. Dr Seggelman, 31, from the small town of Oelde in north-west Germany, is a contributor to the Internet Engineering Task Force (IETF), a not-for-profit global group whose mission is to make the internet work better. He is attached to the Munster University of Applied Sciences in Germany, where, as research associate in the networking programming lab in the department of electrical engineering and computer science, he has published a number of papers, including his thesis on strategies to secure internet communications in 2012. He has been writing academic papers and giving talks on security matters since 2009, while still a PhD student. Advertisement His academic research influence index score of two, based on the number of scientific citations of his work, suggests an influential thinker at the early stages of his scientific career. According to the IETF, Dr Seggelman previously worked for Dutch Telecom IT services subsidiary T-Systems, possibly the largest such consultancy in Germany. [...]

Tags: , , , , , , , , , , , ,
Tagged with:
 

http://www.telegraph.co.uk/technology/internet-security/10753180/Hacker-exposes-embarrassing-weakness-in-Mets-online-security.html By Theo Merz The Telegraph 10 Apr 2014 A computer security expert took less than two minutes to exploit an “embarrassing” flaw in the Metropolitan Police’s website, which he claims could have left computer users vulnerable to malicious attacks. Ilia Kolochenko, a consultant who is employed by companies to find weaknesses in their systems, said it took just 90 seconds to find a vulnerability which allowed him to create a fake page under the Met’s domain name. A malicious hacker could have exploited this to create a page asking members of the public for personal information, or one injecting malware, which would have been impossible to distinguish from a genuine police link. “I couldn’t access the Met’s police database, but I could very easily create a new link for the site,” the 27-year-old said. [...]

Tags: , , , , , , , , , , , , , , ,
Tagged with:
 

Performance Results of Free Public DNS Services

On April 9, 2014, in Personal, Security, by Lawrence Pingree

I ran some tests today to optimize my Internet performance. I performed the test using DNSBench. In my test I included all the major Free public DNS services that provide SOME level of malicious host protection capabilities. Below are my results.

Please Note: Performance results may vary. This test was performed via a Comcast home broadband connection in Livermore, California. Location of requestor and server’s can contribute significantly to overall performance. All users should perform their own tests to select an appropriate provider.

Secure Free Public DNS Test Performance Graphic

secure-dns-test-04-09-2014

Performance Ranking by Provider and DNS Server

#1 - Norton ConnectSafe DNS
nameserver 199.85.127.10 (fastest DNS lookups in overall test)
nameserver 199.85.126.10 (4th place DNS lookups in overall test)

#2 - OpenDNS Home
nameserver 208.67.220.220 (2nd fastest DNS lookups in overall test)
nameserver 208.67.222.222 (3rd place DNS lookups in overall test)

#3 – Comodo Secure DNS
nameserver 8.26.56.26 (5th place DNS lookups in overall test)
nameserver 8.20.247.20 (6th place DNS lookups in overall test)
Below is a comprehensive report from the tool 

Final benchmark results, sorted by nameserver performance:
(average cached name retrieval speed, fastest to slowest)

199. 85.127. 10 | Min | Avg | Max |Std.Dev|Reliab%|
—————-+——-+——-+——-+——-+——-+
- Cached Name | 0.014 | 0.016 | 0.020 | 0.001 | 100.0 |
- Uncached Name | 0.017 | 0.086 | 0.254 | 0.070 | 100.0 |
- DotCom Lookup | 0.035 | 0.077 | 0.127 | 0.023 | 100.0 |
—<——–>—+——-+——-+——-+——-+——-+
··· no official Internet DNS name ···
ULTRADNS – NeuStar, Inc.,US
208. 67.220.220 | Min | Avg | Max |Std.Dev|Reliab%|
—————-+——-+——-+——-+——-+——-+
- Cached Name | 0.020 | 0.022 | 0.024 | 0.001 | 100.0 |
- Uncached Name | 0.021 | 0.146 | 0.590 | 0.136 | 100.0 |
- DotCom Lookup | 0.082 | 0.196 | 0.335 | 0.058 | 100.0 |
—<——–>—+——-+——-+——-+——-+——-+
resolver2.opendns.com
OPENDNS – OpenDNS, LLC,US
208. 67.222.222 | Min | Avg | Max |Std.Dev|Reliab%|
—————-+——-+——-+——-+——-+——-+
- Cached Name | 0.020 | 0.022 | 0.025 | 0.001 | 100.0 |
- Uncached Name | 0.021 | 0.152 | 0.518 | 0.139 | 100.0 |
- DotCom Lookup | 0.078 | 0.189 | 0.351 | 0.070 | 100.0 |
—<——–>—+——-+——-+——-+——-+——-+
resolver1.opendns.com
OPENDNS – OpenDNS, LLC,US
199. 85.126. 10 | Min | Avg | Max |Std.Dev|Reliab%|
—————-+——-+——-+——-+——-+——-+
- Cached Name | 0.030 | 0.032 | 0.037 | 0.001 | 100.0 |
- Uncached Name | 0.033 | 0.100 | 0.261 | 0.072 | 100.0 |
- DotCom Lookup | 0.061 | 0.105 | 0.159 | 0.022 | 100.0 |
—<——–>—+——-+——-+——-+——-+——-+
··· no official Internet DNS name ···
ULTRADNS – NeuStar, Inc.,US
8. 26. 56. 26 | Min | Avg | Max |Std.Dev|Reliab%|
—————-+——-+——-+——-+——-+——-+
- Cached Name | 0.032 | 0.058 | 0.246 | 0.053 | 100.0 |
- Uncached Name | 0.035 | 0.130 | 0.423 | 0.100 | 100.0 |
- DotCom Lookup | 0.035 | 0.094 | 0.132 | 0.036 | 100.0 |
—<——–>—+——-+——-+——-+——-+——-+
ns1.recursive.dns.com
ELVATE – Elvate.com, LLC,US
8. 20.247. 20 | Min | Avg | Max |Std.Dev|Reliab%|
—————-+——-+——-+——-+——-+——-+
- Cached Name | 0.032 | 0.066 | 0.253 | 0.054 | 100.0 |
- Uncached Name | 0.034 | 0.138 | 0.525 | 0.119 | 100.0 |
- DotCom Lookup | 0.034 | 0.099 | 0.130 | 0.031 | 100.0 |
—<——–>—+——-+——-+——-+——-+——-+
ns2.recursive.dns.com
ELVATE – Elvate.com, LLC,US
UTC: 2014-04-09, from 21:33:01 to 21:33:30, for 00:28.540

Interpreting your benchmark results above:

The following guide is only intended as a quick
“get you going” reference and reminder.

To obtain a working understanding of this program’s operation, and to familiarize yourself with its many features, please see the main DNS Benchmark web page by clicking on the “Goto DNS Page” button below.

Referring to this sample:

64. 81.159. 2 | Min | Avg | Max |Std.Dev|Reliab%
—————-+——-+——-+——-+——-+——-
- Cached Name | 0.001 | 0.001 | 0.001 | 0.000 | 100.0
- Uncached Name | 0.021 | 0.033 | 0.045 | 0.016 | 100.0
- DotCom Lookup | 0.021 | 0.022 | 0.022 | 0.001 | 100.0
—<O-OO—->—+——-+——-+——-+——-+——-
dns.chi1.speakeasy.net
Speakeasy

The Benchmark creates a table similar to the one above for each DNS resolver (nameserver) tested. The top line specifies the IP address of the nameserver for this table.

The first three numeric columns provide the minimum, average, and maximum query-response times in seconds. Note that these timings incorporate all network delays from the querying computer, across the Internet, to the nameserver, the nameserver’s own processing, and the return of the reply. Since the numbers contain three decimal digits of accuracy, the overall resolution of the timing is thousandths of a second, or milliseconds.

The fourth numeric column shows the “standard deviation” of the collected query-response times which is a common statistical measure of the spread of the values – a smaller standard deviation means more consistency and less spread.

The fifth and last numeric column shows the reliability of the tested nameserver’s replies to queries. Since lost, dropped, or ignored queries introduce a significant lookup delay (typically a full second or more each) a nameserver’s reliability is an important consideration.

The labels of the middle three lines are colored red, green, and blue to match their respective bars on the response time bar chart.

The “Cached Name” line presents the timings for queries that are answered from the server’s own local name cache without requiring it to forward the query to other name servers. Since the name caches of active public nameservers will always be full of the IPs of common domains, the vast majority of queries will be cached. Therefore, the Benchmark gives this timing the highest weight.

The “Uncached Name” line presents the timings for queries which could not be answered from the server’s local cache and required it to ask another name server for the data. Specifically, this measures the time required to resolve the IP addresses of the Internet’s 30 most popular web sites. The Benchmark gives this timing the second highest weight.

The “DotCom Lookup” line presents the timings for the resolution of dot com nameserver IP addresses. This differs from the Cached and Uncached tests above, since they measure the time required to determine a dot com’s IP, whereas the DotCom Lookup measures the time required to resolve the IP of a dot com’s nameserver, from which a dot com’s IP would then be resolved. This test presents a measure of how well the DNS server being tested is connected to the dot com nameservers.

The lower border of the table contains a set of eight indicators (O and -) representing non-routable networks whose IP addresses are actively blocked by the resolver to protect its users from DNS rebinding attacks: <O-OO—->. The “O” character indicates that blocking is occurring for the corresponding network, whereas the “-” character indicates that non-routable IP addresses are being resolved and rebinding protection is not present. The first four symbols represent the four IPv4 networks beginning with 10., 127., 172., and 192. respectively, and the second four symbols are the same networks but for IPv6.

The final two lines at the bottom of each chart duplicate the information from the Name and Owner tabs on the Nameserver page:

dns.chi1.speakeasy.net
Speakeasy

The first line displays the “Reverse DNS” name of the server, if any. (This is the name looked up by the nameserver’s IP address.) The second line displays the Ownership information, if any, of the network containing the nameserver

The final line of the automatically generated chart is a timestamp that shows the date and time of the start, completion, and total elapsed time of the benchmark:

UTC: 2009-07-15 from 16:41:50 to 16:44:59 for 03:08.703

All times are given in Universal Coordinated Time (UTC) which is equivalent to GMT. In the sample shown above, the entire benchmark required 3 minutes, 8.703 seconds to run to completion.

All, or a marked portion, of the Tabular Data results on this page may be copied to the Windows’ clipboard or saved to a file for safe keeping, sharing, or later comparison.
• • •

Tags: , , , , , , , , , , , , , , , , , , , , ,
Tagged with:
 

http://www.cnet.com/news/how-to-protect-yourself-from-the-heartbleed-bug/ By Richard Nieva CNET News Security April 8, 2014 A major new security vulnerability dubbed Heartbleed was disclosed Monday night with severe implications for the entire Web. The bug can scrape a server’s memory, where sensitive user data is stored, including private data such as usernames, passwords, and credit card numbers. It’s an extremely serious issue, affecting some 500,000 servers, according to Netcraft, an Internet research firm. Here’s what you can do to make sure your information is protected, according to security experts contacted by CNET: Do not log into accounts from afflicted sites until you’re sure the company has patched the problem. If the company hasn’t been forthcoming

Tags: , , , , , , , , , ,
Tagged with:
 

http://arstechnica.com/security/2014/04/critical-crypto-bug-in-openssl-opens-two-thirds-of-the-web-to-eavesdropping/ By Dan Goodin Ars Technica April 7, 2014 Researchers have discovered an extremely critical defect in the cryptographic software library an estimated two-thirds of Web servers use to identify themselves to end users and prevent the eavesdropping of passwords, banking credentials, and other sensitive data. The warning about the bug in OpenSSL coincided with the release of version 1.0.1g of the open-source program, which is the default cryptographic library used in the Apache and nginx Web server applications, as well as a wide variety of operating systems and e-mail and instant-messaging clients. The bug, which has resided in production versions of OpenSSL for more than two years, could make it possible for people to recover the private encryption key at the heart of the digital certificates used to authenticate Internet servers and to encrypt data traveling between them and end users. Attacks leave no traces in server logs, so there’s no way of knowing if the bug has been actively exploited. Still, the risk is extraordinary, given the ability to disclose keys, passwords, and other credentials that could be used in future compromises. “Bugs in single software or library come and go and are fixed by new versions,” the researchers who discovered the vulnerability wrote in a blog post published Monday. “However this bug has left a large amount of private keys and other secrets exposed to the Internet. Considering the long exposure, ease of exploitations and attacks leaving no trace this exposure should be taken seriously.” The researchers, who work at Google and software security firm Codenomicon, said even after vulnerable websites install the OpenSSL patch, they may still remain vulnerable to attacks. The risk stems from the possibility that attackers already exploited the vulnerability to recover the private key of the digital certificate, passwords used to administer the sites, or authentication cookies and similar credentials used to validate users to restricted parts of a website. Fully recovering from the two-year-long vulnerability may also require revoking any exposed keys, reissuing new keys, and invalidating all session keys and session cookies. Members of the Tor anonymity project have a brief write-up of the bug here, and a this analysis provides useful technical details. [...]

Tags: , , , , , , , , , , , , , , , , , , , , , , ,
Tagged with:
 

http://www.israelnationalnews.com/News/News.aspx/179376 By Shimon Cohen Arutz Sheva 4/7/2014 The threatened #opisrael cyber-attack turned out to be a dud – but Israel does not have enough manpower to ward off a major cyber-attack. Dr. Michael Orlov, head of the cyber-engineering department of Shamoon College Engineering in Be’er Sheva, explained the problem to Arutz Sheva Monday. As Orlov explained, the hacking projects against Israel by Anonymous – a loosely organized group of hackers worldwide, but for #opIsrael mostly localized to Middle-Eastern countries – is a childish attempt to “feel important,” and nothing more. Currently, cyber-attacks against Israel largely focus on replacing a site’s content with propaganda, and leaving a site alone after it is fixed. This, he said, “is not a serious problem.” Future attacks may be, however. Orlov emphasizes that if a major country – e.g. Iran – were to set aside the “relatively small amount” of $50 million dollars to establish a professional hacking team, Israel could be in trouble. “We have seen Iran do this in the past to other countries, like Saudi Arabia,” Orlov stated, “Hackers attacked, broke into [websites] and deleted information. If this happens, we cannot dismiss the impact of attacks.” [...]

Tags: , , , , , , , , ,
Tagged with: