Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity

October 7, 2019

TLP:GREEN Leak to Lossen Your Bowels

Filed under: Classification,Government,Security — Patrick Durusau @ 4:45 pm

Zak Doffman in FBI Issues Surprise New Cyber Attack Warning posted a link to: Cyber Criminals Use Social Engineering and Technical Attacks to Circumvent Multi-Factor Authentication, which is clearly marked:

TLP:GREEN:

This PIN has been released TLP:GREEN: The information in this product is useful for the awareness of all participating organizations within their sector or community, but should not be shared via publicly accessible channels.

Do you think Forbes.com qualifies as a “publicly accessible channel?”

I ask just to highlight the absurdity of information restriction that has taken over government and cybersecurity in general. Notice that the evils doers in this scenario are already informed and the only people left uninformed, are members of the public.

I’m sure someone at the FBI has the authority to assign TPL:GREEN classification, but not anything lower or higher, plus they have auditing routines to check their work, monthly reports, etc. Now imagine all the turf protection and routines that must go on for other security classifications. All to hide information from the voting public.

Ask your 2020 candidates to sweep away all but launch code and location of nuclear submarine secrecy. It’s not like a modern army can conceal its intentions to invade. Think of all the classification staff that will become availabe to fill the front ranks.

March 30, 2019

ARM Assembly Basics

Filed under: ARM,Assembly,Cybersecurity,Hacking,Security — Patrick Durusau @ 8:51 pm

ARM Assembly Basics by Azeria.

Why ARM?:

This tutorial is generally for people who want to learn the basics of ARM assembly. Especially for those of you who are interested in exploit writing on the ARM platform. You might have already noticed that ARM processors are everywhere around you. When I look around me, I can count far more devices that feature an ARM processor in my house than Intel processors. This includes phones, routers, and not to forget the IoT devices that seem to explode in sales these days. That said, the ARM processor has become one of the most widespread CPU cores in the world. Which brings us to the fact that like PCs, IoT devices are susceptible to improper input validation abuse such as buffer overflows. Given the widespread usage of ARM based devices and the potential for misuse, attacks on these devices have become much more common.
Yet, we have more experts specialized in x86 security research than we have for ARM, although ARM assembly language is perhaps the easiest assembly language in widespread use. So, why aren’t more people focusing on ARM? Perhaps because there are more learning resources out there covering exploitation on Intel than there are for ARM. Just think about the great tutorials on Intel x86 Exploit writing by Fuzzy Security or the Corelan Team – Guidelines like these help people interested in this specific area to get practical knowledge and the inspiration to learn beyond what is covered in those tutorials. If you are interested in x86 exploit writing, the Corelan and Fuzzysec tutorials are your perfect starting point. In this tutorial series here, we will focus on assembly basics and exploit writing on ARM.

Written in the best tradition of sharing technical knowledge and skill, this is your ticket to over 100 billion ARM powered devices. Not all of them of interest and/or vulnerable, but out of 100 billion (higher now) you will be kept busy.

Enjoy!

March 29, 2019

Pentagon Adopts Hostile Adoption Strategy

Filed under: Cybersecurity,FBI,Government,Hacking,Security — Patrick Durusau @ 10:44 am

Pentagon’s Multibillion-Dollar DEOS Contract is Guaranteed for Microsoft

High-five traffic saturated networks between groups of North Korean, Chinese and Russian hackers when they read:

In the coming weeks, the Pentagon—through its partner, the General Services Administration—will bid out a cloud-based contract for enterprisewide email, calendar and other collaboration tools potentially worth as much as $8 billion over the next decade.


Yet former defense officials, contracting analysts and industry experts tell Nextgov the Defense Enterprise Office Solutions contract is one that tech giant Microsoft—with its Office 365 Suite—simply cannot lose.

Yes, the Pentagon, through a variety of bidders, all of who offer Microsoft based solutions, is adopting a hostile adoption strategy, described as:

According to Defense Department spokeswoman Elissa Smith, the intent is for DEOS to replace all the disparate, duplicative collaboration tools Defense Department agencies use around the world. Components, including the Army, Navy and Air Force, “will be required” to use the same cloud-based business tools.

“It is expected that DEOS will be designated as an enterprise solution for DOD-wide adoption and organizations,” Smith told Nextgov. “Components that have already implemented different solutions with similar functionality will be required to migrate to DEOS.”

You may remember how successful the FBI Virtual Case File project was, $170 million in the toilet, where local FBI offices were to be “forced” to migrate to a new system. Complete and utter failure.

Undeterred by previous government IT failures, the Pentagon is upping the stakes 47 X the losses in the FBI Virtual Case File project and, even more importantly, risking national security on hostile adoption of an unwanted product.

If that weren’t bad enough, the Office 365 Suite offers a security single point of failure (SPOF). Once the system is breached for one instance, it has been breached for all. Hackers can now abandon their work on other systems and concentrate on Microsoft alone. (A thanks on their behalf to the Pentagon.)

Hackers are unlikely to take up my suggestion because an eight year slog to complete failure leaves non-Microsoft systems in operation during and past the project’s failure date. Not to mention that a hostile transition to an unwanted system is likely to leave openings for exploitation. Happy hunting!

November 20, 2018

Do Your Clients Know You’re Running Adobe Flash?

Filed under: Cybersecurity,Hacking,Security — Patrick Durusau @ 5:28 pm

Critical Adobe Flash Bug Impacts Windows, macOS, Linux and Chrome OS by Tom Spring.

From the post:

