شماره: IRCNE2014062226
تاريخ:/04/93

با گذشت دو ماه از كشف مشكل Heartbleed، حداقل 300000 سرور هم چنان نسبت به اين مشكل، آسيب پذير هستند.
آسيب پذيري Heartbleed كه توسط محققان گوگل كشف شد، نگراني زيادي را ايجاد كرد. اين مساله امنيتي OpenSSL را تحت تاثير قرار داد و در صورتي كه مورد سوء استفاده قرار بگيرد مي تواند جزئيات حساب هاي ورودي و رمزهاي عبور را افشاء نمايد.
پس از آن كه اين مشكل در ماه آوريل به طور عمومي منتشر شد، محقق امنيتي Robert David Graham از شركت امنيتي Errata دريافت كه تقريبا 600000 سرور نسبت به اين حفره آسيب پذير مي باشند. يك ماه پس از افشاء، آسيب پذيري در نيمي از اين سرورها برطرف شد اما هم چنان 300000 سرور ديگر نسبت به اين مشكل، آسيب پذيري مي باشند.
يك محقق امنيتي اظهار داشت كه كاربران به روز رساني سيستم ها را متوقف كردند و روند اصلاح آسيب پذيري در سيستم ها به كندي انجام مي گيرد.
Graham معتقد است كه ده سال آينده نيز مي توان هزاران سيستم را پيدا كرد كه هم چنان نسبت به مشكل Heartbleed آسيب پذير مي باشند.

Number: IRCNE2014062226
Date: 2014-06-24

According to “zdnet”, two months after the Heartbleed bug was discovered, at least 300,000 servers remain vulnerable to the exploit.
Heartbleed, discovered by a Google engineer, caused widespread panic and a furious round of server patching by companies worldwide. The security kink impacts OpenSSL and, if exploited, can leak account login details and passwords.
Once Heartbleed was publicized, security researcher Robert David Graham from Errata Security found that roughly 600,000 servers were vulnerable to the security flaw. One month later, half of these servers had been patched and protected against Heartbleed, and only 318,239 were left exposed.
The security researcher says this stagnation means people have stopped even trying to patch systems, and there should be a "slow decrease" in the number of vulnerable systems as older servers are replaced.
"Even a decade from now, though, I still expect to find thousands of systems, including critical ones, still vulnerable," Graham says.

Number: IRCNE2014062225
Date: 2014-06-19

According to “techworld”, Less than three weeks after pushing Android 4.4.3 to users of its Nexus devices, Google released a new version of the OS that incorporates a patch for a serious vulnerability identified in the OpenSSL cryptographic library.
CVE-2014-0224 is the tracking number in the Common Vulnerabilities and Exposures (CVE) database for a serious security flaw found recently in OpenSSL, one of the most popular libraries for supporting the SSL (Secure Sockets Layer) and TLS (Transport Layer Security) secure communications protocols.
The CVE-2014-0224 vulnerability can be exploited by a man-in-the-middle attacker to decrypt and modify traffic between a client and a server that both use OpenSSL, if the server uses OpenSSL 1.0.1 or a newer version. The flaw was patched in OpenSSL 1.0.1h released on June 5.
According to a recent scan by security vendor Qualys, around 14 percent of the Internet's most popular 155,000 SSL-enabled websites are vulnerable to possible attacks exploiting CVE-2014-0224.

Number:IRCNE2014062224
Date: 2014-06-20

According to “computerworld”, as if tracking down bugs in a complex application isn't difficult enough, programmers now must worry about a newly emerging and potentially dangerous trap, one in which a program compiler simply eliminates chunks of code it doesn't understand, often without alerting the programmer of the missing functionality.
The code that can lead to this behavior is called optimization-unstable code, or "unstable code," though it is more of a problem with how compilers optimize code, rather than the code itself, said Xi Wang, a researcher at the Massachusetts Institute of Technology.
With unstable code, programs can lose functionality or even critical safety checks without the programmer's knowledge.
The researchers have developed a new technique for finding unstable code in C and C++ programs, called Stack, that they hope compiler makers will use when updating their products.
Using Stack, the research team has found over 160 bugs in various programs due to unstable code.
The research looked at 16 open source and commercial C/C++ compilers -- from companies such as Intel, IBM and Microsoft -- and had found they all dropped unstable code.
A compiler can issue warnings when it drops code, though compilers typically issue so many warnings, especially for large programs, that a notice of code being eliminated may be lost in the deluge of other largely inconsequential messages.
"I think compiler developers have known about this for years," Wang said.
Not all the blame should be placed on the compiler makers, noted Peng Wu, a researcher at Huawei America Labs who was at the presentation.
Wu noted that optimization was a chief priority for compiler makers in previous decades, when developers tried to get the best performance from the hardware as possible. Over the past decade however, has more attention been placed on finding bugs, due to the growing impact of security vulnerabilities, and so the problem of unstable code is now surfacing.

