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

تحليل آسيب پذيري :
اين آسيب پذيري امكان كنترل از راه دور را فراهم مي سازد و به مهاجمي كه داراي اطلاعات احراز هويت بوده اجازه مي دهد كه از راه دور كد دلخواه خود را بر روي نسخه آسيب پذير Gateway Symantec Web (SWG 5.2) اجرا نمايد. اين آسيب پذيري مرتبط با كدهاي CVE ، CVE-2013-5017، CVE-2014-1650، CVE-2014-1651، CVE-2014-1652 مي باشد.
آسيب پذيري مذكور در فايل user.php و snmpConfig.php وجود داشته و امكان اجراي حمله تزريق كد از طريق ارسال پارامترهاي آسيب پذير، دسترسي به كنسول مديريت نرم افزار و تغيير اطلاعات پايگاه داده نرم افزار وجود دارد.
مهاجم مي تواند با توسعه آسيب پذيري مذكور امكان خواندن فايل ها و اجراي كد از راه دور را توسط كاربر root ايجاد نمايد. برخي از صفحات گزارش دهي نرم افزار SWG در نسخه هاي 5.2 و قديمي تر، بصورت مناسب بر روي اطلاعات ورودي به نرم افزار تحليل و بررسي انجام نداده و امكان اجراي حمله blind sql injection را ميدهند. برخي از نسخه هاي نرم افزار در 5.1.x داراي آسيب پذيري XSS بوده كه منجر به سرقت نشست كاربران مي شود.
 

امن سازي نرم افزار:
شركت امنيتي سايمانتك، به روز رساني متناسب با آسيب پذيري را در نسخه 5.2.1 اعلام نموده است. بر اساس پيشنهادات ارايه شده توسط اين شركت، واسط SWG نبايد از طريق شبكه عمومي قابل دسترس باشد.

نسخه نرم افزارهاي آسيب پذير مي بايست از مسير ذيل به روز رساني گردد

Current Software Version -> Current Version
Administration->Updates

و يا

Administration->Updates-> Check for Updates

همچنين اين شركت راهكارهاي ايمن سازي ذيل را نيز پيشنهاد نموده است.

• محدودسازي دسترسي كاربران محدود به سيستمهاي مديريتي
• غيرفعالسازي امكان دسترسي از راه دور و يا محدودسازي آن به سيستم هاي مورد اعتماد
• محدودسازي دسترسي به برنامه كاربردي و واسط ها به شبكه ها و يا سيستم هاي مورد اعتماد
• به روز رساني تمامي سيستم ها و برنامه هاي كاربردي به آخرين نسخه ارايه شده توسط شركت
• اجراي خط مشي هاي امن سازي چندلايه اي شبكه، پياده سازي فايروال و نرم افزارهاي ضد بدافزار و سيستم هاي تشخيص نفوذ تحت شبكه و تحت سيستم

منابع خبر:

http://www.zerodayinitiative.com/advisories/ZDI-
http://www.symantec.com/security_response/securityupdates/detail.jsp?fid=security_advisory&pvid=sec…

شماره: IRCNE2014062227
تاريخ: 7/4/93

دو ماه پس از اصلاح آسيب‌پذيري‌هاي حياتي در Apache Struts كه يك فريم ورك مشهور متن‌باز براي توسعه برنامه‌هاي تحت وب مبتني بر جاوا است، VMWare يك اصلاحيه امنيتي براي ترميم‌هايي در محصول vCenter Operations Management Suite خود عرضه كرده است، ولي به نظر مي‌رسد كه همچنان يك اصلاحيه ديگر باقي مانده باشد.
vCenter Operations Management Suite مي‌تواند براي مانيتور كردن و مديريت كارآيي و بازدهي، ظرفيت و پيكربندي زيرساخت مجازي به كار رود. اين محصول در برخي از ويژگي‌هاي خود به Struts وابسته است.
روز سه‌شنبه و همزمان با عرضه vCenter Operations Management Suite (vCOps) نسخه 5.8.2، VMware در راهنمايي امنيتي خود نوشت كه كتابخانه Apache Struts به نسخه 2.3.16.2 به‌روز رساني شده است تا چندين مسأله امنيتي را برطرف كند.
Apache Struts 2.3.16.2 يك به‌روز رساني اورژانسي بود كه در 24 آوريل عرضه شده بود. اين به‌روز رساني پس از آن عرضه شد كه مشخص گرديد ترميم ارائه شده در Struts 2.3.16.1 براي يك آسيب‌پذيري اجراي كد از راه دور، كافي نبوده است و مي‌تواند دور زده شود.
اين مسأله به عنوان يك آسيب‌پذيري جداگانه و با شناسه CVE-2014-0112 مطرح شد و از آسيب‌پذيري اصلي با شناسه CVE-2014-0094 جدا گرديد.
vCOps 5.8.2 حاوي اصلاحيه‌اي براي يك آسيب‌پذيري انكار سرويس با شناسه CVE-2014-0050 بود كه بدواً در Struts 2.3.16.1 اصلاح شده بود.
VMware در راهنمايي امنيتي خود نوشت كه vCOps تحت تأثير دو آسيب‌پذيري CVE-2014-0112 و CVE-2014-0050 قرار دارد. سوء استفاده از آسيب‌پذيري CVE-2014-0112 مي‌تواند منجر به اجراي كد از راه دور بدون نياز به احراز هويت گردد.
به كاربران نسخه‌هاي قديمي‌تر vCOps 5.7.x توصيه مي‌شود كه محصول خود را به vCOps 5.8.2 ارتقاء داده يا اينكه به طور دستي گردش كاري توضيح داده شده در مقاله‌اي در VMware را اعمال نمايند.
محصول ديگر VMare يعني vCenter Orchestrator (VCO) نيز فقط تحت تأثير آسيب‌پذيري انكار سرويس (CVE-2014-0050) قرار دارد، ولي هنوز اصلاحيه‌اي براي آن عرضه نشده است.
توسعه دهندگان Struts پس از كشف اين موضوع كه اصلاحيه پيشين آنها تمامي سوء استفاده‌هاي ممكن را مسدود نمي‌كند، ترميم مجدد خود را براي CVE-2014-0094 و CVE-2014-0112 در Struts 2.3.16.3 جاي دادند كه در 3 مي عرضه شد.
اين ترميم جديد، يك آسيب‌پذيري با ريسك متوسط را پوشش مي‌داد كه مي‌تواند به مهاجمان اجازه دهد وضعيت دروني سشن‌ها و درخواست‌ها را دستكاري كنند. اين آسيب‌پذيري با شناسه CVE-2014-0116 شناسايي مي‌گردد.
از آنجايي كه vCOps تحت تأثير CVE-2014-0094 و CVE-2014-0112 قرار دارد، احتمال مي‌رود كه تحت تأثير CVE-2014-0116 نيز قرار داشته باشد، چرا كه تمامي اين آسيب‌پذيري‌ها از يك مسأله نشأت مي‌گيرند. به هر حال راهنمايي امنيتي جديد VMware هيچ اشاره‌اي به CVE-2014-0116 يا Struts 2.2.16.3 نكرده است.