Adobe released a patch for a critical flaw on Tuesday that leaves its Flash Player vulnerable to arbitrary code execution by an adversary. Affected are versions of the Flash Player running on Windows, macOS, Linux and Chrome OS.

Unless you need the technical details to prepare an exploit, that’s about all that needs to be said about the latest Adobe Flash fail.

You aren’t running Flash? Yes?

Assuming you are not running Flash, download and save a known to be safe Flash file. Attach it to an email to your current contractor(s).

Call your contractor(s) and ask if they can open the attached Flash file. Should they say yes, start looking for new contractor(s).

What are you going to say when you get a “can you open the Flash attachment” call?

PS: I wonder if any of the techno-mages at the White House are running Flash? Thoughts?

November 15, 2018

Fake ‘Master’ Fingerprints

Filed under: Artificial Intelligence,Security — Patrick Durusau @ 3:20 pm

DeepMasterPrints: Generating MasterPrints for Dictionary Attacks via Latent Variable Evolution by Philip Bontrager et al.

Abstract:

Recent research has demonstrated the vulnerability of fingerprint recognition systems to dictionary attacks based on MasterPrints. MasterPrints are real or synthetic fingerprints that can fortuitously match with a large number of fingerprints thereby undermining the security afforded by fingerprint systems. Previous work by Roy et al. generated synthetic MasterPrints at the feature-level. In this work we generate complete image-level MasterPrints known as DeepMasterPrints, whose attack accuracy is found to be much superior than that of previous methods. The proposed method, referred to as Latent Variable Evolution, is based on training a Generative Adversarial Network on a set of real fingerprint images. Stochastic search in the form of the Covariance Matrix Adaptation Evolution Strategy is then used to search for latent input variables to the generator network that can maximize the number of impostor matches as assessed by a fingerprint recognizer. Experiments convey the efficacy of the proposed method in generating DeepMasterPrints. The underlying method is likely to have broad applications in fingerprint security as well as fingerprint synthesis.

One review of this paper concludes:


At the highest level of security, the researchers note that the master print is “not very good” at spoofing the sensor—the master prints only fooled the sensor less than 1.2 percent of the time.

While this research doesn’t spell the end of fingerprint ID systems, the researchers said it will require the designers of these systems to rethink the tradeoff between convenience and security in the future.

But fingerprint ID systems are only one use case for DeepMasterPrints.

The generated fingerprints, for all intents and purposes, appear to be human fingerprints. If used to intentionally “leave” fingerprints for investigators to discover, there is no immediate “tell” these are artificial fingerprints.

If your goal is to delay or divert authorities for a few hours or even days with “fake” fingerprints, then DeepMasterPrints may be quite useful.

The test for any security or counter-security measure isn’t working forever or without fail but only for as long as needful. (For example, encryption that defeats decryption until after an attack has served its purpose. It need not do more than that.)

October 10, 2018

Passwords: Philology, Security, Authentication

Filed under: Cryptography,Humanities,Security — Patrick Durusau @ 4:29 pm

Passwords: Philology, Security, Authentication by Brian Lennon.

Disclaimer: I haven’t seen Passwords, yet, but it’s description and reviews prompted me to mention it here.