Number:IRCNE2014062223
Date: 2014-06-20

According to “zdnet”, no doubt there are still many vulnerable web sites and many more users who never changed their passwords from vulnerable web sites, and the consequences haven't been catastrophic.
The theory was that since so many sites were vulnerable for so long, you should (once the site patched OpenSSL) change your password on all of them. It's unlikely that a lot of sites were so-compromised and mined.
Few people would have bothered even if it were easy, but the fact remains that if you were following best practices with your passwords — making them complex and long and not reusing them, and using a password manager to make that all practical — changing all your potentially-vulnerable passwords is a daunting task. It has to be a manual, one site at a time thing.
When the Heartbleed smoke cleared I asked a couple of vendors about the problem and proposed a solution: a standard web API for changing site password, probably for use by password managers. The information you need to change a password — basically the URL, the userID and the old password — should all be accessible to the password manager.
Some of the potential problems, such as CAPTCHAs, are obvious, but I'd still think there is a way around them, if only through an authorization email to the account on record. Even if that email required you to follow a link and fill out a CAPTCHA it would still be far more automated for the user than if the whole process were manual.
But the vendors told me that they didn't think it could be done reliably. I still don't understand the problem, but they know a lot more about these things than I do, so I'm sure they're right. It's a damn shame.
Automation could also be useful in non-crisis situations. One of those best practices for passwords that nobody follows is to change your passwords periodically. A good password manager could track password age and, at a predetermined interval, offer to change site passwords. If it were an automatic process I would do it.
One person suggested to me that I was looking at it the wrong way, and that the answer to the password problem was OAuth. The official OAuth site defines it as an "authorization framework" which " enables a third-party application to obtain limited access to an HTTP service." This is like when a site offers to let you log in with your Facebook or Google account.
Even the user experience with OAuth can be confusing in my experience. I'm also uncomfortable using one of these big services as my identity on some of these other services. I like to maintain the maximum flexibility on them.
The biggest reason nothing has been done about the problem is that it's way down the list of things we need to do in order to make users more secure.
Very few users have proper password practices and industry attention is certainly best-directed to addressing that. Even so, I take the fact that the problem is so difficult as a sign of potential trouble in the future.

Number:IRCNE2014062222
Date: 2014-06-20

According to “zdnet”, Microsoft and Google announced on Thursday new features in their phone operating systems to combat smartphone theft.
Smartphone theft, known as "Apple picking" in some cases, has become a significant crime in some parts of the country. Law enforcement and prosecutors have been pressing the industry to institute a "kill switch" to disable stolen phones.
In response to the call, wireless industry group CTIA developed their Smartphone Anti-Theft Voluntary Commitment.
Microsoft's announcement notes that they committed in April to follow the CTIA's guidelines and that they will be meeting the commitment before the July 2015 deadline. When it is available, it "...will be offered as an update for all phones running Windows Phone 8.0 and newer, though availability is subject to mobile operator and phone manufacturer approval."
Microsoft has already met many of these goals with Windows Phone's Find My Phone feature, as we noted in a story last September. The same story described Android Device Manager, which also matches many of the CTIA feature commitments.
A Google spokesperson told ZDNet: "Yes, the next version of Android will include a factory reset protection solution to help deter smartphone theft. We will be releasing more details shortly."

شماره: IRCNE2014062224
تاريخ:29/03/93