ID: IRCNE2014062227
Date: 2014-06-28

According to “TechWorld”, Two months after critical vulnerabilities were patched in Apache Struts, a popular open-source framework for developing Java-based Web applications, VMware released a security update to incorporate the fixes in its vCenter Operations Management Suite product but appears to have left out a more recent patch.
The vCenter Operations Management Suite can be used to monitor and manage the performance, capacity and configuration of virtualized infrastructure. It depends on Struts for some of its features.
"The Apache Struts library is updated to version 2.3.16.2 to address multiple security issues," VMware said in a security advisory Tuesday that coincided with the release of vCenter Operations Management Suite (vCOps) version 5.8.2.
Apache Struts 2.3.16.2 was an emergency update released on April 24 after it was revealed that a fix included in Struts 2.3.16.1 for a remote code execution vulnerability was insufficient and could be bypassed.
The bypass was treated as a separate vulnerability and was assigned the CVE-2014-0112 tracking number, superseding the original issue known as CVE-2014-0094.
The vCOps 5.8.2 also incorporated a patch for a denial-of-service vulnerability tracked as CVE-2014-0050 that was also originally patched in Struts 2.3.16.1.
"VCOps is affected by both CVE-2014-0112 and CVE-2014-0050," VMware said in its advisory. "Exploitation of CVE-2014-0112 may lead to remote code execution without authentication."
Users of the older vCOps 5.7.x branch are advised to either upgrade to vCOps 5.8.2 or to manually apply a workaround described in a separate knowledge base article.
Another VMware product called vCenter Orchestrator (vCO) is affected only by the denial-of-service issue (CVE-2014-0050), but no patch has been released yet.
The Struts developers further improved their fix for CVE-2014-0094 and CVE-2014-0112 in Struts 2.3.16.3, released on May 3, after discovering that their previous patches still didn't cover all possible exploits.
The new fix addressed a medium-risk exploit that could have allowed attackers to manipulate the internal state of sessions and requests. The issue received the tracking number CVE-2014-0116.
Since vCOps was affected by CVE-2014-0094 and CVE-2014-0112, it's likely that it is also affected by CVE-2014-0116 since all three vulnerabilities stem from the same underlying problem. However, the new VMware advisory doesn't mention CVE-2014-0116 or Struts 2.3.16.3.

Number: IRCNE2014092318
Date: 2014-09-17

According to “zdnet”, Adobe has released security updates for Reader and Acrobat addressing eight vulnerabilities in both the Windows and Mac versions. The affected versions are Reader and Acrobat X 10.1.11 and earlier and Reader and Acrobat XI 11.0.08 for Windows and Mac.
The updates were originally scheduled to be released a week ago, but were delayed due to problems in testing.
The new versions are Reader and Acrobat X 10.1.12 and Reader and Acrobat XI 11.0.09 for Windows and Mac. Individual users may apply the updates using the "Check for Updates" option on the Help menu.
Several of the vulnerabilities are critical and could result in the attacker taking over the system in the context of the user if the user opens a malicious PDF.

ID: IRCNE2014092320
Date: 2014-09-17

According to “TechWorld”, the default browser in Android versions older than 4.4 has a vulnerability that allows malicious websites to bypass a critical security mechanism and take control of a user's authenticated sessions on other sites.
The issue is a universal cross-site scripting flaw that stems from how the browser handles javascript: strings preceded by a null byte character. When encountering such a string, the browser fails to enforce the same-origin policy, a security control that prevents scripts running in the context of one site from interacting with the content of other websites.
"What this means is, any arbitrary website (say, one controlled by a spammer or a spy) can peek into the contents of any other web page," said Tod Beardsley, technical lead for the Metasploit Framework project, in a blog post Monday. "Imagine you went to an attacker's site while you had your webmail open in another window -- the attacker could scrape your e-mail data and see what your browser sees. Worse, he could snag a copy of your session cookie and hijack your session completely, and read and write webmail on your behalf."
The security flaw was discovered by independent security researcher Rafay Baloch, who published a proof-of-concept exploit on his blog Aug. 31. However, the bug's disclosure remained largely unnoticed until the Metasploit team developed a module that can be used to steal authentication cookies from users who open a malicious page.
Users who believe they might be affected are advised to install and use one of the other browsers available for Android such as Google Chrome, Mozilla Firefox, Dolphin Browser or Opera, which are not affected by this issue.

شماره: 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.