What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
2018-07-12 19:54:20 | Your IoT security concerns are stupid (lien direct) | Lots of government people are focused on IoT security, such as this recent effort. They are usually wrong. It's a typical cybersecurity policy effort which knows the answer without paying attention to the question.Patching has little to do with IoT security. For one thing, consumers will not patch vulns, because unlike your phone/laptop computer which is all "in your face", IoT devices, once installed, are quickly forgotten. For another thing, the average lifespan of a device on your network is at least twice the duration of support from the vendor making patches available.Naive solutions to the manual patching problem, like forcing autoupdates from vendors, increase rather than decrease the danger. Manual patches that don't get applied cause a small, but manageable constant hacking problem. Automatic patching causes rarer, but more catastrophic events when hackers hack the vendor and push out a bad patch. People are afraid of Mirai, a comparatively minor event that led to a quick cleansing of vulnerable devices from the Internet. They should be more afraid of notPetya, the most catastrophic event yet on the Internet that was launched by subverting an automated patch of accounting software.Vulns aren't even the problem. Mirai didn't happen because of accidental bugs, but because of conscious design decisions. Security cameras have unique requirements of being exposed to the Internet and needing a remote factory reset, leading to the worm. While notPetya did exploit a Microsoft vuln, it's primary vector of spreading (after the subverted update) was via misconfigured Windows networking, not that vuln. In other words, while Mirai and notPetya are the most important events people cite supporting their vuln/patching policy, neither was really about vuln/patching.Such technical analysis of events like Mirai and notPetya are ignored. Policymakers are only cherrypicking the superficial conclusions supporting their goals. They assiduously ignore in-depth analysis of such things because it inevitably fails to support their positions, or directly contradicts them. IoT security is going to be solved regardless of what government does. All this policy talk is premised on things being static unless government takes action. This is wrong. Government is still waffling on its response to Mirai, but the market quickly adapted. Those off-brand, poorly engineered security cameras you buy for $19 from Amazon.com shipped directly from Shenzen now look very different, having less Internet exposure, than the ones used in Mirai. Major Internet sites like Twitter now use multiple DNS providers so that a DDoS attack on one won't take down their services.In addition, technology is fundamentally changing. Mirai attacked IPv4 addresses outside the firewall. The 100-billion IoT devices going on the network in the next decade will not work this way, cannot work this way, because there are only 4-billion IPv4 addresses. Instead, they'll be behind NATs or accessed via IPv6, both of which prevent Mirai-style worms from functioning. Your fridge and toaster won't connect via your home WiFi anyway, but via a 5G chip unrelated to your home.Lastly, focusing on the ven |
Hack Patching Guideline | NotPetya | |
|
2018-06-27 15:49:15 | Lessons from nPetya one year later (lien direct) | This is the one year anniversary of NotPetya. It was probably the most expensive single hacker attack in history (so far), with FedEx estimating it cost them $300 million. Shipping giant Maersk and drug giant Merck suffered losses on a similar scale. Many are discussing lessons we should learn from this, but they are the wrong lessons.An example is this quote in a recent article:"One year on from NotPetya, it seems lessons still haven't been learned. A lack of regular patching of outdated systems because of the issues of downtime and disruption to organisations was the path through which both NotPetya and WannaCry spread, and this fundamental problem remains." This is an attractive claim. It describes the problem in terms of people being "weak" and that the solution is to be "strong". If only organizations where strong enough, willing to deal with downtime and disruption, then problems like this wouldn't happen.But this is wrong, at least in the case of NotPetya.NotPetya's spread was initiated through the Ukraining company MeDoc, which provided tax accounting software. It had an auto-update process for keeping its software up-to-date. This was subverted in order to deliver the initial NotPetya infection. Patching had nothing to do with this. Other common security controls like firewalls were also bypassed.Auto-updates and cloud-management of software and IoT devices is becoming the norm. This creates a danger for such "supply chain" attacks, where the supplier of the product gets compromised, spreading an infection to all their customers. The lesson organizations need to learn about this is how such infections can be contained. One way is to firewall such products away from the core network. Another solution is port-isolation/microsegmentation, that limits the spread after an initial infection.Once NotPetya got into an organization, it spread laterally. The chief way it did this was through Mimikatz/PsExec, reusing Windows credentials. It stole whatever login information it could get from the infected machine and used it to try to log on to other Windows machines. If it got lucky getting domain administrator credentials, it then spread to the entire Windows domain. This was the primary method of spreading, not the unpatched ETERNALBLUE vulnerability. This is why it was so devastating to companies like Maersk: it wasn't a matter of a few unpatched systems getting infected, it was a matter of losing entire domains, including the backup systems.Such spreading through Windows credentials continues to plague organizations. A good example is the recent ransomware infection of the City of Atlanta that spread much the same way. The limits of the worm were the limits of domain trust relationships. For example, it didn't infect the city airport because that Windows domain is separate from the city's domains.This is the most pressing lesson organizations need to learn, the one they are ignoring. They need to do more to prevent desktops from infecting each other, such as through port-isolation/microsegmentation. They need to control the spread of administrative credentials within the organization. A lot of organizations put the same local admin account on every workstation which makes the spread of NotPetya style worms trivial. They need to reevaluate trust relationships between domains, so that the admin of one can't infect the others.These solutions are difficult, which is why news articles don't mention them. You don't have to know anything about security to proclaim "the problem is lack of patches". It's moral authority, chastising the weak, rather than a proscription of what to do. Solving supply chain hacks and Windows credential sharing, though, is hard. I don't know any universal solution to this -- I'd have to thoroughly analyze your network and business in order to | Ransomware Malware Patching | FedEx NotPetya Wannacry | |
 |
