• chevron_right

      The 2023 Wrap-up

      pubsub.slavino.sk / hackerfactor · Saturday, 30 December - 22:31 edit · 5 minutes

    Every year I try to focus on a theme. For example:
    • In 2017, it was Cyber Goat . I had this crazy idea that a small company might be able to make large organizations move. (It was an incredible success.)
    • In 2019, I focused on a couple of themes : fraud and detection, practical ways to deter bots, and how to setup a basic honeypot.
    • In 2020, I heavily focused on Tor . Sadly, there was nothing I could do to make them address some of their huge security holes. It's been over 4 years and they have not addressed any of the issues. (Then again, some of these have been known problems for decades and the Tor Project just ignores them, even when there are viable solutions. Seriously: don't use Tor if you need real online anonymity.)
    This year, I've been heavily focused on automation. I don't have unlimited resources or personnel, so I want to make the most of what I've got.

    Automation for security and administration tasks isn't a new concept. Everyone does it to some degree. Firewalls are configured and deployed, cron jobs automate backups, etc.

    My crazy twist applies this concept to tasks that are usually not automated. I've been developing and using automated security solutions for over 30 years. This year, I publicly disclosed many of the solutions that I use. For example:
    • In No Apps , I mentioned how I use test images to identify the underlying graphics libraries that applications use. Some libraries change images during their rendering process, and others have known vulnerabilities. This quick semi-automated test allows me to learn more about the software that I use.
    • I covered how I use fail2ban and strict mail server rules to mitigate junk mail and spam. On any typical day, my email box only receives 2-4 spam messages. The remaining hundreds of emails are caught by the mail server's filter rules. I configured it once and occasionally (maybe 30 minutes every few months) make little adjustments. For the most part, it's fully automated and I don't have to think about it.
    • I mentioned the various honeypots I use and some of the findings . I am automatically alerted when a change in attack volume happens, and I can tell if it's specific to a single server or just a change in the background noise level.

      Knowing the background level is really important. I'm less concerned if everyone sees the same attacks. Directed attacks get my attention. I also use it for business intelligence ; I often know what exploits the attackers are looking for before any official announcement.
    • Based on my work with honeypots, I released a four-part series on No-NOC Networking . This series describes some simple solutions to dramatically reduce the number of scans and attacks that your typical online service receives. And best of all: these can be implemented without any full-time system administrators or network operations center (NOC). These changes require no extra costs for better security.
    • Along with descriptions of my honeypots, I also released Nuzzle as an open source packet sniffer that can be used as an IDS/IPS system. Many of my own servers use Nuzzle. Between Nuzzle and some simple kernel configurations, you can easily see a 99% drop in the number of attacks. (That's not "stopping 99% of attacks", that's "99% fewer attacks that need to be stopped.")
    • Besides software automation, I did a lot of hardware hacking by making some simple internet-of-things (IoT) devices. These ranged from a basic temperature sensor (for montioring my server cabinet) to different approaches for checking on the health of elderly friends . I even automated the tracking of my AirTag .
    • Through the use of automated detectors, I was able to rapidly detect and block uploads when a new kind of prohibited content went viral.
    All of this simplifies my system management needs. Rather than spending a lot of time and money on yet another partial solution, I use my limited resources more effectively. Fewer network attacks, less spam, and better ways to monitor the things that I think are important.

    Bad Automation

    I typically view automation as a good thing. I often tell my peers: if it can be automated, then it should be automated. However, sometimes automation isn't beneficial. A good automated system should be reliable and accurate. Unfortunately, some recently deployed automated solutions are neither.

    The growing and unchecked use of AI is a really good example here. Whether it's AI-generated art or AI-written text , I'm seeing more misuse and problems than benefits. Personally, I think the punishments for using unchecked AI text, like ChatGPT, for official reports should be more severe than public criticism and the occasional sanction .

    There are also problems with how these AI systems are being trained. Since deep networks can often memorize the training data, the AI generated results may appear as copyright infringement. Personally, I'm eagerly waiting to hear the outcome of Getty's lawsuit against Stability AI for stealing pictures for training and generating minor variants as uncited "AI generated imagery". And the New York Times recently sued OpenAI and Microsoft for the unauthorized use of copyrighted news articles.

    While I use many different types of automated systems (including lots of different kinds of AI), it takes effort to create good automated rules. Bad automatons lead to bad user experiences . (Just ask the Etsy forums about bad automated blocking rules, and the US Post Office really needs to consult with a human-computer interaction (HCI) expert about usability for their automated kiosks.)

    And then there's C2PA. I don't think I'm done writing about them . I rarely use snake oil to describe any kind of fake security solution or bad automated evaluation system, but this time I think it is well deserved.

    Next year?

    Long-time readers of my blog will know that I am often rough, brutally honest, and hyper-focus on the negative aspects. In 2023, I tried to write more uplifting and less cranky blog entries. (Other than C2PA or my criticisms about AI, I think I did pretty well compared to previous years. And with AI and C2PA, I do like the concepts, but I take issue with the execution and how they generate more problems than they attempt to solve.)

    In 2024, I'm going to try to have a little more fun with this blog. I'm hoping to write more about things that make me happy (which usually includes projects that have worked out better than expected). For example, rather than focusing on how deep network AI causes problem, I might try to experiment with some good uses for it. When it comes to authenticity and provenance, the C2PA management challenged me to come up with something better. I think I've got a partial solution that works; when I get time to write it up and create a working example, I'm certain to blog about it. (A working partial solution is definitely an improvement when compared to the defective solution from C2PA.) And who knows what else I'll do? Some of the best projects have been those surprises along the way.

    Značky: #Privacy, #Network, #Security, #Forensics, #[Other]

    • chevron_right

      A DKIM signature on email by itself means very little

      pubsub.slavino.sk / chris_spam · Sunday, 24 December - 03:49 edit · 2 minutes

    In yesterday's entry on what I think the SMTP Smuggling attack enables , I casually said that you were safe if you ignored SPF results and only paid attention to DKIM . As sometimes happens, this was my thoughts eliding some important qualifications that I just take as given when talking about DKIM, but that I should spell out. The most important qualification is that a (valid) DKIM signature by itself means almost nothing , which is a bit unlike how SPF works.

    First off, anyone can DKIM sign a message , provided that they control a bit of DNS (you could probably even do it in a mail client). Quite a lot of people, including spammers, can even DKIM sign email that is 'aligned' with the 'From:' header, which means that the DKIM signature is from the From: domain, not just from some random domain. A valid DKIM signature does provide definite attribution , and if it's for the From: domain, it more or less identifies who authorized the mail. Also, in practice lack of a DKIM signature is itself a signal , because an increasing number of places more or less require a DKIM signature , sometimes one that is from the From: domain.

    (However, some people only have SPF records and this can be deliberately used to create email that can't be easily forwarded .)

    A valid DKIM signature for the From: domain is at least as strong a sign as an SPF pass result. However, this doesn't mean that the email is any good, any more than an SPF pass does; spammers can and do pass both checks. Similarly, lack of a valid DKIM signature for the From: domain doesn't mean that it's not from that domain. To have some idea of that you need to check the domain's DMARC policy. In effect, the equivalent of SPF is the combination of DKIM and DMARC (or something like it).

    So when I casually wrote about (only) paying attention to DKIM, I was implicitly thinking of using DKIM along with something else to tell you when DKIM results matter. This might be specific knowledge of which important domains you deal with DKIM sign their email (including your own domain), or it might mean checking DMARC, or both. And of course you can ignore both SPF and DKIM signatures, apart perhaps from logging DKIM results.

    ( We don't explicitly use DKIM signatures and DMARC in our Exim configuration, but these days we use rspamd for spam scoring and I think it makes some use of DKIM and perhaps DMARC.)

    Značky: #Network

    • chevron_right

      What I think the 'SMTP Smuggling' attack enables

      pubsub.slavino.sk / chris_spam · Saturday, 23 December - 02:49 edit · 2 minutes

    The very brief summary of SEC Consult's "SMTP Smuggling" attack is that under the right circumstances, it allows you (the attacker) to cause one mail server to 'submit' an email with contents and SMTP envelope information that you provide to a second mail server. To the second email server, this smuggled email will appear to have come from the first mail server (because it did), and can inherit some of the authentication the first mail server has.

    (It's important to understand that the actual vulnerability is in the second mail server, not the first one; the first one can and often must be completely RFC compliant in its behavior.)

    The obvious authentication that the smuggled email inherits is SPF , because that's based on the combination of the sending IP (the first mail server) and the SMTP envelope sender (and possibly message From:), which is under your control. So you can put in a SMTP envelope sender (and a From:) that claims to be 'from' the first mail server, and the second mail server will accept it as authentic.

    (An almost as obvious thing is that the smuggled email gets to share in whatever good reputation the sending email server has with the receiver. This is most useful if you can get a big, high reputation mail system to be the first server, which is possible (or perhaps 'was' by the time you're reading this).)

    If you forge email as being from something that has a DMARC policy that passes the policy if SPF passes, you can also get your forged email to pass DMARC checks. The same is true if the second email server happens to be something that imposes its own implicit DMARC-like policy that accepts email if SPF passes and (and possibly that SPF is 'aligned' with the From: message address).

    What you can't fully do is inherit DKIM authentication. You can add your own valid DKIM headers to your smuggled email, but you can only do this for domains with DNS under your control (or domains where you've managed to obtain the DKIM signing keys). This probably doesn't include the first email server and its domain, and because the first email server doesn't recognize your smuggled email as an actual email message, it won't DKIM sign the email for you. The only way you can get the domain of the first email server to DKIM sign your second email for you is if the second email server is also an internal one belonging to the same domain and it will DKIM sign outgoing messages. This general configuration is reasonably common (incoming and outgoing email servers are often different), but usually they run the same mail software and so they won't have the different interpretations of the email message(s) that SMTP Smuggling needs.

    The result of this is that if the second (receiving) email server doesn't check SPF results and only pays attention to DKIM ( which is increasingly mandatory in practice ), it's almost completely safe from SMTP Smuggling even if it accepts things other than 'CR LF . CR LF' as the email message terminator. Since SPF breaks things ( also ), this is what I feel you should already be doing.

    Značky: #Network

    • chevron_right

      The (historical) background of 'SMTP Smuggling'

      pubsub.slavino.sk / chris_spam · Thursday, 21 December - 03:55 edit · 5 minutes

    The recent email news is SEC Consult's SMTP Smuggling - Spoofing E-Mails Worldwide ( via ), which I had a reaction to . I found the article's explanation of SMTP Smuggling a little hard to follow, so for reasons that don't fit within the scope of today's entry, I'm going to re-explain the central issue in my own way.

    SMTP is a very old Internet protocol, and like a variety of old Internet protocols it has what is now an odd and unusual core model. Without extensions, everything in SMTP is line based, with the sender and receiver exchanging a series of 7-bit ASCII lines for commands, command responses, and the actual email messages (which are sent as a block of text in the 'DATA' phase, ie after the sender has sent a 'DATA' SMTP command and the receiver has accepted it). Since SMTP is line based, email messages are also considered to be a series of lines, although the contents of those lines is (mostly) not interpreted. SMTP needs to signal the end of the email text being transmitted, and as a line based protocol it does this by a special marker line; a '.' on a line by itself marks the end of the message.

    (In theory there's a defined quoting and de-quoting process if an actual line of the message starts with a '.'; see RFC 821 section 4.5.2, which is still there basically intact in RFC 5321 section 4.5.2 . In practice, actual mailer behavior has historically varied.)

    When you have a line based protocol you must decide how the end of lines are marked (the line terminator ). In SMTP, the official line terminator is the two byte (two octet) sequence 'CR LF', because this was the fashion at the time. This includes the lines that are part of the email message that is sent in the DATA phase, and so the last five octets sent at the end of a standard compliant SMTP message are 'CR LF . CR LF'. The first 'CR LF' is the end of the last line of the actual message, and then '. CR LF' makes up the '.' on a line by itself.

    (This means that all lines of the message itself are supposed to be terminated with 'CR LF', regardless of whatever the native line terminator is for the systems involved. If you're doing SMTP properly, you can't just blast out or read in the raw bytes of the message, even apart from RFC 5321 section 4.5.2 concerns. There are various ESMTP extensions that can change this.)

    Unfortunately, SMTP's definition makes life quite inconvenient for systems that don't use CR LF as their native line ending, such as Unix (which uses just LF, \n). Because SMTP considers the email message itself to be a sequence of lines (and there's a line length limit), a Unix SMTP mailer has to keep translating all of the lines in every email message it sends or receives back and forth between lines ending in \n (the native format) and \r\n (the SMTP wire format). Doing this translation raises various questions about what you should send if you encounter a \r (or a \r\n) in a message as you send it, or encounter a bare \n (or \r) in a message as you receive it. It also invites shortcuts, such as turning \r\n into \n as you read data and then dealing with everything as Unix lines.

    Partly for this reason and partly because CR LF line endings make various people grumpy, there has been somewhat of a tradition of mailers accepting other things as line endings in SMTP, not just CR LF. Historically a variety of Unix mailers accepted just LF, and I believe that some mailers have accepted just CR. Even today, finding SMTP listeners that absolutely require 'CR LF' as the line ending on SMTP commands isn't entirely common (GMail's SMTP listener doesn't, for example, although possibly this will cause it to be unhappy with your email, and I haven't tested its behavior for message bodies). As a result, such mailers can accept things other than 'CR LF . CR LF' as the SMTP DATA phase message terminator. Exactly what a mailer accepts can vary depending on how it implemented things.

    (For instance, a mailer might turn '\r\n' into '\n' and accept '\n' as a line terminator, but only after checking for a line that was an explicit '. CR LF'. Then you could end messages with 'LF . CR LF', without the initial 'CR'; the bare LF would be taken as the line terminator for the last data line, then you have the '. CR LF' of the official terminator sequence. But if you sent 'LF . LF', that wouldn't be recognized as the message terminator.)

    This leads to the core of SMTP Smuggling, which is embedding an improper SMTP message termination in an email message (for example, 'LF . LF'), then after it adding SMTP commands and message data to submit another message (the smuggled message ). To make this do anything useful we need to find a SMTP server that will accept our message with the embedded improper terminator, then send the whole thing to another mail server that will treat the improper terminator as a real terminator, splitting what was one message into two, sent one after the other. The second mail server will see the additional mail message as coming from the first mail server, although it really came from us, and this may allow us to forge message data that we couldn't otherwise.

    (There are various requirements to make this work; for example, the second mail server has to accept being handed a whole block of SMTP commands all at once. These days this is a fairly common thing due to an ESMTP extension for 'pipelining', and also because SMTP receivers have to do extra work to detect and reject getting handed a block of stuff like this. See the original article for the gory details and an extended discussion.)

    What you can do with SMTP Smuggling in practice has some limitations and qualifications, but that's for another entry.

    Značky: #Network

    • chevron_right

      C2PA's Worst Case Scenario

      pubsub.slavino.sk / hackerfactor · Monday, 18 December - 21:06 edit · 20 minutes

    A month ago, I wrote a very detailed and critical review of the Coalition for Content Provenance and Authenticity (C2PA) specification for validating media metadata. My basic conclusion was that C2PA introduces more problems than it tries to solve and it didn't solve any problems.

    Although a few people have left comments on the blog, I have had a near daily stream of new contacts writing in. Some are curious developers, while others are people tasked with evaluating or implementing C2PA. The comments have come from small organizations, Fortune-500 companies, and even other CAI and C2PA members. (Since some of them mentioned not having permission to publicly comment, I'm treating them all as anonymous sources.)

    Despite having different areas of interest, they all seem to ask variations of the same basic questions. (It's so frequent, that I've often been cut-and-pasting text into replies.) In this blog entry, I'm going to cover the most common questions:
    1. Are there any updates?
    2. How bad is C2PA's trust model?
    3. Isn't C2PA's tamper detection good enough?
    4. Is C2PA really worse than other types of metadata?
    5. What's the worst-case scenario?
    For people interested in problem solving with forensic tools, I have a challenge in the 5th item.

    Question 1: Are there any updates?

    There have been a couple of updates to C2PA since my blog came out. Some appear to be unrelated to me, and some are directly related.
    • C2PA released version 1.4 of their specifications. Unfortunately, it doesn't address any of the problems with the trust model. (Since this happened a few days after my blog, it's an unrelated update.)
    • Some of the bugs submitted to various C2PA github projects suddenly became actively addressed by the C2PA/CAI developers. (Including some submitted by me.) While this is progress, none have been fixed yet. In most cases, the bugs seem to have been copied from the public github locations to Adobe's private bug management system. (This means that C2PA development is really only happening inside Adobe.) Unfortunately, none of these bugs address C2PA's trust model.
    • Last week I had a productive discussion with people representing C2PA and CAI. I'm not going to disclose the discussion topics, except to say that there were some things we agreed on, and many things we did not agree on.

      Excluding myself and my colleague, everyone on the call was an Adobe employee. In my previous blog , I mentioned that CAI acts like a façade to support C2PA. Between all of the key people being at Adobe and all development going through Adobe, I'm now getting the distinct impression that CAI and C2PA are both really just "all Adobe all the time." It does not appear to be the wider community that C2PA and CAI describe.
    • A few days after the conference call, Adobe made a change to CAI's Content Credentials web site. Now self-signed certificates (and some of the older non-test certificates) are flagged as untrustworthy: "This Content Credential was issued by an unknown source."
      analysis.php?id=e2d944193b24b267e20bf9c3afe994c9b9ce89ec.6558&fmt=orig
      The only way around this requires paying money to a certificate authority for a "signing certificate". (At DigiCert, this costs $289 for one year.) Switching to a fee-based requirement dramatically reduces the desirability for smaller companies and individual developers to adopt C2PA. And yet, adding in a fee requirement does nothing to deter fraud. (Fraud is a multi-billion dollar per year industry. The criminals can afford to pay a little for "authentication".)

      As an aside, "HTTPS" adoption had a similar pay-to-play limitation until Let's Encrypt began offering free certificates. Today, HTTPS is the norm because it's free. Unfortunately, those free certificates are for web domains only and not for cryptographic signatures .

    Question 2: How bad is C2PA's trust model?

    My previous evaluation identified different ways to create forgeries, but it only superficially covered the trust model.

    Back in the old days of network security, we relied on "trust", but "trust" was rapidly shown to be vulnerable and insecure. "Trust" doesn't work very well as a security mechanism; it's not even "better than nothing" security. "Trust" is used for legal justification after the fact. We trust that someone won't ignore the "No Soliciting" sign by your door. The sign doesn't stop dishonest solicitors. Rather, it establishes intent for any legal consequences that happen later.

    In networking, "trust" was replaced with " trust but verify ", which is better than nothing. Today, network security is moving from "trust but verify" to " zero trust ".

    C2PA is based heavily on the "trust" and not "trust but verify". (And definitely not "zero trust".) With C2PA:
    • We trust that the metadata accurately reflects the content. (Provenance, origin, handling, etc.) This explicitly means trusting in the honesty of the person inserting the metadata.
    • We trust that each new signer verified the previous claims.
    • We trust that a signer didn't alter the previous claims.
    • We trust that the cryptographic certificate (cert) was issued by an authoritative source.
    • We trust that the metadata and cert represents an authoritative source. While the cert allows us to validate how it was issued ("trust but verify"), it doesn't validate who it was issued to or how it is used.
    • We trust the validation tools to perform a proper validation.
    • We trust that any bad actors who violate any of these trusts will be noticed before causing any significant damage. ( Who will notice it? We trust that there is someone who notices, somewhere to report it, and someone who can do something about it. And we trust that this will happen quickly, even though it always takes years to revoke a pernicious certificate authority .)
    All of this trust is great for keeping honest people honest. However, it does nothing to deter malicious actors.

    C2PA is literally based on the honor system. However, the honor system is the definition of having no security infrastructure. (We don't need security because we trust everyone to act honorably.)

    Question 3: Isn't C2PA's tamper detection good enough?

    Putting strong cryptography around unverified data does not make the data suddenly trustworthy. (It's lipstick on a pig !)

    Other than the cryptographic signature, all of C2PA's metadata can be altered without detection. (Yes, C2PA also uses a hash, like sha256, as a secondary check, but it's trivial to recompute the hashes after making any alterations.) The cryptographic signature ensures that the data hasn't changed after signing. C2PA calls this tamper evident , while other C2PA members describe it as being tamper resistant or tamper proof . Regardless of the terminology, there are four possible scenarios for their tamper detection: unsigned, invalid, valid, and missing.
    • Case 1: Unsigned data
      This cases occurs when the C2PA metadata exists but there is no cryptographic signature. As I've mentioned, everything can be easily forged. Even though the C2PA metadata exists, you cannot explicitly trust it since you don't know who might have changed it.

      The C2PA specification permits including files as a component of another file. This unsigned case can easily happen when incorporating media that lacks C2PA metadata. In my previous blog entry , I pointed out that CAI's example with the flowery hair contains a component without a signature.

      analysis.php?id=3f509b153c8ba2f26732bc8c521a1463085b74eb.690710&fmt=orig&size=256

      What this means: If there is no cryptographic signature, then we cannot trust the data. We must use other, non-C2PA methods to perform any validation.
    • Case 2: Invalid signature or checksum
      When the C2PA metadata has an invalid checksum or signature, it explicitly means something was changed. However, you don't know what was changed, when it happened, or who did it.

      Keep in mind, this does not mean that there is intentional fraud or a malicious activity. Alterations could be innocent or unintentional. For example, importing a JPEG into the Windows Photo Gallery ( discontinued but still widely used) automatically updates the metadata. This update causes a change, making the C2PA signature invalid. The same kind of unintentional alteration can also happen when attaching a picture to an outgoing email. (As opposed to importing a picture into the iPhone Photo Library, which simply strips out C2PA metadata.)

      If the signature is invalid, then C2PA says we cannot trust the data. However, the important aspects of the data may not have changed and may still be trustworthy. We must use other, non-C2PA methods to determine the cause and perform any validation.
    • Case 3: Valid signature and checksums
      There are two different ways that a file can contain valid signatures and checksums:

      (A) While we don't know if we can trust the data, we know we can trust that it wasn't changed after being signed.
      or
      (B) The data was changed after being signed and any invalid signatures were replaced, making it valid again. In this case, the data and signatures are untrusted.

      In both cases (A and B), the signatures and checksums are valid and we cannot trust the data. Moreover, we can't distinguish unaltered (A) from intentionally altered (B). Since we cannot use C2PA for trust or tamper detection, we must use other, non-C2PA methods to perform any validation.
    • Case 4: No C2PA metadata
      This is currently the most common case. Does it mean that the picture never included C2PA metadata, or that the metadata was removed (stripped)?

      CAI's Content Credentials service addresses this problem by performing a similar picture search (perceptual search). Most of the time, they find nothing. However, even if they do find a visually similar file that contains C2PA metadata, it doesn't mean the data in the search result is trustworthy or authentic. (See Cases 1-3.)
    In every case:
    • The data is untrusted.
    • Intentional tampering cannot be detected.
    • The data must be validated through other, non-C2PA means.
    What does C2PA provide? Nothing except computational busywork. C2PA's complexity and use of buzzwords like "cryptography" and "tamper evident" makes it appear impressive, but it currently provides nothing of value.

    Question 4: Is C2PA really worse than other types of metadata?

    Given that C2PA does not validate, why do we need yet another standard for storing the exact same information?

    The metadata information provided by C2PA is typically present in other metadata fields: EXIF, IPTC, XMP, etc. However, C2PA provides the same information in an overly complicated manner, requiring 5 megs of libraries and four different complex formats to process. In contrast, EXIF and IPTC are simple formats, easy to implement, require few resources, and come in very small libraries. Even XMP (Adobe's XML-based format that sucks due to a lack of consistency) is a better choice than C2PA's JUMBF/CBOR/JSON/XML.

    A few people have written to me with comments like, "C2PA has the same long-term integrity issue as other metadata" or "Isn't C2PA as trustworthy as anything else?"

    My reply is a simple "No." C2PA is much worse:
    1. Regular metadata doesn't claim to be tamper-evident.
    2. Regular metadata doesn't use cryptographic signatures.
    3. Regular metadata doesn't have the backing of tech companies like Adobe, Microsoft, and Intel that give the false impression of legitimacy.
    Other types of metadata (EXIF, IPTC, etc.) can be altered and should be validated though other means. C2PA gives the false impression that you don't need to validate the information because the cryptographic signatures appear valid.

    Even the converse is problematic. Because the metadata can be altered without malicious intent (see the previous Case 2), an invalid C2PA signature does not mean the visual content, GPS, timestamps, or other metadata is invalid or altered. Everything else could be legitimate even with an invalid C2PA signature.

    Unlike other types of metadata, C2PA's cryptographic signatures act as a red herring . Regardless of whether the signature is valid, invalid, or missing, forensic investigators should ignore C2PA's signatures since they tell nothing about the data's validity, authenticity, and provenance.

    Question 5: What's the worst-case scenario?

    This is the most common question I've received. I usually just explain the problem. But for a few people, I've manufactured examples of the worst-case scenario for the questioner to evaluate. In each of these instances, I used the questioner's own personal information to really drive home the point.

    Since lots of people are reading this blog entry, I'm going to use Shantanu Narayen as the fictional example of the worst-case scenario. Narayen is the current chair and CEO of Adobe; his personal information in this example comes from his Wikipedia page. (I'm not doxing him.)

    In my opinion, the worst-case scenario is when the data is used to frame someone for a serious crime, like child pornography. Here's the completely fictitious scenario:

    Last month, Shantanu Narayen got into an online argument with a very vindictive person. The vindictive person acquired a bunch of child pornography and used C2PA to attribute the pictures to Narayen. The pictures were then distributed around the internet.

    It doesn't take long for the pictures to be reported to the National Center for Missing and Exploited Children (NCMEC). NCMEC sees the attribution to Narayen and immediately passes the information to the FBI and California's Internet Crimes Against Children (ICAC) task force. A short while later, the police knock on Narayen's door.

    I'm not going to include a real picture of child porn for this demonstration of a fictional situation. (That would be gross, illegal, and irrelevant to this example.) Instead, I used a teddy bear picture (because it's "bearly legal").

    For this evaluation, ignore the visual portion and assume the picture shows illegal activity. Here's one of those forged pictures!

    analysis.php?id=04857686607b05b9fe3efef11fa6a11cd68e51df.306924&fmt=orig&size=256

    Now, you get to play the role of the investigator: Prove Narayen didn't do it.

    You'll probably want to:
    • Download the image. (Save it as 'bearlylegal.jpeg'.) To make sure it wasn't modified between my server and your evaluation, the file is 306,924 bytes and the SHA1 checksum is 04857686607b05b9fe3efef11fa6a11cd68e51df.
    • Evaluate it using whatever metadata viewers you have available.

      • If you don't have a starting place, then you can use my own online forensic services, like FotoForensics and Hintfo . But don't feel like you need to use my tools.
      • From the command line, try exiftool or exiv2 .
      • Most graphical applications have built-in metadata viewers, including Mac's Preview, Windows file properties ("Details" tab), Gimp, and Photoshop. (Just be careful to not hit 'save' or make any changes to the file's metadata.)

    • Use Adobe's command-line c2patool to evaluate the C2PA metadata. With c2patool, you can view what sections are valid and the x.509 certificate contents:
      c2patool -d bearlylegal.jpeg
      c2patool --certs bearlylegal.jpeg | openssl x509 -text | less
    • View it at Adobe/CAI's Content Credentials online service. While this web service currently isn't as informative as the command-line c2patool, it does provide information about the file's C2PA metadata.
    If you try solving this problem, either with software or as a conceptual exercise, I'd love to hear your results! I hope people include information like:
    • What's your background? Inquisitive amateur, student, software engineer, law enforcement, legal, professional investigator, or something else?
    • What tools did you use?
    • What were some of your observations?
    • What other issues should we consider?
    • Do you think you could prove innocence or reasonable doubt?
    • Let's turn the problem around: If you were working for the prosecution, do you think you could get a conviction?
    I look forward to hearing how people did!

    [Spoiler Alert]

    * If you want to evaluate this problem on your own, come back to this section later.

    If you go through these various tools, you'll see:
    • The metadata says it's from a Leica camera and is explicitly associated with Narayen. (For this forgery, the metadata looks authentic because I copied it directly from a real Leica photo before changing the dates and attribution.) The GPS coordinates identify Adobe's headquarters where Narayen works.
    • The cert signer's information looks like a Leica certificate (complete with Leica's correct German address) because I copied the cert's subject information from a real Leica cert.
    • The C2PA checksums and signatures are valid. Programs like c2patool do not report any problems. The only issue (introduced after an update a few days ago) comes from the Content Credentials web site. That site says the cert is from an unknown source. ("Unknown" is not the same as "untrusted".) If the vindictive person wanted to pay $289 for a trusted signing cert, then even that warning could be bypassed. Every C2PA validation tool says the signatures look correct; nothing suspicious. (They were forged using c2patool, so they really are valid.)
    • The picture's timestamps predate the disagreement between Narayen and the vindictive person. (Even if you can show it is forged, you don't know who forged it or when. The vindictive person is effectively anonymous.)
    According to the C2PA metadata, this picture came from Narayen. The picture has valid authentication and provenance information.

    For reasonable doubt, you'll need show that C2PA's metadata can be easily forged and the metadata is unreliable. (If Narayen's attorneys are smart, they'll reference the Nov 28 CAI webinar on YouTube (from 16:37 to 17:32) where DataTrails explicitly demonstrates how C2PA is easy to forge with a few simple clicks. DataTrail's solution? They authenticate using non-C2PA technology. This shows that other experts also realize that C2PA doesn't work for validation, tamper detection, establishing provenance, or providing authentication.)

    To prove his innocence, you'll need to prove it is a forgery. (In this case, I intentionally backdated the metadata to a time before Leica supported C2PA. However, if the vindictive person didn't make that kind of error, then there's no easy way to detect the forgery.)

    Worst-Case Results

    Given all of these findings, there are a few other things to consider:
    • Law enforcement, attorneys, and the courts are not very technical. If the file's metadata says it's his name and it has a valid signature, then it's valid until proven otherwise. Remember: digital signatures are legal signatures in a court of law; they are accepted as real until you can prove tampering. (And saying "I didn't do that" doesn't prove tampering.)
    • Narayen can say "that's not my picture!" While Leica may be able to verify that the cert isn't legitimate, Leica is in Germany and Narayen is in the United States. That makes serving a subpoena really difficult. In general, law enforcement (and everyone else who isn't Leica) cannot verify this. Also, Leica is a big company and can have multiple certs. Maybe they just don't remember creating this one or maybe it was part of a limited beta test.
    • C2PA's trust model assumes that a forged certificate will be eventually noticed. However, Narayen doesn't have months or years to wait for the forged certificate to be reused with some other victim. And that's assuming it is reused; it doesn't have to ever be reused.
    • You can try to explain that the cert only validates that the data existed and hasn't been changed since signing. But the courts see the words "authentication" and "provenance" and "certified" and "verified" and "validated". The evidence clearly says it is attributed to Narayen.
    • You might see flaws in the authenticated forgery. The prosecution will claim that the flaws are evidence that Narayen tried and failed to hide his identity. (As many people in the legal system have said, " We don't catch the smart ones. ")
    • While the C2PA tools don't identify any problems, you might notice problems if you use other tools. In that case, why even bother with C2PA? But that's a rhetorical question and the answer carries no weight in court. The fact is, the metadata identifies Narayen and the cryptographic signature for authentication and provenance says the metadata can be trusted.
    • Worse: even if the signature appears fake, it doesn't mean Narayen didn't do it. Remember: there is other metadata besides C2PA's metadata that names Narayen. There are also multiple pictures naming him, and not just one photo.
    • This is a very technical topic. Really technical explanations and jargon will quickly confuse the courtroom. Remember: The judge still thinks a FAX machine is a secure data transmission system and most jury members don't know the difference between "Google" and "the Internet". Assuming you can identify how it was forged, communicating it to the judge and jury is an uphill battle. (Creating a forgery in a live demo would be great here. However, while live demos are common in TV crime shows, they almost never happen in real life. Also, live demos can go horribly wrong, as demonstrated by the OJ Simpson trial's "if the glove fits" fiasco. No sane attorney would permit you to perform a live demo.)
    • Even if you, as the expert, can explain how it was forged, your testimony will just appear to be you trying to discredit the certified authenticated provenance information. Remember: C2PA claims to be tamper-evident. But in this case, everything checks out so there is no evidence of tampering.
    • Most people can't afford, don't have access, and/or don't know an expert witness who can determine if the C2PA metadata is legitimate. As the CEO of Adobe, using his own employees as experts carries little or no weight. (Any expert from Adobe is clearly biased since Narayen can fire them at any time.) Law enforcement and the courts will assume: If it says it's from Narayen and the tamper-evident C2PA says there is no evidence of tampering, then it's from Narayen.
    • Let's pretend that you can identify the forgery, demonstrate that C2PA does not work, and communicate it clearly to the court. It's now your word against every technical expert at Microsoft, Intel, Sony, Arm, DigiCert, and a dozen other big tech companies. Who has more credibility? Hundreds of highly paid security and cryptography professionals or you? And remember: these big companies have their reputations on the line. They have a financial incentive to not be proven wrong
    As an online service provider, I've interacted closely with NCMEC and ICACs for over a decade, and with attorneys and law enforcement for even longer. I can tell you that the prosecution won't spend much effort here. The cops will knock on his door. Narayen won't be able to convince the courts how it happened, and he'll either be found guilty or his attorney will convince him to take a plea deal.

    Narayen's only option in this fictional scenario is to demonstrate that C2PA does not verify the metadata, the metadata can be altered, anyone can sign anything, and C2PA doesn't provide validated provenance and authenticity -- even though it's in the name: C2 PA . I'm not a lawyer, but I think this option also could show that every company currently selling products that feature C2PA are actively engaged in fraud since they know what they are selling doesn't work.

    Either C2PA doesn't work and Narayen walks free, or C2PA works and this forgery sends him to jail. That's the worst case scenario, and it's very realistic.

    Truth or Consequences

    If this fictional child porn example seems too extreme, then the same application of fake C2PA metadata works with propaganda from wars (Ukraine, Gaza, etc.), insurance fraud, medical fraud, fake passport photos, defective merchandise claims at Amazon and Etsy, altered photojournalism, photo contests, political influences, etc. At FotoForensics, I'm already seeing known fraud groups developing test pictures with C2PA metadata. (If C2PA was more widely adopted, I'm certain that some of these groups would deploy their forgeries right now.)

    To reiterate:
    • Without C2PA: Analysis tools can often identify forgeries, including altered metadata.
    • With C2PA: Identifying forgeries becomes much harder. You have to convince the audience that valid, verifiable, tamper-evident 'authentication and provenance' that uses a cryptographic signature, and was created with the backing of big tech companies like Adobe, Microsoft, Intel, etc., is wrong.
    Rather than eliminating or identifying fraud, C2PA enables a new type of fraud: forgeries that are authenticated by trust and associated with some of the biggest names on the tech landscape.

    A solution for assigning authentication and provenance would go a long way toward mitigating fraud and misrepresentation. Unfortunately, the current C2PA specification is not a viable solution: it fails to authenticate, is trivial to forge, and cannot detect simple intentional tampering methods. It is my sincerest hope that the C2PA and CAI leadership tries to re-engage with the wider tech community and opens discussions for possible options, rather than making sudden unilateral decisions and deploying ad hoc patches (like requiring pay-to-play) that neither address the basic problems nor encourage widespread adoption.

    Značky: #Forensics, #Network, #Security, #FotoForensics, #Programming

    • chevron_right

      Failures in Automation

      pubsub.slavino.sk / hackerfactor · Monday, 11 December - 22:47 edit · 12 minutes

    I usually follow a simple mantra: if it can be automated then it should be automated. However, while automation may seem like a great solution, it introduces a new set of perils. Unexpected critical points, untested conditions, and unforeseen failures can lead to new problems.

    At FotoForensics , Hintfo , and my other services, I use a lot of automation. I have tools that detect and respond to network attacks, terms of use violations, server monitoring, and basic system management. However, I never just deploy an automation and walk away. I never just assume that it works.

    When I release new automated solutions, I usually spend as much time testing, monitoring, and adjusting the new system as I do developing it. Sometimes new problems are identified quickly and are easy to resolve. Some issues take a while to surface, and some have no easy solutions. A few times, I've had automated scripts fail so badly during the initial testing that they had to go back to the drawing board or were treated as a failure and a good learning experience.

    Unfortunately, my overly-cautious approach to software deployment seems to be the exception and not the norm. Often, companies deploy automated solutions without any deep review.

    What's for dinner?

    At our local grocery store, they removed more than half of the checkout aisles and replaced them with self-checkout kiosks. The space required by 3 manual checkout counters can fit six kiosks. In addition, one employee can (frantically) manage all six kiosks rather than one employee per counter. When I visit the grocery store, they usually have 10 of 16 kiosks open with little or no wait. (They open the other six during the busy periods.) And while they still have eight counters available, usually only 1 or 2 are open for the people who don't want to use the self-checkout kiosks.

    On the positive side:
    • Automation seems to reduce lines at the grocery store. I rarely have to wait for the kiosk. In contrast, grocery stores that don't have automated kiosks usually has long lines even when the store doesn't seem very crowded.
    • Around here, every store has a "Help wanted" sign. Automation allows the store to operate with fewer employees.
    • I'm not advocating the replacement of employees with machines. However, the existing employees can be moved to other essential tasks, like restocking shelves and helping customers.
    Unfortunately, there is a down side to checkout counter automation:
    • Saving money on employees does not translate into lower prices. Because there is less human oversight, it's easier to steal from these automated kiosks. Why pay extra for that "organic" apple when you can choose the lower-cost generic (inorganic?) apple from the kiosk's menu? Or maybe scan one box of Mac and Cheese but put two in the self-bagging area? I suspect that the increase in theft is part of the reason that prices have increased even through employee-related expenses has decreased.
    • These machines are not always easy to use and customers often need assistance. At my grocery store, self-scanning coupons is usually more miss than hit.
    Some stores are starting to re-evaluate their automated self-checkout systems. A few are even removing them altogether.

    The problem isn't that the kiosks don't work. Rather, while automation solves some problems, it creates opportunities for new problems.

    Neither snow nor rain nor heat nor gloom of night

    The grocery store kiosks usually work well. They are mostly easy to use. (Even with coupon scanning problems and the occasional double-scan, I'd give them very high marks.) However, not all kiosk are designed well.

    For example, every few years, my bank installs a new ATM machine. Sometimes the machine interfaces are really easy to use, while other versions are confusing and take twice as long to use. You can tell when the ATM interface is bad because more people go into the bank for assistance.

    And then there's the US Post Office. It's the holiday season and the Post Office has long lines of people waiting to mail gifts and packages. Our Post Office has a couple of automated self-service kiosk (SSK) machines, but almost nobody is using them. These SSKs have no waiting line and are located right next to the long line of people who are waiting for assistance. (You can't miss these machines!)

    It isn't that the SSKs are down or out-of-order. Rather, the user interfaces are designed so incredibly poorly, that people would rather spend 45 minutes waiting in line for human assistance. The few people using these SSKs seem to fall into one of three categories:
    • They spent a lot of time earlier learning how to use them, so they know what selections to use.
    • They think they might battle the confusing interface faster than waiting in the long line. (Sometimes this gamble pays off, sometimes it doesn't.), or
    • They have a friend holding their place in line, just in case they can't figure out how to use the SSK. (Seriously. You often hear someone say "can you hold my place in line for a moment?" before trying their luck at an SSK.)
    Then again, if you succeed in using the Post Office's SSK, you might get asked by a few strangers to help them, too.

    Et tu, Etsy?

    Etsy is an online marketplace for handmade goods and is the epitome of automation gone wrong. For example, earlier this year , Etsy's rolled out a filter to remove any Etsy listings that also appeared on the Chinese (cheap / knock-off goods) site called Temu. The problem is that some Temu accounts appear to steal images and product descriptions from Etsy. As a result, legitimate Etsy sellers are having their handmade products delisted. In some cases, Etsy even shuts down the legitimate Etsy shop. A few examples from the Etsy forums:
    • " Etsy removed my handmade ceramic listing ": A user has repeatedly had their handmade bottles removed. Keep in mind, the bottles look handmade, are signed by the seller, and there are videos showing how she makes the bottles. Another Etsy seller responded:

      I had a listing removed two months ago and after opening a support request with videos showing my process I was able to get it reinstated after two weeks of waiting. However, the exact same listing was removed again last week for the same reason so even if you prove you’re handmaking the item, they may still remove it in the future. I’m hoping if they reinstate a listing it doesn’t still count as a strike against your shop since it seems this will continue to happen (in my experience)


    • " China has stole my product and photos! I can't get Etsy to help. ": A seller laments that their product photos are being stolen by knock-off sellers from China.
    • " Etsy destroyed my store. They are responsible for their own downfall. ": Again, legitimate handmade items were delisted by Etsy because knock-off sellers copied her photos.
    • " I need some help with handmade policy violation - at wits end ": The seller uses an engraver and uv printer and is having custom items removed. One of the replies identified the likely cause: "The bots are taking over, so they may not be sophisticated enough to distinguish between similar silver tone keychains over a pure white background with similar text/sayings, etc."
    A few Etsy users have posted advice for getting products or account reinstated, but your success at any of these tips is really hit-or-miss.

    Etsy's Amber Alert

    This isn't the only automation and filtering problem at Etsy. Back in 2016, a child died after choking on amber teething beads that had been purchased on Etsy.

    I'm not going to dive into this loss of a child or even the merits of the court case. Rather, my focus is on Etsy's reaction: they banned products that included the word "amber". The initial ban appears to have been automated and does not pay attention to the context. "Amber color?" Nope. "Amber is my first name?" Nope. This forum discussion really describes the problem well (my bold for emphasis):

    Listings deactivated for using the word amber to describe glass bead colour
    by TheBeckoningCat Post Crafter ‎05-14-2022 10:36 AM

    Received a deactivation notice from Etsy regarding the word "amber" appearing in my description. I cannot get thru to Support by any means. In my description of the bracelet, I mentioned that the Swarovski squares were of an "amber color". Swarovski, to my knowledge, does not offer any crystals made from amber. I have since changed the description to "honey brown color". Perhaps in the future, when your "bot" or algorithm comes up with results for people selling "amber" a human actually review them to determine whether actual amber is being sold. I just did a simple search for the word "amber" and came up with over 132,000 results, just in the US alone. The people who are selling Amber Heard T-shirts will have to revise their listings as Johnny Depp's ex-wife.

    Reply by BlackberryDesigns Conversation Maker ‎05-14-2022 11:50 AM

    I would get rid of the word Swarovski , also. I got hit on that one from my website. Apparently since making the shift and removing their crystals for sale to the artists, they are doubling down on their brand name and do not want it associated with us little guys.

    Reply by JDTotesnDolls Community Maker ‎03-14-2022 04:17 PM

    The bot is designed to look for the word amber and not to make decisions on whether or not it is a color or an actual bead.

    Contact Etsy and ask them to manually review the listings and with the removal of the word, they may okay a relist,

    Unfortunately, Etsy's use of the ban-hammer seems inconsistent at best . The Etsy bots appear to use poorly defined rules that are applied irregularly and enforced occasionally, resulting in confusion among their sellers. Adding to the problem, the only real solution is to talk to a human in their support group, and that seems like a Herculean task.

    The problems related to bad bots and automated filtering is more than just an inconvenience for users. Some Etsy sellers have reported that scammers are using Etsy's poor filtering services as a front for blackmailing sellers. For example:

    ( I'm the bot in charge of security ) HELP
    by KummLeather Inspiration Seeker ‎09-15-2023 04:49 PM

    hello, I received such a message, does anyone have information about this?

    "Hello, my name is Jackson, I'm the bot in charge of security. You have received a complaint that you are a scammer, in order that your account was not blocked send me your name and surname, as well as your e-mail.
    You will need to be verified today, in the worst case your account will be blocked.
    Send me your first name, last name and e-mail!!!!!"

    Etsy support bot
    by Bellayall Inspiration Seeker 09-15-2023 03:56 PM

    I just received a message from someone claiming to be an Etsy support bot. He said that the product I shared was reported and asked for my name, surname and email address.I'm new to Etsy and didn't know it was a scam so I gave her what he wanted and then he blocked me. Is this a problem please help


    "Is this a problem"? Yes. Yes it is.

    Choke Points

    A heavy dependency on automation also creates central points of failure in critical systems. Earlier this year, a failed update by the FAA caused thousands of flight cancellations across a wide range of airlines. A few months later, Southwest had their own software failure that caused them to cancel thousands of flights.

    Keep in mind, these were not cyber attacks. These were just system failures in critical systems. These single points of failure were associated with the automation of their day-to-day operations. This is why a single computer outage can stop both automated and manual operations.

    Ideally, critical services should have failover backups. Ideally, the operators should have tested for these scenarios and had viable workarounds. However, automation often results in unidentified choke points and a lack of immediate options.

    This limitation is not restricted to critical infrastructures. Our local library has had a few instances where the self-checkout book kiosks have gone offline. One librarian said the kiosk outage was related to their new weekly backup system. Fortunately, they do have a workaround: They put up "out of order" signs and manually handle checkouts at the front desks.

    analysis.php?id=8a4beb98e7cdba55c314fc9c36f2e621cd2df8e2.114509&fmt=orig

    Welcoming Our New Robot Overlords

    Unfortunately, I'm seeing more instances of people relying on automation without testing. I'd cite specific instances of people mistakenly relying on ChatGPT, but there were too many references to choose from! Here's a few examples:
    • Legal : An attorney used ChatGPT without checking the results. It made up fake citations. The attorney ended up getting sanctioned by the court.
    • Legal : A different attorney was suspended after using ChatGPT and not noticing that it was citing fake cases.
    • Legal : Another attorney was fired after using ChatGPT.
    • Medical : Researchers found that ChatGPT was usually wrong when responding to a medical question. (It was correct 10 out of 39 times.)
    • Summarization : When asked to generate automated summaries, ChatGPT often makes up results.
    • Factuality : Poynter reported that, when fact-checking results, ChatGPT sometimes reached accurate conclusions, but "struggled to give consistent answers, and sometimes was just plain wrong."
    Just because a solution is deployed, doesn't always mean it's a perfect solution.

    A few companies have managed to get automation to work quite well. For example, I recently needed to return an item to Amazon. I went down to my local Whole Foods (where Amazon has a kiosk) and was able to effortlessly follow the instructions to return the item. (The hardest part was opening the cellophane bag that they provided.)

    I also drove through Kansas this summer. Part of the trip included a tollway. I had affixed the free tollway pass to my car a month earlier. As a result, I managed to bypass the long line of cars at the tollbooth and I never came to a stop. This was easy and much less expensive than paying at the booth.

    It seems to me that the success of the automation really comes down to the company's focus. Companies that are consumer-focused, like Amazon, the Kansas tollway, and the grocery store, have fewer usability problems but introduce new potential venues for fraud. In contrast, profit and process-oriented automated, like Etsy and the Post Office, seem to generate more problems than they attempt solve.

    Značky: #Forensics, #Programming, #AI, #Network

    • chevron_right

      Learning New Tricks

      pubsub.slavino.sk / hackerfactor · Saturday, 25 November - 22:38 edit · 5 minutes

    I recently presented a short version of my " No-NOC Networking " talk to a room full of managers C-level executives, policy makers, and technical evangelists. These are not the people in a network operation center (NOC), but it did include people who manage the people in the NOCs. For this presentation, I lowered the technical level to someone who hasn't taken a basic networking class in years. The talk was very positively received.

    Most of the questions were exactly as I expected, like "Where can I get your software?" and "What were those Linux commands to turn off scanner responses?" (The answer to both is at the Nuzzle web site). But there were also a few people who had the same kind of unexpected request: Where can I learn more?

    They weren't asking about learning more ways to deter network attackers. Rather, they were asking about where they could learn more about security in general. A few people confided that they weren't sure if they were too old to learn.

    Full stop: You are never too old to learn about security. Whether you are looking for a late-in-life occupational change or just a new hobby, you can always learn this as a new skill.

    Where to Start?

    I often hear people talking about starting with a certification, like CISSP , CEH (certified ethical hacker), or some of the SANS courses. However, I think that's like diving into the deep end of the pool. (As an aside: this isn't a recommendation for any of these certifications. As someone who tracks down cyber bad guys for a living, I've seen more unethical behavior from people with CEH credentials than any other group!)

    Before you get too deep or start paying for some kind of education, start by finding out what you like. There isn't just one kind of "computer security". What's your interest? Here's a short sample of different cyber areas:
    • Cryptography (great for math and puzzle people)
    • Network security
    • Policy
    • Reverse-engineering
    • Social engineering
    • Red team (offense)
    • Blue team (defense)
    • Hardware and IoT (internet of things)
    • Software (fuzzing is fun!)
    • Physical security, including lock-picking
    • Anonymity and privacy
    • AI and counter-AI (yes, there's a security element)
    This is far from everything. Most of these categories include forensics (detection) and anti-forensics (avoiding detection).

    Don't know which one to choose? Try them all and find what you like! (Personally, I like the weird stuff, like file format forensics and packet-level network forensics. But I've also worked with everything else in this list.)

    Groupies

    Besides trying to learn on your own, there are tons of conferences . Most weeks have multiple conferences worldwide. While conferences usually require paid admission, a few are free or even online.

    There are also tons of meet-up groups. Many of these groups are part of larger organizations. For example:
    • The Open Worldwide Application Security Project (OWASP) started with a focus on web-security best practices. However, it has evolved. Today, it mostly focuses on policies and processes for securing generalized applications. The organization has individual satellite chapters that hold monthly meetings all over the world.
    • DEF CON is a huge hacker conference that is held once a year. However, it has spawned lots of smaller " DEF CON groups " that meet monthly. Most are identified by their telephone area code. For example, Denver is area code 303, so their local DEF CON group is " DC303 ". Unlike OWASP, the DC groups usually have topics that span the entire spectrum -- software, hardware, social engineering, etc. Often, they include live demonstrations and how-to information. Some of these groups meet in person, while others are online.

      If you're new to DC groups and you don't like one topic, then wait a minute and there will be a different topic. The only warning: the content can be extremely detailed and discussions may quickly go over your head.
    Most of these groups are friendly, helpful, and welcoming to new people. Also, most of them look down on using technology for evil, malicious, or illegal purposes. You're not going to learn how to compromise your ex's Facebook account or how to steal money from an online transaction.

    Can't find a local group? Try using Meetup . Search for your city and the "Technology" category. In Fort Collins (where I am), we have "Women Who Code", "Fort Collins Internet Professionals" (FCIP), Northern Colorado Hackers (NoCo Hackers), a couple of Python developer groups, web developer groups, and more. And keep in mind, Fort Collins isn't a "big city"; big cities have even more groups. Unless you're out in the middle of nowhere (sorry, Casper, Wyoming ), there's probably something nearby.

    Hands On

    Beyond groups, many organizations offer various games where you can try tools, techniques, and methods in a controlled and safe environment. (I liken it to how cats sharpen their claws.) The games often include different skill levels, from newborn novice to guru expert. In my opinion, the real-world problems are nowhere near as difficult as the harder games.

    So how can you find these games?

    If you ask in any of the social groups (OWASP, DC, etc.) then someone is bound to provide some suggestions. But even without group participation, there are lots of 'capture the flag' (CTF) opportunities out there. These include challenges and puzzles that award points for completion. Some are meant for individuals, while others permit teams. (Often, teams are looking for new members. It's usually easy to find a team that will take on a new person.) Some of the better-known CTFs include:
    If you really enjoy these CTF games, then there are competitive teams. Many of the larger conferences have CTF contests with prizes for the winners.

    Personally, I find game play to be a great way to teach and test knowledge. At my FotoForensics service, I include a few ' Challenges ' (Tutorials → Training → Challenges) where people can try to evaluate pictures in a controlled environment.

    New Tricks for Old Dogs

    Just as there are different security focuses, there are also different ways to learn. Regardless of whether you prefer self-paced, hands-on, one-on-one, or a classroom environment, there are plenty of options. After you find your interest and get a taste of the technologies, then you can start focusing on formal certifications and professional education... or you can be an informed amateur.

    Most companies, universities, and news outlets focus on cybersecurity as a career . (OMG! 650,000 cyber jobs are now vacant !) However, it doesn't have to be a career. These topics have benefits even in small amounts. With a little practice, you will start noticing fraud and scams, identifying poor security practices, and distinguishing the real threats from hype. The fundamentals used to include reading, writing, and arithmetic. Then it expanded to some computer literacy. Today, a little computer security knowledge is becoming a fundamental requirement. It's time to start learning!

    Značky: #Forensics, #Programming, #Security, #Conferences, #Network

    • chevron_right

      Making RADIUS more secure

      pubsub.slavino.sk / networkradius · Friday, 24 November - 12:00

    As we’ve previously discussed, there are several insecure elements in RADIUS. We are currently working in the IETF (Internet Engineering Task Force) to close those gaps and improve security for everyone. This article outlines some of the current shortcomings of RADIUS, best practices for mitigating against them, and a roadmap for how these vulnerabilities will be addressed within the RADIUS standard.

    Značky: #Network, #articles

    • chevron_right

      How to customize an OEM instance of FreeRADIUS

      pubsub.slavino.sk / networkradius · Friday, 24 November - 12:00

    As the most popular RADIUS server in the world, FreeRADIUS is used by many hardware vendors. They ship their products with FreeRADIUS embedded as an embedded or “OEM” product. It is common for them to need some additional features or some customizations which are not part of the core FreeRADIUS functionality.

    Značky: #Network, #articles