That and finding an essay with the same titie, verbatim, by the same author, published in Diacritics, Volume 43.1 (2015) 82-104. Try: Passwords: Philology, Security, Authentication. (Hosted on the Academia site so you will need an account (free) to download the essay (also free).

From the publisher:

Cryptology, the mathematical and technical science of ciphers and codes, and philology, the humanistic study of natural or human languages, are typically understood as separate domains of activity. But Brian Lennon contends that these two domains, both concerned with authentication of text, should be viewed as contiguous. He argues that computing’s humanistic applications are as historically important as its mathematical and technical ones. What is more, these humanistic uses, no less than cryptological ones, are marked and constrained by the priorities of security and military institutions devoted to fighting wars and decoding intelligence.

Lennon’s history encompasses the first documented techniques for the statistical analysis of text, early experiments in mechanized literary analysis, electromechanical and electronic code-breaking and machine translation, early literary data processing, the computational philology of late twentieth-century humanities computing, and early twenty-first-century digital humanities. Throughout, Passwords makes clear the continuity between cryptology and philology, showing how the same practices flourish in literary study and in conditions of war.

Lennon emphasizes the convergence of cryptology and philology in the modern digital password. Like philologists, hackers use computational methods to break open the secrets coded in text. One of their preferred tools is the dictionary, that preeminent product of the philologist’s scholarly labor, which supplies the raw material for computational processing of natural language. Thus does the historic overlap of cryptology and philology persist in an artifact of computing—passwords—that many of us use every day.

Reviews (from the website):

Passwords is a fascinating book. What is especially impressive is the author’s deft and knowing engagements with both the long histories of computational text processing and the many discourses that make up literary philology. This is just the sort of work that the present mania for the digital demands, and yet books that actually live up to those demands are few and far between. Lennon is one of the few scholars who is even capable of managing that feat, and he does so here with style and erudition.”—David Golumbia, Virginia Commonwealth University

“A stunning intervention, Passwords rivets our attention to the long history of our present fascination with the digital humanities. Through a series of close, contextual readings, from ninth-century Arabic philology and medieval European debates on language to twentieth-century stylometry and machine translation, this book recalls us to a series of engagements with language about which ‘all of us—we scholars, we philologists,’ as Lennon puts it, ought to know more. Passwords is eloquent and timely, and it offers a form of deep, institutional-lexical study, which schools us in a refusal to subordinate scholarship in the humanities to the identitarian and stabilizing imperatives of the national-security state.”—Jeffrey Sacks, University of California, Riverside

Not surprisingly, I think a great deal was lost when humanities, especially those areas focused on language, stopped interacting with computer sciences. Sometime after the development of the first compilers but I don’t know that history in detail. Suggested reading?

October 9, 2018

Weapon Systems Cybersecurity:… [Opportunity Knocks!]

Filed under: Cybersecurity,Hacking,Military,Security — Patrick Durusau @ 4:14 pm

Weapon Systems Cybersecurity: DOD Just Beginning to Grapple with Scale of Vulnerabilities

From the webpage:

The cited reason for the “fictitious weapon system” is “classification reasons.”

Maybe, but identifying weaknesses in named weapon systems, encourages use of those security flaws as excuses for flaws in other systems. “Everybody has flaw ….. You can’t penalize me for a market standard flaw.”

Under the section title: Test Teams Easily Took Control (page 22):


Test teams were able to defeat weapon systems cybersecurity controls meant to keep adversaries from gaining unauthorized access to the systems. In one case, it took a two-person test team just one hour to gain initial access to a weapon system and one day to gain full control of the system they were testing. Some programs fared better than others. For example, one assessment found that the weapon system satisfactorily prevented unauthorized access by remote users, but not insiders and near-siders. Once they gained initial access, test teams were often able to move throughout a system, escalating their privileges until they had taken full or partial control of a system. In one case, the test team took control of the operators’ terminals. They could see, in real-time, what the operators were seeing on their screens and could manipulate the system. They were able to disrupt the system and observe how the operators responded. Another test team reported that they caused a pop-up message to appear on users’ terminals instructing them to insert two quarters to continue operating. Multiple test teams reported that they were able to copy, change, or delete system data including one team that downloaded 100 gigabytes, approximately 142 compact discs, of data.

For “security” reasons none of the systems were named, guranteeing the same failing vendors in the same congressional districts will continue to produce failing weapon systems.

Not only does opportunity knock for present US weapon systems, but additional opportunities await in every country where such systems are sold.

Remember, “…one hour to gain initial access … one day to gain full control….” If that’s not opportunity, I don’t know what is.

September 28, 2018

LoJax – Coming to a Corporation/Government Near You!

Filed under: Cybersecurity,Government,Hacking,Security — Patrick Durusau @ 8:58 pm

Cybersecurity Researchers Spotted First-Ever UEFI Rootkit in the Wild by Swati Khandelwal.

From the post:

Cybersecurity researchers at ESET have unveiled what they claim to be the first-ever UEFI rootkit being used in the wild, allowing hackers to implant persistent malware on the targeted computers that could survive a complete hard-drive wipe.

Dubbed LoJax, the UEFI rootkit is part of a malware campaign conducted by the infamous Sednit group, also known as APT28, Fancy Bear, Strontium, and Sofacy, to target several government organizations in the Balkans as well as in Central and Eastern Europe.

Operating since at least 2007, Sednit group is a state-sponsored hacking group believed to be a unit of GRU (General Staff Main Intelligence Directorate), a Russian secret military intelligence agency. The hacking group has been associated with a number of high profile attacks, including the DNC hack just before the U.S. 2016 presidential election.

UEFI, or Unified Extensible Firmware Interface, a replacement for the traditional BIOS, is a core and critical firmware component of a computer, which links a computer’s hardware and operating system at startup and is typically not accessible to users.

Khandelwal has a great explanation of LoJax with pointers to more detailed information.

At present the result of governmental development, it’s not unreasonable to expect LoJax to become commodity malware in a period of a year or two, perhaps less. Not unlike the first atomic bomb. The first one was true research, the second one and following, were matters of engineering.

Any number of governments and corporations merit being gifted with installations of LoJax.

Watching the anti-woman antics in the US Senate this week, made me think of several likely targets.

September 20, 2018

New Hacking Challenge: CLIP OS (French Cybersecurity OS)

Filed under: Cybersecurity,Hacking,Security — Patrick Durusau @ 2:44 pm

French cyber-security agency open-sources CLIP OS, a security hardened OS by Catalin Cimpanu.

From the post:

The National Cybersecurity Agency of France, also known as ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information), has open-sourced CLIP OS, an in-house operating system its engineers had developed to address the needs of the French government administration.

In a press release, ANSSI described CLIP OS as a “Linux-based operating system [that] incorporates a set of security mechanisms that give it a very high level of resistance to malicious code and allow it to protect sensitive information.”

More details are available at The CLIP OS Project, including version 4 (current release, documentation in French), and version 5 (alpha version, documentation in English).

The lack of a build version makes me wonder the breadth of CLIP OS deployment. Within ANSSI or the French government more generally.

Not that you want to rely on security by obscurity, but if CLIP OS is a substantial security advance over comparable systems, why open source it?

The open source motivation could be to boost a French vendor has a commercial product along similar lines. Perhaps former members of the ANSSI?

In any event, enjoy getting the CLIP OS up and running as preparation to finding its soft spots.

Free CCTV Surveillance Camera Networks

Filed under: Cybersecurity,Hacking,Security — Patrick Durusau @ 12:51 pm

You don’t get to pick the locations but as Tom Spring details in: Zero-Day Bug Allows Hackers to Access CCTV Surveillance Cameras, not only can you take over up to 800,000 existing CCTV cameras with the bugs discussed, all those cameras will require a manual upgrade.

Hard to imagine a greater deterrent to upgrading than requiring manual upgrading of each and every camera.

From the post:


The first vulnerability (CVE-2018-1149) is the zero-day. Attacker can sniff out affected gear using a tool such as Shodan. Next, the attacker can trigger a buffer-overflow attack that allows them to access the camera’s web server Common Gateway Interface (CGI), which acts as the gateway between a remote user and the web server. According to researchers, the attack involves delivering a cookie file too large for the CGI handle. The CGI then doesn’t validate user’s input properly, allowing them to access the web server portion of the camera. “[A] malicious attackers can trigger stack overflow in session management routines in order to execute arbitrary code,” Tenable wrote.

The second bug (CVE-2018-1150) takes advantage of a backdoor functionality in the NUUO NVRMini2 web server. “[The] back door PHP code (when enabled) allows unauthenticated attacker to change a password for any registered user except administrator of the system,” researchers said.

Which CCTV surveillance camera networks do you have control of? (Rhetorical question. Don’t answer! Bad OpSec.)

September 4, 2018

Penetration Testing / OSCP Biggest Reference Bank

Filed under: Cybersecurity,Security — Patrick Durusau @ 12:38 pm

Penetration Testing / OSCP Biggest Reference Bank by OlivierLaflamme (Boschko)

Forty-three (43) penetration cheatsheets as of today (4 September 2018), all dating from August 1, 2018.

Opportunity to grab cheatsheets and to contribute back to the community with comments and suggestions.

Note the difference between some communities of hackers and white-hat hackers, who practice secrecy and non-sharing. That’s the real advantage in cybersecurity matters.

Enjoy!

I first saw this in a tweet by Catalin Cimpanu.

August 3, 2018

Red Team Tips

Filed under: .Net,Cybersecurity,Hacking,Security — Patrick Durusau @ 2:11 pm

Red Team Tips by Vincent Yiu.

Overview:

The following “red team tips” were posted by myself, Vincent Yiu (@vysecurity) over Twitter for about a year. This is still on-going but I took the opportunity to publish these in one solidified location on my blog. These will be updated ocassionally, but will not be bleeding edge updates. To receive my “red team tips”, thoughts, and ideas behind Cyber attack simulations, follow my Twitter account @vysecurity.

For the full Tweet and thread context (a lot of my followers will comment and give their insights also), visit Twitter.

Collection of three hundred and twenty-nine (329) red team (is there another kind?) tips!

Great way to start the weekend!

Enjoy!

July 29, 2018

When Phishing and “Dropped” USB Fails – Precision Issues in Graphic Libraries

Filed under: Cybersecurity,Security,Subject Identity — Patrick Durusau @ 3:10 pm

Drawing Outside the Box: Precision Issues in Graphic Libraries by Mark Brand and Ivan Fratric, Google Project Zero.

From the post:

In this blog post, we are going to write about a seldom seen vulnerability class that typically affects graphic libraries (though it can also occur in other types of software). The root cause of such issues is using limited precision arithmetic in cases where a precision error would invalidate security assumptions made by the application.

While we could also call other classes of bugs precision issues, namely integer overflows, the major difference is: with integer overflows, we are dealing with arithmetic operations where the magnitude of the result is too large to be accurately represented in the given precision. With the issues described in this blog post, we are dealing with arithmetic operations where the magnitude of the result or a part of the result is too small to be accurately represented in the given precision.

These issues can occur when using floating-point arithmetic in operations where the result is security-sensitive, but, as we’ll demonstrate later, can also occur in integer arithmetic in some cases.

With phishing success rates reported at 90% and the commonly cited 50% of all users who would insert a “found” USB drive in their computer, use of high end hacks is always a fall back position.

The techniques discussed here will be useful for such fall back cases but, the more interesting question to me comes in the conclusion:


When it comes to finding such issues, unfortunately, there doesn’t seem to be a great way to do it. When we started looking at Skia, initially we wanted to try using symbolic execution on the drawing algorithms to find input values that would lead to drawing out-of-bounds, as, on the surface, it seemed this is a problem symbolic execution would be well suited for. However, in practice, there were too many issues: most tools don’t support floating point symbolic variables and, even when running against just the integer parts of the simplest line drawing algorithm, we were unsuccessful in completing the run in a reasonable time (we were using KLEE with STP and Z3 backends).

In the end, what we ended up doing was a combination of the more old-school methods: manual source review, fuzzing (especially with values close to image boundaries) and, in some cases, when we already identified potentially problematic areas of code, even bruteforcing the range of all possible values.

Do you know of other instances where precision errors resulted in security issues? Let us know about them in the comments.

What set of subject identity criteria would enable rough indentification of these issues?

Thoughts?

July 18, 2018

Is the GRU Running Windows 10?

Filed under: Cybersecurity,Microsoft,Security — Patrick Durusau @ 7:44 pm

I ask if the GRU is running Windows 10 in part because of the fanciful indictment of twelve Russians that presumes key logging on GRU computers.

That and I saw: Exploiting a Windows 10 PagedPool off-by-one overflow (WCTF 2018), today.

From the post:

My contribution to the above result was a flag for the “Searchme” task authored by Eat, Sleep, Pwn, Repeat. It involved the exploitation of an off-by-one buffer overflow of a PagedPool allocation made by a vulnerable kernel driver loaded in Windows 10 64-bit. Shortly after the CTF, the original author (@_niklasb) published the source code of the driver and the corresponding exploit (see niklasb/elgoog on GitHub and discussion on Twitter), which revealed that my solution was partially unintended. Niklas used the off-by-one to corrupt allocation metadata and performed some pool feng-shui to get overlapping pool chunks. On the other hand, I achieved a similar outcome through a data-only attack without touching any pool metadata, which made the overall exploitation process somewhat simpler. I encourage you to closely analyze Niklas’ exploit, and if you’re interested in my approach, follow along.

