Process injection is a method of executing arbitrary code in the address space of a separate live process. Running code in the context of another process may allow access to the process's memory, system/network resources, and possibly elevated privileges. Execution via process injection may also evade detection from security products since the execution is masked under a legitimate process.
Posted: Jan 13, 2020
Keyword tags: hackingsecurityinfoseclinuxred team
Posted: Nov 20, 2019
Keyword tags: securityinfosecvulnerability disclosureprivilege escalationlinux
Antivirus evasion as a topic has always fascinated me. When I began my graduate computer science studies many years back, I originally proposed a topic to my advisors about improving antivirus engines to detect polymorphic viruses by mapping execution flows in binaries. As graduate studies go, this topic was ultimately shot down and I eventually settled on another research topic.
Bypassing antivirus is a necessary evil if you work in penetration testing or red teaming. It's also one of the more frustrating areas -- Frustrating, because "signature-based" antivirus software is both pretty ineffective at blocking threats, but at the same time is sometimes a pain to evade.
The popular wisdom to evade antivirus is "write your own custom tools." That's great advice if all you need to do is write a simple reverse shell, or if you have a large budget and lots of time to develop a well polished C2 infrastructure from scratch. The rest of us rely on the huge wealth of open source (and commercial) tools developed by folks in the security community. Yes, I want to be able to run something like mimikatz on an engagement and not jump through massive hoops to do so.
In comes Empire. If you aren't familiar with the tool, Empire is a post-exploitation C2 server that includes a wide variety of offensive tools. It's a powerful tool to use as part of an offensive operation, if it doesn't get flagged by antivirus in the process and become an unusable frustration. For a while, Empire was pretty good at evading things like Windows Defender. This is no longer true. If you create a generic http listener agent payload and execute in-memory, without even touching the disk, you will likely see something like the following.
Windows Defender busted us! I guess it's time to pack it in for the assessment, right? No way!
By tearing into Empire a bit (yea for free open source software!), we can easily modify some key areas and bypass that pesky client-side antivirus.
Posted: Feb 26, 2019
Keyword tags: securityinfosecempireantivirusevasionhacking
When was the last time you patched your fax machine? When was the last time you even thought about your fax machine? (Annoyance due to a PC LOAD LETTER error doesn't count.)
Research presented at last week's DEF CON security conference demonstrated some dead simple attacks on the fax machine protocol in many popular printers.
Posted: Aug 17, 2018
Keyword tags: securitysmall businessfax machines
Earlier this year I was asked to perform an OWASP ASVS (Application Security Verification Standard) with a colleague on a client's deployment of the web-based file-sharing software Pydio. After getting my feet wet looking at the codebase, my interest was piqued in the platform and decided to independently research the software for vulnerabilities.
The following vulnerability disclosure is a detailed account of my findings. Four areas of weakness were identified: multiple XSS flaws, a credentialed SSRF flaw, multiple methods to discover the remote version of the software, and a credentialed Remote Code Execution flaw. After discussion with the Pydio developers, two of the flaws were fixed in the 8.2.1 release. The remaining issues were not addressed due to the reasons discussed in the disclosure. A workaround is included for one of these issues, providing additional protections for those who may require it.
Update October 2018: The vendor has released Pydio 8.2.2, which includes an official fix for the credentialed Remote Code Execution flaw. The disclosure has been updated to reflect the new release.
Posted: Jul 23, 2018
Keyword tags: vulnerability disclosurepydiosecurityweb security
Earlier this week I had the privilege of providing insight for a Bleeping Computer article about the impending time-bomb that is world-writable Amazon S3 buckets. While S3 security is not a new topic, what gets the most attention are world-readable S3 buckets containing sensitive & confidential data. In fact, FedEx was in the news last week for leaking sensitive passport data via S3. However, the S3 insecurity topic this week is renewed interest in world-writable buckets.
A quick aside for folks new to the topic: S3 is a product provided through Amazon Web Services that allows anyone to create cloud-based file storage. These so called 'buckets' are basically virtual internet accessible hard drives. Unfortunately, they are often misconfigured and allow misuse by attackers looking to steal or manipulate data.
(Related post: Last year I did a quick analysis demonstrating that many general web servers are also misconfigured allowing public access to sensitive information, similar to S3.)
What likely got conversation going again this week was a security researcher who began placing warning messages in exposed writable S3 buckets with the filename POC.txt. The file itself was not malicious, but warned the account owners that they are at risk to malicious attackers.
What might that risk be? Security expert Kevin Beaumont speculated in a tweet that these exposed files may be stolen and/or encrypted by attackers looking to extort companies for ransom. Others speculated that these open buckets are ripe targets to host cryptojacking scripts -- the latest way attackers seek to monetize data breaches. (PS - If you want to understand the prevalence of cryptojacking, read the statistics published daily by Bad Packets Report.)
Posted: Feb 23, 2018
Keyword tags: securitys3ransomwarecryptojacking
Summary: A method is detailed - dubbed CSS Exfil - which can be used to steal targeted data using Cascading Style Sheets (CSS) as an attack vector. Due to the modern web's heavy reliance on CSS, a wide variety of data is potentially at risk, including: usernames, passwords, and sensitive data such as date of birth, social security numbers, and credit card numbers. The technique can also be used to de-anonymize users on dark nets like Tor. Defense methods are discussed for both website operators as well as web users, and a pair of browser extensions are offered which guard against this class of attack.
Several months ago I began tinkering with Chrome's XSS auditor looking for bypasses. One remote injection method which reliably got through Chrome's filter was CSS injection. By utilizing injected CSS, an attacker essentially has complete control over the look-and-feel of a page. I also discovered an attacker can leverage CSS to steal form data. By utilizing CSS alone, browser protections like NoScript can't block the egress of data (although NoScript's XSS auditor is more effective than Chrome at blocking some of the injection Proof of Concept attacks detailed below).
While CSS injection is not a new vulnerability, using CSS as the sole attack vector to reliably exfiltrate data - to my knowledge - has never been presented. I am also not aware of any effective method previously documented to guard end users against such attack - other than to block CSS, which is not a practical solution.
Posted: Feb 06, 2018
Keyword tags: CSS Exfilexploitweb security
My son loves building and Lego bricks are some of his favorite toys. He's also the son of a ham radio operator and is absolutely fascinated with radio antennas. For Christmas I built him a model radio tower complete with red pulsing lights and a Lego base.
Posted: Dec 21, 2017
Keyword tags: electronicsmake555 timerlegoradioantenna
Want to know an easy way to get hacked? Leave your sensitive data exposed publicly to the world.
It seems like not a week goes by without another story of a company or government leaking sensitive data on public AWS S3 buckets. S3 is a service that allows anyone to create cloud file storage, and by default is web accessible. Amazon recently made an update to their administration console to indicate if a 'bucket' is public, but there are a lot of historical/misconfigured buckets out there set as public when they should not be.
The issue is certainly not isolated to S3. I was recently evaluating a piece of software for a client and noticed that sensitive data was being exposed though cache files which were publicly accessible / unauthenticated in an open directory on their web server, if you knew where to look. Lucky for them there was no evidence that this data had been accessed, but it made me curious to evaluate the extent of publicly accessible open directories on the web.
Posted: Dec 12, 2017
Keyword tags: securityinfoseccybersecurityowaspremote vulnerabilitys3
Let's Encrypt announced this week they will begin issuing wildcard SSL certificates starting January 2018, a feature many have been hoping would be added to the service for years. While many will be rejoicing, it may get a little harder locating scammers and phishers.
While the vast majority of Let's Encrypt issued certificates are for legitimate domains, the service has become a sort of best practice for phishing campaigns. Why? SSL brings the illusion of trust to a URL. This has been compounded with most browsers indicating a site is "secure" in the URL bar, by merely serving a site up via https. Combine this with the fact that Let's Encrypt is a completely free service, and you have a breeding ground for scammers.
One reliable method security researchers use to enumerate domain names (determine all sub-domains of a domain name) is to monitor SSL certificate issuance. The Certificate Transparency project makes this easy.
Posted: Nov 16, 2017
Keyword tags: infoseccybersecuritycertificate transparencylets encryptphishing
The KRACK vulnerability publicly announced yesterday dropped like a bombshell, because the decade and a half old WPA2 protocol was not only thought to be secure, but the attack presented seems so obvious in retrospect. There is a lot of online coverage and one of the best summaries was written by security expert Bruce Schneier.
I am skeptical that devices will be patched in a timely manner. Vendors had a head start to get patches ready before the public announcement, and while this is a rare time I will commend Microsoft, who patched the flaw ahead of public release, many vendors were left sitting on their hands.
The Android ecosystem is particularly vulnerable to KRACK, due to the so-called null key issue. Google won't have an official patch available for a couple weeks (although the LineageOS team has it fixed), but my guess is the large majority of Android devices in the wild will never see that patch applied to their phone.
Likewise, I don't have high hopes that my home FiOS router will be patched, considering that it's up-to-date with a firmware version over a year old. Something tells me KRACK isn't the only issue that may be lurking within the device.
I never trusted that router anyway.
KRACK underscores an important lesson. You can't trust your network. As soon as a packet leaves your computer or smartphone, assume always that it's being sniffed and manipulated. If not by your ISP, then by some compromised router deep on the internet, or perhaps now a couple hundred feet away from you by that wardriver cruising your neighborhood or corporate parking lot.
Fortunately, you can protect yourself, with encryption.
Posted: Oct 18, 2017
Keyword tags: securityhackingkrackwpa2
This discovery is similar to the Google Docs phishing attack earlier this year. While this isn't necessarily a direct flaw within iOS, the attack vector is subtle and I bet would fool many people. In fact, I would be surprised if this wasn't previously used in the wild for a targeted spear phishing campaign. (Edit: It appears that this flaw was uncovered back in 2015!)
Posted: Oct 10, 2017
Keyword tags: securityhackingphishing
In light of the recent data breach at Equifax I'm composing some thoughts in two posts. The first post discusses the weaknesses in employing partial security solutions. This second post discusses why organizations must employ offensive security to stay ahead.
Hot off the Equifax news, last week we heard about a breach of the SEC EDGAR reporting system, and announced yesterday, Deloitte's private communications. Organizations must start to think like would be attackers.
Offensive security is a school of thought, where a proactive approach is taken to computer security. When people typically think of security, the first thing that comes to mind are traditional/defensive approaches: e.g. patching systems, strong passwords, employing firewalls, etc. While defensive measures are essential, an offensive security approach focuses on penetration testing and thinking like an attacker, with a goal of finding weaknesses in your own organization's systems and software.
Posted: Sep 26, 2017
Keyword tags: securityhackinginfosecoffensivesecurity
In light of the recent data breaches at Equifax I'm composing some thoughts in two posts. This first post details how organizations often miss the mark securing data due to partial security solutions.
As soon as news of the Equifax breaches hit the wire people were asking: How did this happen? All public accounts point to a vulnerability in the software package Apache Struts, that went unpatched in Equifax's systems for months. (Note that Apache Structs is different from the widely used Apache web server, although that distinction is meaningless for the purposes of this post).
That sounds pretty damning, but I'm not going to speculate why a software package went unpatched. It should have been patched - and swiftly - but what if the flaw was a so-called 0-day exploit without a patch? Would Equifax still be held liable for such a massive breach? The answer should be a resounding yes!
Posted: Sep 21, 2017
Keyword tags: securityhackinginfosec
Posted: Aug 31, 2017
Keyword tags: securityhackingremote vulnerabilityssllets encrypt
Posted: Feb 25, 2016
Keyword tags: shortwavetransmitterqrpschematicAM transmitterelectronics500mW
Posted: Feb 13, 2014
Keyword tags: raspberry piarcademakeelectronics
Posted: Dec 24, 2013
Keyword tags: arduinoelectronicsclockRTCshift registers
Posted: Jun 17, 2013
Keyword tags: amateur radioelectronicsmakeDIYmakeRF
If you read my last post, you saw my schematic on how to build a musical Arduino doorbell.
After the doorbell was installed, I noticed that it rang by itself sometimes. Not often enough to be too annoying, but enough to think about correcting the issue at some point. I noticed it rang sometimes when a large appliance clicked on, like the dishwasher or central air, and even sometimes when getting a static shock on a light switch.
My annoyance level went through the roof when a large thunderstorm rolled though one afternoon. During the fifteen minutes of thunder crashing, the doorbell rang by itself six times!
So, what was happening, and how did I fix it?
Posted: May 22, 2013
Keyword tags: arduinocircuitselectronicsdoorbellschematicfilter
Earlier this year my family and I had the good fortune to move to our first home. The home had everything we wanted, except a working doorbell.
The original doorbell button was there, complete with decades of corrosion and wires that were cut between the button and what looked to be some sort of buzzer. Initially, I planned to buy a new chime and button at Home Depot, hook up the wires, and be done with it. The chime selection, however, was sub-par.
Apparently the doorbell market is dominated by ding-dong and Westminster. Growing up, my father built a doorbell that played the first two measures of Pictures at an Exhibition. Maybe I was spoiled listening to this during my formative years, but if I wanted a doorbell that played music, I needed to build it myself.
Posted: Mar 27, 2013
Keyword tags: arduinocircuitselectronicsdoorbellschematiclm386
Posted: Jun 13, 2012
Keyword tags: google voiceland linenumber porting