از آن جايي كه يافتن مشكلات برنامه هاي كاربردي كار دشواري نيست، در حال حاضر برنامه نويسان بايد نگران ظهور تله هاي خطرناك بالقوه باشند. يك برنامه كامپايلر به راحتي مشكلات كد نويسي را ناديده مي گيرد و در بسايري از مواقع در خصوص خطاهاي عملياتي برنامه هشداري نمي دهد.
Xi Wang، محققي از مركز فناوري ماساچوست گفت: كدي كه در نتيجه اين فرآيند توليد مي شود را كد بي ثبات و ناپايدار مي نامند. با اين كدهاي ناپايدار، عملكرد برنامه ها كاهش مي يابد.
محققان راه جديدي را براي يافتن كدهاي ناپايدار در برنامه هاي C و C++ پيدا كردند و آن را Stack مي نامند و اميدوار هستند كه توليدكنندگان كامپايلر هنگام به روز رساني محصولات خود از اين تكنيك استفاده نمايند.
گروهي از محققان با استفاده از Stack توانستند بيش از 160 مشكل در رابطه با كد بي ثبات را در برنامه هاي مختلف پيدا كنند. هم چنين محققان كامپايلر 16 برنامه منبع باز و برنامه هاي تجاري C و C++ شركت هايي مانند اينتل، IBM و مايكروسافت را بررسي نمودند و دريافتند كه تمامي آن ها داراي كد ناپايدار مي باشند.
يك كامپايلر مي تواند هنگام يافتن كدهاي نامناسب هشدارهايي را نشان دهد و حتي برخي از آن ها هشدارهاي بي شماري را نشان مي دهند در نتيجه ممكن است برخي از اين هشدارها كه از اهميت بالاتري برخوردارند در ميان انبوه پيام هاي كم اهميت تر ديگر ناديده گرفته شوند.
Wang گفت: من فكر مي كنم توسعه دهندگان كامپايلر سال ها است كه از اين مساله اطلاع دارند.اگرچه تمامي تقصيرات را نمي توان به عهده توليدكنندگان كامپايلر گذاشت.
Wang اشاره كرد كه در دهه هاي گذشته بهينه سازي براي سازندگان كامپايلر از اولويت بالايي برخوردار بوده است. اگرچه در دهه هاي گذشته با توجه به افزايش آسيب پذيري هاي امنيتي، بيشترين توجه سازندگان براي يافتن مشكلات بوده است اما در حال حاضر كدهاي ناپايدار دغدغه اصلي سازندگان مي باشد.

شماره: IRCNE2014062225
تاريخ:29/03/93

تنها سه هفته پس از آن كه اندرويد نسخه 4.4.3 براي كاربران دستگاه هاي Nexus منتشر شد، شركت گوگل نسخه جديدي از اين سيستم عامل را براي اصلاح يك آسيب پذيري جدي شناخته شده در كتابخانه رمزگذاري OpenSSL منتشر كرد. اين به روز رساني مشكل CVE-2014-0224 را برطرف كرده است. CVE-2014-0224 شماره آسيب پذيري است كه اخيرا در OpenSSL كشف شده است.
آسيب پذيري CVE-2014-0224 مي تواند براي حملات MitM مورد سوء استفاده قرار بگيرد تا مهاجم بتواند ترافيك مابين يك سرور و يك كلاينتي كه از OpenSSL استفاده مي كنند را رمزگشايي نموده و آن را تغيير دهد. اين آسيب پذيري در سرورهايي كه از OpenSSL نسخه 1.0.1 يا نسخه هاي پس از آن استفاده مي كنند وجود دارد. اين حفره در OpenSSL 1.0.1h كه پنجم ژوئيه منتشر شد اصلاح شده است.
با توجه به تحقيقات اخير كه توسط شركت امنيتي Qualys صورت گرفته است، حدود 14 درصد از محبوب ترين وب سايت هايي كه از SSL استفاده مي كنند نسبت به حملات ناشي از سوء استفاده از حفره CVE-2014-0224 آسيب پذير مي باشند.

شماره: RCNE2014062223
تاريخ: 29/03/93