If you want to jump straight to the exploit code, find it on GitHub.

Beyond my current skill level but a good example to follow for improving the same.

Aside to the GRU: Software compiled by others is untrustworthy. All cases, no exceptions. Consider Linux.

June 11, 2018

Speaking of Being Vulnerable: Tor Browser 7.5.5 and 8.0a8 released!

Filed under: Cybersecurity,Security,Tor — Patrick Durusau @ 10:03 am

Tor Browser 7.5.5 is released (stable)

Tor Browser 8.0a8 is released (experimental)

BTW, if you want to use Tor in more than name only, follow these instructions (no exceptions):

Want Tor to really work?

You need to change some of your habits, as some things won’t work exactly as you are used to.

  1. Use Tor Browser

    Tor does not protect all of your computer’s Internet traffic when you run it. Tor only protects your applications that are properly configured to send their Internet traffic through Tor. To avoid problems with Tor configuration, we strongly recommend you use the Tor Browser. It is pre-configured to protect your privacy and anonymity on the web as long as you’re browsing with Tor Browser itself. Almost any other web browser configuration is likely to be unsafe to use with Tor.

  2. Don’t torrent over Tor

    Torrent file-sharing applications have been observed to ignore proxy settings and make direct connections even when they are told to use Tor. Even if your torrent application connects only through Tor, you will often send out your real IP address in the tracker GET request, because that’s how torrents work. Not only do you deanonymize your torrent traffic and your other simultaneous Tor web traffic this way, you also slow down the entire Tor network for everyone else.

  3. Don’t enable or install browser plugins

    Tor Browser will block browser plugins such as Flash, RealPlayer, Quicktime, and others: they can be manipulated into revealing your IP address. Similarly, we do not recommend installing additional addons or plugins into Tor Browser, as these may bypass Tor or otherwise harm your anonymity andprivacy.

  4. Use HTTPS versions of websites

    Tor will encrypt your traffic to and within the Tor network, but the encryption of your traffic to the final destination website depends upon on that website. To help ensure private
    encryption to websites, Tor Browser includes HTTPS Everywhere to force the use of HTTPS encryption with major websites that support it. However, you should still watch the browser URL bar to ensure that websites you provide sensitive information to display a blue or green URL bar button, include https:// in the URL, and display the proper expected name for the website. Also see EFF’s interactive page explaining how Tor and HTTPS relate.

  5. Don’t open documents downloaded through Tor while online

    Tor Browser will warn you before automatically opening documents that are handled by external applications. DO NOT IGNORE THIS WARNING. You should be very careful when downloading documents via Tor (especially DOC and PDF files, unless you use the PDF viewer that’s built into Tor Browser) as these documents can contain Internet resources that will be downloaded outside of Tor by the application that opens them. This will reveal your non-Tor IP address. If you must work with DOC and/or PDF files, we strongly recommend either using a disconnected computer, downloading the free VirtualBox and using it with a virtual machine image with networking disabled, or using Tails. Under no circumstances is it safe to use BitTorrent and Tor together, however.

  6. Use bridges and/or find company

    Tor tries to prevent attackers from learning what destination websites you connect to. However, by default, it does not prevent somebody watching your Internet traffic from learning that you’re using Tor. If this matters to you, you can reduce this risk by configuring Tor to use a Tor bridge relay rather than connecting directly to the public Tor network. Ultimately the best protection is a social approach: the more Tor users there are near you and the more diverse their interests, the less
    dangerous it will be that you are one of them. Convince other people to use Tor, too!

Be smart and learn more. Understand what Tor does and does not offer. This list of pitfalls isn’t complete, and we need your help identifying and documenting all the issues.

Volunteer, donate, spread the word about the Tor project! The privacy you protect, could well be your own!

Zip Slip – Universal Government Vulnerability?

Filed under: Cybersecurity,Security — Patrick Durusau @ 9:25 am

Zip Slip vulnerability affects thousands of projects by Zeljka Zorz.

From the post:


The vulnerability, dubbed Zip Slip by the researchers, has been seen in the past before, but was never this widely spread, Snyk CEO Guy Podjarny told Help Net Security.

“Zip Slip is a form of directory traversal that can be exploited by extracting files from an archive. The premise of the directory traversal vulnerability is that an attacker can gain access to parts of the file system outside of the target folder in which they should reside,” the company explained.

“The vulnerability is exploited using a specially crafted archive that holds directory traversal filenames (e.g. ../../evil.sh). The two parts required to exploit this vulnerability is a malicious archive and extraction code that does not perform validation checking.”

There is a list of vulnerable libraries/apps, good for checking versions to discover failures to update. For the technical details, see: Zip Slip Vulnerability.

A large number of libraries have been updated but effectiveness of those updates depends upon projects in the wild updating the libraries they use.

Considering the sluggishness of government IT operations, Zip Slip may be a universal government vulnerability even in the face of updated libraries.

Nothing ventured, nothing gained. The worse case scenario for attackers is the attack fails.

May 9, 2018

Increasing Your Security (As Opposed to Thinking You Are Secure)

Filed under: Cybersecurity,Security,Tails,Tor — Patrick Durusau @ 8:36 pm

You can increase your security, against known hazards/bugs, by installing and using:

along with other appropriate practices and cautions.

Bear in mind that no software or encryption scheme is a defense against a $5 wrench.

May 8, 2018

2,000+ New Egyptian Hieroglyphs Coming Soon! [Code Talker Security?]

Filed under: Hieroglyphics,Security — Patrick Durusau @ 7:37 pm