2018-03-07 18:41:05 | Technique Discovered That Can Mitigate Memcached DDoS Attacks (lien direct) | A mitigation mechanism is available for all victims who are under a DDoS attack carried out via Memcached servers. [...] | Patching | ★★★ | |
 |
2018-03-07 18:00:00 | Here\'s how Android P promises to protect your privacy (lien direct) | Android P could give even the most ardent iPhone fans a run for their money. | Patching | ★★★ | |
 |
2018-03-07 17:00:03 | Building an incident response program: creating the framework (lien direct) |
An incident response plan does not need to be overly complicated. However, having a solid and tested framework for the program is key in the ability of an organization to respond to and survive a security incident.
Categories:
101
Business
Tags: gdprGeneral Data Protection RegulationIncident Responseincident response frameworkincident response program
(Read more...)
|
Patching | ★★★ | |
 |
2018-02-28 14:59:00 | Intel Releases Updated Spectre Fixes For Broadwell and Haswell Chips (lien direct) | Intel has issued stable microcode to help protect its Broadwell and Haswell chips from the Spectre Variant 2 security exploits. | Patching | ||
 |
2014-07-16 23:41:20 | Foxit PDF Reader Stored XSS (lien direct) | A friend of mine was performing an external pentest recently and he started to complain that his traditional Java exploits were not being effective. He was able to map a few applications and defenses in place protecting the client's network but he still needed an initial access to start pivoting.Basic protections like AV, application white-listing as well as more advanced ones like EMET are used to make the life of criminals (and pentesters) harder, but they're often bypassed. While discussing alternatives with my friend, he told me that the company replaced Adobe Reader after seeing lots of Security Advisories for the product. And what was the replacement? Foxit Reader: Advisories for Adobe Reader and Foxit Reader listed on OSVDB (May/2014)Less advisories means that the product is more secure, right? Marc Ruef's talk about VDB management summarizes this point: The moment I head the word Foxit Reader I remembered of an old exploit I created a long time ago. The vulnerability wasn't that critical but I knew that it would fit for the situation (and for this blog post).As I was about to disclose it publicly I notified the vendor and waited for them to patch it. I had some problems with their security contact and had to mail them twice, but they answered after a couple of days, patching the product and releasing an advisory (no CVE is assigned for this vulnerability as the time of writing).Security Advisoryhttp://www.foxitsoftware.com/support/security_bulletins.php#FRD-21Fixed a security issue caused by the Stored XSS vulnerability when reading and displaying filenames and their paths on the “Recent Documents” section from the Start Page.SummaryFoxit Reader 6.2.1, Foxit Enterprise Reader 6.2.1, and Foxit PhantomPDF 6.2.1 fixed a security issue caused by the Stored XSS vulnerability when reading and displaying filenames and their paths on the “Recent Documents” section from the Start Page. Attackers could tamper with the registry entry and cause the application to load malicious files. When opening a PDF, Foxit creates a "FileX" registry entry with the document's complete path:[HKEY_CURRENT_USER\Software\Foxit Software\Foxit Reader 6.0\Recent File List]"File1"="C:\\w00t.pdf"Whenever you open a document, Foxit 6.x displays the start panel on a different tab by default. |
Malware Vulnerability Patching Guideline | ★★★★ | |
|
2014-02-18 09:43:31 | Analyzing Malware for Embedded Devices: TheMoon Worm (lien direct) | All the media outlets are reporting that Embedded Malware is becoming mainstream. This is something totally new and we never heard of this before, right? The high number of Linux SOHO routers with Internet-facing administrative interfaces, the lack of firmware updates and the ease to craft exploits make them a perfect target for online criminals. The Internet of Threats is wildly insecure, but definitely not unpatchable.To all infosec people out there, it's important to understand these threats and report it properly to the media. Some top-notch researchers recently uncovered "Massive Botnets" infecting refrigerators, microwaves, gaming consoles, soda machines and tamagotchis. The problem is that they never provided any sort of evidence, no malware samples, no IOC's and did not write a Hakin9 article describing it. Refrigerator Botnet? Revd. Pastor Laphroaig says Show the PoC || GTFOThe aim for this post is to provide more information to identify/execute embedded binaries, describing how to set your own virtual lab. In case you missed it, head to the first post from the "Analyzing and Running binaries from Firmware Images" series.TheMoon WormJohannes from SANS provided me a sample from "TheMoon" malware and posted some interesting information on their handler's diary. Their honeypots captured the scanning activity and linked the exploit to a vulnerable CGI script running on specific firmwares from the following Linksys routers: E4200, E3200, E3000, E2500, E2100L, E2000, E1550, E1500, E1200, E1000,E900.SANS handlers classified TheMoon as a Worm because of the self-replicating nature of the malware. The worm searches for a "HNAP1" URL to fingerprint and identify potentially vulnerable routers. If you check your FW and Server logs you may find lot's of different IP's probing this URL.The worm was named like this because it contains images from the movie "The Moon". It's possible to carve a few PNG's inside the ELF binary: Identifying the BinaryA total of seven different samples were provided: they all seem to be variants from the same malware due to the ssdeep matching score. |
Malware Vulnerability Patching | ★★★★ | |
|
2013-12-10 17:36:29 | Binwally: Directory tree diff tool using Fuzzy Hashing (lien direct) | For this post, I'll discuss about the concept of directory tree and binary diffing and how it could be used to find potential vulnerabilities and security issues that were (silently) patched on firmware images.Silent patching is a big deal as we don't have many security researchers like Spender around. This is a common practice among companies that create software and firmwares for embedded devices. Changelogs from new firmwares often contains few information about security issues, outlining the changes as "bugfixes" or "enhancements": we get no CVE's and we don't know how critical the flaws are.In addition to that, you may occasionally find some reference for the string 'Ac1db1tch3z' on your code (which means that you got a free vulnerability assessment) or your employee Joel might forget to remove a backdoor from the firmware. Diffing the content from previous firmwares may be useful to find out when these backdoors were first installed, modified and/or removed.I introduce you to Binwally: a simple script to perform directory tree diffing using the concept of Fuzzy Hashing (ssdeep) to define a matching score between binaries. Binwally says "no" to Silent PatchingFuzzy HashingFuzzy Hashing, also know as context triggered piecewise hashes (CTPH), can match inputs that have homologies. Such inputs have sequences of identical bytes in the same order, although bytes in between these sequences may be different in both content and length. The concept was introduced by Andrew Tridgell and the most well-known tool is ssdeep, created by Jesse Kornblum.The usage example outlined on ssdeep's homepage summarizes it well:$ ls -l foo.txt-rw-r--r-- 1 jessekor jessekor 240 Oct 25 08:01 foo.txt$ cp foo.txt bar.txt$ echo 1 >> bar.txtA cryptographic hashing algorithm like MD5 can't be used to match these files; they have wildly different hashes.$ md5deep foo.txt bar.txt7b3e9e08ecc391f2da684dd784c5af7c /Users/jessekornblum/foo.txt32436c952f0f4c53bea1dc955a081de4 /Users/jessekornblum/bar.txtBut fuzzy hashing can! We compute the fuzzy hash of one file and use the matching mode to match the other one.$ ssdeep -b foo.txt > hashes.txt$ ssdeep -bm hashes.txt bar.txtbar.txt matches foo.txt (64)The number at the end of the line is a match score, or a weighted measure of how similar these files are. The higher the number, the more similar the files.BinwallyBinwally is a simple Python script that uses this concept to diff directory trees in order to find different, unique and matching files, displaying an overall score of the results. It was based on diffall.py from the book Programming Python (4th Ed |
Tool Vulnerability Patching | ★★★★ |
To see everything:
Our RSS (filtrered)