شكي نيست كه هم چنان بسياري از وب سايت ها نسبت به حفره Heartbleed آسيب پذير مي باشند و بسياري از كاربران نيز هرگز رمزهاي عبور خود را تغيير نداده اند و نتيجه اين كار فاجعه آميز خواهد بود.
از آن جايي كه بسياري از سايت ها براي مدت طولاني آسيب پذير بودند، در نتيجه شما بايد رمزهاي عبور خود را بر روي تماي سايت هايي كه OpenSSL خود را اصلاح كرده اند، تغيير دهيد.
اگر شما براي انتخاب رمزهاي عبور خود از بهترين راهكارهاي عملياتي انتخاب رمز عبور شامل انتخاب رمزهاي عبور پيچيده، عدم استفاده مجدد از رمزها و استفاده از برنامه هاي مديريت رمز عبور استفاده كرده باشيد، در نتيجه تغيير تمامي رمزهاي عبوري كه ممكن است به طور بالقوه آسيب پذير باشند، كاري سخت و دشوار است.
برخي از توليدكنندگان پس از افشاي آسيب پذيري Heartbleed پيشنهاد دادند كه كاربران براي تغيير رمزهاي عبور خود از يك API استاندارد و يا نرم افزارهاي مديريت رمز عبور استفاده نمايند. تمامي اطلاعاتي كه براي تغيير رمز عبور نياز داريد از قبيل URL، شناسه كاربر و رمز قديم بايد براي نرم افزار مديريت رمز عبور در دسترس باشد.
بسياري از مشكلات بالقوه مانند CAPTCHA مشهود است اما اگر اين فرآيند به صورت خودكار و از طريق آدرس ايميل و پيروي از لينك ارسال شده براي كاربر انجام گيرد بسيار راحت تر از زماني است كه تمامي فرآيند به صورت دستي انجام شود.
اما روال هاي خودكار بيشتر براي موقعيت هاي بحراني مفيد است. يكي از اين موارد در خصوص بررسي طول عمر رمز عبور توسط نرم افزارهاي مديريت رمز عبور و اعلام به كاربر براي تغيير رمز عبور خود مي باشد.
كاربران بسيار كمي هستند كه از رمزهاي عبور مناسب استفاده مي كنند و واقعيت آن است كه فرآيند دشوار تغيير دادن رمزهاي عبور و استفاده از رمزهاي عبور مناسب به عنوان يك مشكل بالقوه اي است كه درآينده خسارت هاي كلاني را به بار مي آورد.

شماره: IRCNE2014062222
تاريخ:29/03/93

شركت مايكروسافت و گوگل اعلام كردند كه براي مبارزه با سرقت گوشي هاي هوشمند، ويژگي هاي جديدي به سيستم عامل هاي اندرويد و ويندوز فون اضافه خواهد شد.
سرقت گوشي هاي هوشمند كه در برخي موارد به "برداشتن سيب" شناخته مي شوند، در برخي از كشورها يك جرم مهم محسوب مي شود.
رويه ها و الزامات قانوني، توليدكنندگان گوشي هوشمند را تحت فشار قرار مي دهند تا براي غيرفعال سازي گوشي هاي به سرقت رفته، يك " kill switch" در نظر بگيرند.
در پاسخ به اين درخواست، گروه صنعتي بي سيم CTIA، تهدنامه Smartphone Anti-Theft Voluntary Commitment را ايجاد كردند كه در آن يك سري الزامات سخت افزاري و نرم افزاري را كه توليدكنندگان سخت افزاري و نرم افزاري گوشي هاي هوشمند بايد رعايت كنند آورده شده است.
شركت مايكروسافت اعلام كرد كرد كه اين شركت در ماه آوريل، به راهنمايي هاي CTIA متعهد شده است. در نتيجه اين شركت يك به روز رساني براي تمامي گوشي هاي در حال اجراي ويندوز فون 8.0 و نسخه هاي بعد از آن منتشر خواهد كرد. اگرچه در حال حاضر بسياري از الزامات CTIA در نسخه هاي فعلي ويندوز فون رعايت مي شوند.
همين روال در خصوص سيستم عامل اندرويد نيز صادق است و اين سيستم عامل در حال حاضر بسياري از الزامات را رعايت مي كند. سخنگوي گوگل اظهار داشت: نسخه بعدي اندرويد شامل راه حل هاي حافظتي برگرداندن به تنظيمات اوليه كارخانه است كه بدين وسيله به حفاظت گوشي هوشمند در برابر سرقت كمك مي كند. اطلاعات كامل تر در اين باره در آينده منتشر خواهد شد.