Soon You May Be Able to Text with 2,000 Egyptian Hieroglyphs by Sarah E. Bond.

From the post:

Collaborations among Egyptologists and digital linguistics promise global visualizations of what was written on inscriptions, papyri, wall paintings, and other sources of Hieroglyphs. It may also allow for more popular knowledge of Egyptian Hieroglyphs and encourage its assimilation into popular language-learning apps like Duolingo.

Over 2,000 new Hieroglyphs may soon be available for use on cell phones, computers, and other digital devices. The Unicode Consortium recently released a revised draft of standards for encoding Egyptian Hieroglyphs. If approved, the available Hieroglyphs will provide greater access and global uniformity for Egyptologists, covering a much longer period of Hieroglyphic usage than ever before. The proposal is part of a larger effort between the Unicode Consortium, ancient linguists, font designers, and the federal government to attempt to study, preserve, and then digitally represent ancient and endangered languages through the use of computer code.

Certainly a boon for Egyptologists but don’t miss the opportunity to use Egyptian from different historical periods as a secure language.

Before you say: “Security through obscurity is a bad idea,” remember that Navajo code talkers worked quite well during World War II.

Moreover, in adapting an ancient language to a modern context, you can shift the meaning of words such that standard dictionaries and tools aren’t useful.

Being always mindful of the question: How long does this message need to remain secure? Messages about an action are of little value once an action is public. Events replace hopes and aspirations.

Enjoy!

May 5, 2018

Weekend Readings: Qubes (‘Reasonably Secure OS’)

Filed under: Cybersecurity,Linux OS,Security — Patrick Durusau @ 3:00 pm

Weekend Readings: Qubes by Carlie Fairchild.

From the post:

Qubes OS is a security-focused operating system that, as tech editor Kyle Rankin puts it, “is fundamentally different from any other Linux desktop I’ve used”. Join us this weekend in reading Kyle’s multi-part series on all things Qubes.

In order:

  1. Secure Desktops with Qubes: Introduction
  2. Secure Desktops with Qubes: Installation
  3. Secure Desktops with Qubes: Compartmentalization
  4. Secure Desktops with Qubes: Extra Protection
  5. Qubes Desktop Tips
  6. What’s New in Qubes 4

From the Qubes homepage: Motherboard: “Finally, a ‘Reasonably-Secure’ Operating System: Qubes R3” by J.M. Porup.

After reading Rankin’s posts, Qubes is high on my list of things to try.

April 4, 2018

192 Search Strings for Never To Be Patched Intel CPUs

Filed under: Cybersecurity,Security — Patrick Durusau @ 7:42 pm

Mohit Kumar in Intel Admits It Won’t Be Possible to Fix Spectre (V2) Flaw in Some Processors points to a microcode revision guide from Intel, PDF), which points to CPUs which won’t be patched for Spectre (variant 2) flaws.

Kumar lists the product families, Bloomfield, Clarksfield, Gulftown, Harpertown Xeon, Jasper Forest, Penryn, SoFIA 3GR, Wolfdale, and Yorkfield, but those are Intel names, not product names.

To simplify your searching for never-to-be-patched Intel chips, I created a list of the public chips names, some 192 of them.

Good hunting!

March 11, 2018

Phishing, The 43% Option

Filed under: Cybersecurity,Politics,Security — Patrick Durusau @ 2:54 pm

How’s that for a motivational poster?

You can, and some do, spend hours plumbing in the depths of code or chip design for vulnerabilities.

Or, you can look behind door #2, the phishing door, and find 43% of data breaches start with phishing.

Phishing doesn’t have the glamor or prestige of finding a Meltdown or Spectre bug.

But, on the other hand, do you want to breach a congressional email account for the 2018 mid-term election, or for the 2038 election?

Just so you know, no rumors of breached congressional email accounts have surfaced, at least not yet.

Ping me if you see any such news.

PS: The tweet points to: https://qz.com/998949/can-you-outwit-a-hacker/, an ad for AT&T.

March 1, 2018

MSDAT: Microsoft SQL Database Attacking Tool

Filed under: Cybersecurity,Database,Security — Patrick Durusau @ 9:30 am

MSDAT: Microsoft SQL Database Attacking Tool

From the webpage:

MSDAT (Microsoft SQL Database Attacking Tool) is an open source penetration testing tool that tests the security of Microsoft SQL Databases remotely.

Usage examples of MSDAT:

  • You have a Microsoft database listening remotely and you want to find valid credentials in order to connect to the database
  • You have a valid Microsoft SQL account on a database and you want to escalate your privileges
  • You have a valid Microsoft SQL account and you want to execute commands on the operating system hosting this DB (xp_cmdshell)

Tested on Microsoft SQL database 2005, 2008 and 2012.

As I mentioned yesterday, you may have to wait a few years until the Office of Personnel Management (OMP) upgrades to a supported version of Microsoft SQL database, but think of the experience you will have gained with MSDAT by that time.

And by the time the OPM upgrades, new critical security flaws will emerge in Microsoft SQL database 2005, 2008 and 2012. Under current management, the OPM is becoming less and less secure over time.

Would it help if I posed a street/aerial view of OPM headquarters in DC? Would that help focus your efforts at dropping infected USB sticks, malware loaded DVDs and insecure sex toys for OPM management to find?

OPM headquarters is not marked on the standard tourist map for DC. The map does suggest a number of other fertile places for your wares.

February 27, 2018

Kiddie Hack – OPM

Filed under: Cybersecurity,Government,Security — Patrick Durusau @ 9:24 pm

Is it fair to point out the Office of Personnel Management (OMP) continues to fail to plan upgrades to its security?

That’s right, not OPM security upgrades are failing, but OPM is failing to plan for security upgrades. Three years after 21.5 million current and former fed data records were stolen from the OPM.

The inspector general report reads in part:


While we believe that the Plan is a step in the right direction toward modernizing OPM’s IT environment, it falls short of the requirements outlined in the Appropriations Act. The Plan identifies several modernization-related initiatives and allocates the $11 million amongst these areas, but the Plan does not
identify the full scope of OPM’s modernization effort or contain cost estimates for the individual initiatives or the effort as a whole. All of the other capital budgeting, project planning, and IT security requirements are similarly missing.

At this rate, hackers are stockpiling gear slow enough to work with OPM systems.

Be careful on eBay and other online sources. No doubt the FBI is monitoring purchases of older computer gear.

February 26, 2018

Governments Are Secure, But Only By Your Forbearance (happens-before (HB) graphs)

Filed under: Cybersecurity,Security — Patrick Durusau @ 3:05 pm

MeltdownPrime and SpectrePrime: Automatically-Synthesized Attacks Exploiting Invalidation-Based Coherence Protocols by Caroline Trippel, Daniel Lustig, Margaret Martonosi.

Abstract:

The recent Meltdown and Spectre attacks highlight the importance of automated verification techniques for identifying hardware security vulnerabilities. We have developed a tool for synthesizing microarchitecture-specific programs capable of producing any user-specified hardware execution pattern of interest. Our tool takes two inputs: a formal description of (i) a microarchitecture in a domain-specific language, and (ii) a microarchitectural execution pattern of interest, e.g. a threat pattern. All programs synthesized by our tool are capable of producing the specified execution pattern on the supplied microarchitecture.

We used our tool to specify a hardware execution pattern common to Flush+Reload attacks and automatically synthesized security litmus tests representative of those that have been publicly disclosed for conducting Meltdown and Spectre attacks. We also formulated a Prime+Probe threat pattern, enabling our tool to synthesize a new variant of each—MeltdownPrime and SpectrePrime. Both of these new exploits use Prime+Probe approaches to conduct the timing attack. They are both also novel in that they are 2-core attacks which leverage the cache line invalidation mechanism in modern cache coherence protocols. These are the first proposed Prime+Probe variants of Meltdown and Spectre. But more importantly, both Prime attacks exploit invalidation-based coherence protocols to achieve the same level of precision as a Flush+Reload attack. While mitigation techniques in software (e.g., barriers that prevent speculation) will likely be the same for our Prime variants as for original Spectre and Meltdown, we believe that hardware protection against them will be distinct. As a proof of concept, we implemented SpectrePrime as a C program and ran it on an Intel x86 processor, averaging about the same accuracy as Spectre over 100 runs—97.9% for Spectre and 99.95% for SpectrePrime.

A separate paper is under review for the “tool” used in this article so more joy is on your way!

As a bonus, “happens-before (HB) graphs” are used, enabling exercise of those graph skills you built making cluttered Twitter graphs.

Good hunting!

February 13, 2018

Responsible Disclosure: You Lost 5 Months of Pwning Corporate/Government Computers

Filed under: Cybersecurity,Security — Patrick Durusau @ 7:34 pm

Skype can’t fix a nasty security bug without a massive code rewrite by Zack Whittaker.

From the post:

A security flaw in Skype’s updater process can allow an attacker to gain system-level privileges to a vulnerable computer.

The bug, if exploited, can escalate a local unprivileged user to the full “system” level rights — granting them access to every corner of the operating system.

But Microsoft, which owns the voice- and video-calling service, said it won’t immediately fix the flaw, because the bug would require too much work.

Security researcher Stefan Kanthak found that the Skype update installer could be exploited with a DLL hijacking technique, which allows an attacker to trick an application into drawing malicious code instead of the correct library. An attacker can download a malicious DLL into a user-accessible temporary folder and rename it to an existing DLL that can be modified by an unprivileged user, like UXTheme.dll. The bug works because the malicious DLL is found first when the app searches for the DLL it needs.

Once installed, Skype uses its own built-in updater to keep the software up to date. When that updater runs, it uses another executable file to run the update, which is vulnerable to the hijacking.

Impact of responsible disclosure?

Microsoft sat on its ass for over five months, five months you could have been pwning corporate and government computers, only to say (paraphrase): “It’s too hard.”

It wasn’t too hard for them to completely break Skype for Ubuntu and possibly other flavors of Linux. But fixing a large bug? No, let us introduce some new ones and then we’ll think about the existing ones.

Most corporations and governments maintain secrets only by lack of effort on the part of the public.

Give that some thought when deciding how to spend your leisure time.

February 12, 2018

Improving Your Phishing Game

Filed under: Cybersecurity,Ethics,Phishing for Leaks,Security — Patrick Durusau @ 7:52 pm

Did you know that KnowBe4 publishes quarterly phishing test analysis? Ranks the top lines that get links in phishing emails followed.

The entire site of KnowBe4 is a reference source if you don’t want to fall for or look like a Nigerian spammer when it comes to phishing emails.

Their definition of phishing:

Phishing is the process of attempting to acquire sensitive information such as usernames, passwords and credit card details by masquerading as a trustworthy entity using bulk email which tries to evade spam filters.

Emails claiming to be from popular social web sites, banks, auction sites, or IT administrators are commonly used to lure the unsuspecting public. It’s a form of criminally fraudulent social engineering.

I think:

It’s a form of criminally fraudulent social engineering.

sounds a bit harsh and not nuanced at all.

For example, these aren’t criminally fraudulent cases of phishing:

  • CIA sends phishing emails to foreign diplomats
  • FBI sends phishing emails to anti-war and social reform groups
  • NSA sends phishing emails to government officials (ours, theirs, etc.)

Phishing is an amoral weapon, just like any other weapon.

If you use phishing to uncover child sex traffickers, is that a criminally fraudulent use of phishing? Not to me.

If you hear a different conclusion in a windy discussion of ethics, don’t bother to write. I’ll just treat it as spam.

Don’t let other people make broad ethical pronouncements on your behalf. They have an agenda and it’s not likely to be one in your interest.

Meanwhile, improve your phishing game!

February 9, 2018

Fear Keeps People in Line (And Ignorant of Apple Source Code)

Filed under: Cybersecurity,Hacking,Security — Patrick Durusau @ 11:05 am

Apple’s top-secret iBoot firmware source code spills onto GitHub for some insane reason by Chris Williams.

From the post:

The confidential source code to Apple’s iBoot firmware in iPhones, iPads and other iOS devices has leaked into a public GitHub repo.

The closed-source code is top-secret, proprietary, copyright Apple, and yet has been quietly doing the rounds between security researchers and device jailbreakers on Reddit for four or so months, if not longer.

We’re not going to link to it. Also, downloading it is not recommended. Just remember what happened when people shared or sold copies of the stolen Microsoft Windows 2000 source code back in the day.

Notice that Williams cites scary language about the prior Windows source code but not a single example of an actual prosecution for downloading or sharing that source code. I have strong suspicions why no examples were cited.*

You?

The other thing to notice is “security researchers” have been sharing it for months, but if the great unwashed public gets to see it, well, that’s a five alarm fire.

Williams has sided with access only for the privileged, although I would be hard pressed to say why?

BTW, if you want to search Github for source code that claims to originate from Apple, use the search term iBoot.

No direct link because in the DCMA cat and mouse game, any link will be quickly broken and I have no way to verify whether a repository is or isn’t Apple source code.

Don’t let fear keep you ignorant.

*My suspicions are that anyone reading Microsoft Windows 2000 source code became a poorer programmer and that was viewed as penalty enough.

February 8, 2018

Introducing HacSpec (“specification language for cryptographic primitives”)

Filed under: Cryptography,Cybersecurity,Security — Patrick Durusau @ 2:58 pm

Introducing HacSpec by Franziskus Kiefer.

From the post:

HacSpec is a proposal for a new specification language for cryptographic primitives that is succinct, that is easy to read and implement, and that lends itself to formal verification. It aims to formalise the pseudocode used in cryptographic standards by proposing a formal syntax that can be checked for simple errors. HacSpec specifications are further executable to test against test vectors specified in a common syntax.

The main focus of HacSpec is to allow specifications to be compiled to formal languages such as cryptol, coq, F*, and easycrypt and thus make it easier to formally verify implementations. This allows a specification using HacSpec to be the basis not only for implementations but also for formal proofs of functional correctness, cryptographic security, and side-channel resistance.

The idea of having a language like HacSpec stems from discussions at the recent HACS workshop in Zurich. The High-Assurance-Cryptographic-Software workshop (HACS) is an invite-only workshop co-located with the Real World Crypto symposium.

Anyone interested in moving this project forward should subscribe to the mailing list or file issues and pull requests against the Github repository.

Cryptography projects should be monitored like the NSA does NIST cryptography standards. If you see an error or weakness, you’re under no obligation to help. The NSA won’t.

Given security fails from software, users, etc., end-to-end encryption resembles transporting people from one homeless camp to another in an armored car.

Secure in transit but not secure at either end.

Running a Tor Relay (New Guide)

Filed under: Privacy,Security,Tor — Patrick Durusau @ 10:45 am

The New Guide to Running a Tor Relay

Have we told you lately how much we love our relay operators? Relays are the backbone of the Tor network, providing strength and bandwidth for our millions of users worldwide. Without the thousands of fast, reliable relays in the network, Tor wouldn’t exist.

Have you considered running a relay, but didn’t know where to start? Perhaps you’re just looking for a way to help Tor, but you’ve always thought that running a relay was too complicated or technical for you and the documentation seemed daunting.

We’re here to tell you that you can become one of the many thousands of relay operators powering the Tor network, if you have some basic command-line experience.

If you can’t help support the Tor network by running a relay, don’t despair! There’s are always ways to volunteer and of course to donate.

Your support helps everyone who uses Tor and sometimes results in really cool graphics, like this one for running a Tor relay:

If you want something a bit closer to the edge, try creating a graphic where spy rays from corporations and governments bounce off of secure autos, computers, homes, phones.

February 7, 2018

Kali Linux 2018.1 Release

Filed under: Cybersecurity,Security — Patrick Durusau @ 9:52 pm

Kali Linux 2018.1 Release

From the post:

Welcome to our first release of 2018, Kali Linux 2018.1. This fine release contains all updated packages and bug fixes since our 2017.3 release last November. This release wasn’t without its challenges–from the Meltdown and Spectre excitement (patches will be in the 4.15 kernel) to a couple of other nasty bugs, we had our work cut out for us but we prevailed in time to deliver this latest and greatest version for your installation pleasure.

Churn, especially in security practices and software, is the best state imaginable for generating vulnerabilities.

New software means new bugs, unfamiliar setup requirements, newbie user mistakes, in addition to the 33% or more of users who accept phishing emails.

2018 looks like a great year for security churn.

How stable is your security? (Don’t answer over a clear channel.)

Older Posts »

Powered by WordPress