Is saving a dark web page locally and reloading it in another browser a security risk?

Likely
That depends all on what scripts the page might be running. If the page contains malicious code that is trying to de-anonymize you, then it is a risk.
If the page has <script src="//example.gov/trackUser.js"></script> this is what happens using the Tor Browser:

The script is downloaded via Tor, so your IP is not revealed to the tracking source, which I called example suffixed by .gov to highlight the interest in mass surveillance
TrackUser script, if Javascript is enabled, may or may not invoke REST methods from example.gov and these are routed via Tor as well

Now, remember that scripts can inject other scripts (think about Angular's lazy loading) that are not known to the HTML at rendering time, and perform REST calls.
When you open the saved page with a regular browser, you will open a local copy of trackUser.js

The script is loaded locally because it has been saved along with the page, so your IP is not revealed
Any AJAX call or injected script will be downloaded from example.gov revealing your IP address

This risk must be mitigated by proxying the regular browser via Tor.
Risk of fingerprinting
Another reason why you should not open a dark page in a browser other than Tor is the risk of browser fingerprinting. This because normal browsers don't do enough to protect users from fingerprinting. Tor Browser tries to do so. I used this wording because I am skeptic about the following sentence

In the end, the approach chosen by Tor developers is simple: all Tor users should have the exact same fingerprint. No matter what device or operating system you are using, your browser fingerprint should be the same as any device running Tor Browser (more details can be found in the Tor design document).

Even if you proxy via Tor Socks, example.gov can still get an AJAX request containing a potentially unique fingerprint.
Reference: https://amiunique.org/
Final line
You should not try to open dark pages you don't fully trust or didn't vet early in a non-anonymised environment.


Rate limit login attempts: count by IP or username

I would say that you should do both.

If you only rate limit on IP address, an attacker controlling a bot net could brute force an account with a weak password. If you have 10 000 computers with unique IPs and each one is allowed four attempts per hour you can try almost a million passwords per day.

If you only rate limit on username, an attacker with a list of existing usernames could brute force accounts with a weak password. Chances are that a few of your users use one of the top 10 passwords, so if you try those on all accounts you will get in somewhere.

Of course you could do all sorts of combinations. For instance you might only block a username once X different IPs have failed to log in with it, so that an attacker trying to block a user from logging in needs to work a bit for it.


There's a big distinction between pen testers who write a bit of code, and developers of security tools.

During a pen test, you may need to write some custom code. For example, if you find server-side template injection, there's likely to be no off-the-shelf exploit that works in this exact scenario. But with a little bit of coding you can get a shell. These scripts just get the job done; design patterns are irrelevant.

Many security tools are much more complex than one-off scripts. Metasploit is a good example. Before Metasploit, most exploits were developed like one-shot pen test scripts. The exploit would target a specific vulnerability and deliver a specific payload. Metasploit introduced modularity and structure into exploit development. In particular, separating the concepts of: exploits, payloads, and encoders.

In fact, there are now all sorts of security tools that are developed with strong design practices in mind, although a lot of these are commercial, e.g. Nessus, Checkmarx, Burp Suite.


A security warning when accessing a site through IP

It's because you generally create a TLS Certificate for an hostname, not an IP. Changing IP addresses is trivial, changing domains are not that common.

If you open the site in Firefox using IP, you will see this message:

66.33.204.254 uses an invalid security certificate.

The certificate is only valid for the following names:
 schneier.com, www.schneier.com

Opening 216.58.211.14 (Google) will give the same message.


Risk in not expiring an "unsubscribe" link

I can not see any real disadvantage for your users.  The worst that could happen to them would be to have to resubscribe.

Note that with the current efforts put in anti-SPAM regulations and controls, every one with a mailing list should be extremely careful to properly maintain it.  You certainly much prefer to have someone opt-out than having them report your message as SPAM.


Is it important for a web application's middle-tier to use a different communication protocol?

Using a different stack / transport protocol doesn't significantly reduce much risk.

client --([1]http)--> frontend --([2]binary)--> backend --([3]mssql/odbc/?)--> database

Three protocols labeled [1], [2], and [3]. If an attacker compromises the frontend server, it doesn't matter what protocol is used for [2]. The attacker will have the same permissions as any process running on the front end, regardless of the protocol used for [2].

I'd put less energy in swapping protocols and more energy in monitoring the traffic from the frontend to the backend. That traffic is more likely to show anomalies because frontend to backend traffic is usually clearly defined. Client to frontend traffic is not as easy to detect anomalies because every browser, every scanner, every hacker is trying to break in all the time. But if you are able to detect that a compromise has already taken place, you're going to be able to mitigate damage.

Back to your protocol question. Because HTTP is clear text, it is easier to monitor. You can detect unusual requests, and alert your incident response.

Just my 2 cents.


multi tenancy and microservices API authentication/authorization

https://blog.andyet.com/2015/05/12/micro-services-user-info-and-auth/

The above blog entry suggests keeping object level permissions within each microservice.  So you can authenticate and pass along user_id (or group_id) via something like OAuth 2.0 and tokens, but do the actual work of authorization / filtering response within the microservice.

This approach keeps the "loosely coupled" spirit of microservices.


What algorithm should I use to avoid the error "ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY"?

That warning is caused by the size of the group used for ephemeral Diffie Hellman key exchange being too small. So small that the symmetric keys can be extracted by academics.

The certificate does not affect the size of the group used for DHE. The configuration of the web server does.

Currently the recommendation is that the group size in bits should be as large as the RSA key for the certificate, usually 2048 bits, and in any case no smaller than 1024 bits. Also, you must generate your own group, not use a predefined one, or else 1024 bits is not enough.

Make sure your server does not support intentionally weak "export" crypto - that means 512 bits.

Use Qualys tool to check the server configuration.

Java docs.


It would be in theory possible that google gets infected and serves malware, although I consider this highly unlikely. More likely is that such an attack is done by malicious browser extensions or attacks through advertisements (malvertisement), i.e. things which are outside of the control of google. And of course a man in the middle attacks might be possible too, especially if you have already one of the known bad certificates on the computer or have an ad injecting software installed.


Asymmetric encryption and signature performed by hand

James Ellis at GCHQ came up with a pen-and-pencil example of public key cryptography, something he called "non-private encryption."  He intended it as an illustration of a public key system.

The gist of his system is something like this:  You start by creating a lot of short riddles, each having a unique solution, which could for practical purposes be mathematical equations.  For each of these riddles you create an encryption key.  The intention is that the solution to the riddle is the ID of the key.  The full list of (riddle [ie. key ID] / encryption key) is posted somewhere public.

When someone wants to send you a secret message, they pick a pair at random.  They solve the riddle, to get the key ID.  They can then encrypt the message they only want you to see, by using the key they chose from the list.  So that you can decrypt the message, they note the key ID somewhere in cleartext in the letter head.

The secrecy of this system depends on the number of riddles, and the time it takes to solve each one for the key ID (an attacker with the all key IDs can simply look up the key).  For instance, if you have 10,000 pairs, and each riddle takes a day to solve, it should last about 30 years against a single attacker.

References:

http://cryptocellar.org/cesg/ellis.pdf
Steven Levy: Crypto: Secrecy and Privacy in the New Code War


How can I tell if a user is access website with a forged IP?

First of all, you can't spoof your IP on a TCP connection. Spoofed IPs are broadcast-only.

As for being able to tell if a user is relaying or proxying his traffic off another computer, some tell-tale signs might include:

Same cookie despite different address
Same browser fingerprint
Known proxy/relay IP address
Many users from a single IP address
Suspiciously-consistent timing

Though often it doesn't matter. If it's a single attacker or multiple attackers exhibiting the same behavior, is there a difference? If a single attacker logs in from multiple computers in multiple locations, is that functionally different from relaying his traffic through proxies?

Consider all suspicious activity by its own merits. If it looks like someone is doing something they shouldn't be, then your best bet is to take action to protect against that behavior, not protect against that person. If a system is under attack, then secure the system; alter it so that the attacker can't succeed.


Can I compare 2 same encrypted files by checking it on binary mode?

It depends on how the API encrypts the file, and there are a LOT of possible variants here: symmetric (block cipher and stream cipher), or asymmetric, and different implementations of each one.
Some encryption modes employ something called random IV, and in practice it means that encrypting the same file multiple times with the same key will output different files each time. So even if the API is rightfully encrypting the file, the result from the API and the file you just encrypted will be different.
You will have to check what encryption mode the API is using. AES with a deterministic IV would work (like using the truncated hash of the file as the IV, for example). The vital part is to never encrypt two different files with the same IV, or it could leak information on the key.
Only if the API returns the same output every time you submit the same file, then it is possible to compare the hashes of the files.


Preventing exploits like ROP and Return-to-libc in modern Operating systems

I believe the standard anti-exploit setup is (on Windows and Linux at least): DEP, Stack Guard, hardened heap, and ASLR (sorry, I don't have a reference for this). As you point out, all these techniques can be circumvented, with varying degrees of difficulty, and ROP is one of the main techniques. ASLR provides some defence against ROP but I believe all the other ROP defences you mention are experimental and not used as standard. They may exist in certain anti-virus and host hardening products.

I work with a very skilled exploit developer, and he is usually able to create a reliable exploit for a memory corruption flaw, even with these defences in place. Bear in mind that many attacks these days are Java/JavaScript sandbox escapes where a large attack surface is exposed compared to a network buffer overrun. Also, a lot of exploits are use-after-free flaws which bypass Stack Guard and the hardened heap.


can multiple encryption of data with multiple keys increase the security?

Yes, multiple layers of encryption using different algorithms and different keys make the encryption as hard as the hardest in the chain.
IIRC this was adressed in Bruce Schneier's book Applied Cryptography (2nd edition).

But the important part is to use different algorithms, or at least different keys. Algorithms that use "round keys" are often optimized for a number of rounds. Using the same key will not necessarily make the message harder to break, and can theoretically make it easier.

A nice example is Triple-DES. Encrypting a message, then encrypting it again with a different key was vulnerable to meet-in-the-middle attack and effectively added only 1 bit of key space. Instead, it was found that one had to encrypt a message, then use the decryption algorithm but with a different key, then encrypt it again.
Even with 3 independent 56-bit keys, the effective key size is 112 bits as it is vulnerable to a meet-in-the-middle attack (source: Wikipedia).

So the strongest way is to use different keys and different algorithms.


Well - you are asking for trouble here with your current setup. Why do you have a deployment interface exposed to the web?

You need to add

IP whitelisting or host internally and connect into the network securely
2FA using an authenticator - SMS is out these days
Store the salted hash not the password
Use PBKDF2 or bCrypt for the hashing. Look up current suggested iterations numbers and imimplementation


What types of attacks and abuse does DNSSEC protect against?

Cache poisoning by implementing cryptographic signatures for zone transfers. If you wish to encrypt payloads then use IPSec


Is it easier to crack a ZIP file than a 7z archived file given they have the same password?

It depends on how the ZIP file is encrypted.

When you want to create a fully standard-compliant ZIP archive, then your only option for encryption is the ZipCrypto algorithm which is known to be seriously flawed.

However, many compression tools support a non-standard addition to the ZIP standard which allows to use different encryption algorithms, including AES-256, which is the same encryption algorithm the 7z format uses by default. When that option is used, 7z and zip are equally hard to crack.

Caveat: not every archive handler can handle AES-256 encrypted ZIP archives. Such tools can then no longer read the files in such archives. One such archive handler is the one built into Windows Explorer.


Why CSRF's JS can't read token by GETting html

JavaScript cannot read the content of other sites due to the same-origin policy.

This is one of the most fundamental principles of web security and goes way beyond CSRF protection. Without the same-origin policy, any website could read our e-mails through our webmailer, have a look at our PayPal account, get our private information from Facebook etc. So browser vendors do put a lot of effort into preventing this.

Like with all security mechanisms, there may be bugs. And there's also a specific attack called DNS rebinding. But all in all, the same-origin policy works very well and cannot easily be defeated.


How do I identify an unknown port/protocol that my IDS picks up?

Let's see, this should be easy: read a good paper like
Offline/Realtime Traffic Classification Using Semi-Supervised Learning

Then maybe mix in some knowledge from wholly understanding a single read through Statistical Techniques for Network Security (cheap, only $160 on amazon)

Then fire up your favorite text editor and code a little, but utilize RapidMiner or Weka because, well, coding those algorithms is too easy.

Finally spend a couple hours tuning up the algorithms and then your all set.

Sarcasm aside, the steps above outlines an academically popular way to creatively solve a lot of hard problems in security.  I wish I could say I could do the above proficiently - maybe you can write a tool to do it!


What is the key to detecting all IoT devices in your organization?

During procurement, have Finance and/or Internal Audit create and maintain a formal asset-registration process. All people managers must receive all procured devices/software and each approved vendor must provide a list of inventory services. Gaps in the inventory services automatically provided from the VARs must be filled in by the people managers using a checklist.

Business Process Example

People manager decides to procure an iPhone and an Android-powered thermostat for a remote worker who is a thermostat tester. The VAR who works with Apple provides the serial numbers, SIM card identifiers, telecommunication-provider IMEI, and MAC address for the WiFi component of the iPhone. The people manager turns on the iPhone to collect the Bluetooth BDADDR and submits it to the internal procurement asset-registration portal using a Standard-Operating Procedure (SOP) document. The manager then opens the box containing the thermostat, turns it on, and collects its WiFi and Bluetooth MACs using a separate SOP document in order to submit these to the procurement asset-registration portal.

At this time, I do recommend tracking at least SIM serial, IMEI/MEID, as well as Ethernet and Bluetooth MAC addresses. You may also want to track ZigBee, Z-Wave, RFID, and NFC identifiers.

Technology Platform Examples

SAP or Oracle Hyperion typically have ways of documenting procurements to asset codes to plant codes. For example, you can have SAP ECC document what was purchased when and where it went, perhaps down to the PDU level, e.g., a cage in a data center or a cube on a floor of a particular building.

Then the procurement system can have hooks to the IT/Ops CMDB or configuration-management database. Some of these include: Axios Assyst, BMC Atrium, CA Service Desk Manager, Cherwell Software, Freshservice, FrontRange, Hornbill, HP Universal UCMDB, IBM SmartCloud Control Desk (SCCD), iET Solutions, InvGate Assets, LANDESK Service Desk Suite, ManageEngine IT360 / ManageEngine AssetExplorer, Scalable Software, ServiceNow, SolarWinds Web Help Desk, and SysAid. If you want free, open-source projects to track inventory and configuration management, check out clusto.org, https://github.com/mozilla/inventory , or http://fusioninventory.org/overview/ -- (with -- https://www.fusiondirectory.org -- and perhaps -
 https://github.com/Normation/ldap-inventory).

Additionally, you can even link applications to an app inventory (or app portfolio, part of Enterprise Architecture Management aka EAM) with device inventory. Microsoft SCCM can do this with software tagging (either ISO/IEC 19770-2 and/or SWID tagging), but there are other solutions that do full EAM such as Software AG Alfabet.

IoT devices, in particular, leverage either on-device REST APIs or reach out to cloud-based REST APIs. These can be discovered, tracked, and managed using Application Discovery and Dependency Mapping (ADDM) solutions such as AccelOps, Cisco AppDynamics, AppEnsure, VNT IllumIT, and -- my favorite for its ability to integrate back to the CMDB -- ServiceNow ServiceWatch.


Secure way to save the local credentials?

Enterprise password managers offer you the ability to store these types of things in a central store for admins to use.

You can restrict access, log when people request credentials, and some interface directly with the device and change the credentials once used or act as a 'wrapper' so you ssh through the password system in order to get to the end device.

Lots of options. A quick vendor search will reward you with rich results.


If you draw back your VoIP "data path" (to use a simple name for the way the data packets may go through the internet), you'll see something like this in terms of steps:

You -> your ISP
Your ISP -> axvoice
axvoice -> wherever

You're guaranteed that axvoice->wherever is secure, through what they have said. You, however, are not guaranteed of steps 1 or 2, or at least not explicitely. You'll need to dig up the SIP defs given by Axvoice as to whether there is any form of end-to-end encryption (i.e. if the traffic all the way to you requires decryption). If there is, halleluiah. If there isn't, all is not lost: get on a VPN.


Storing private asymmetric key in application binary?

This quickly turns into a 'turtles all the way down' problem. You just have to decide at which point you stop encrypting things and rely on another method. I think the goal should be to stop casual users, but not determined hackers, to easily get at the protected data.

I wrestled with a similar method in a web application which needed to store the DB password and the SSL cert password. What I ended up doing was encrypting those passwords in a config file for the app using a different master password. The master password was stored as an environment variable set by the application startup script. Since the master password was set only in the startup script, it was easy enough to give a single user access to the script along with the ability to run it using standard UNIX file permissions.

My thinking was that to get access to this script otherwise, you needed to already be root, at which point, it doesn't really matter. If you can't trust root (or the server has been hacked) you probably have other issues.

Also, there's a little security through obscurity here in that all the details of how this works is not documented very well on purpose. You would have to backtrace how the startup script works, then figure out which algorithm is used, how the salt + plantext is formatted, etc. If you want to get the DB password and got this far, I figure you could probably already have just broken into the DB server directly.


Are requests with no UserAgent header a risk?

Not really, your understanding seems to be correct. Pretty much every web browser (and most other HTTP clients) will send a user-agent string, so arguably any request that arrives without one is pretty sketchy-looking. On the other hand, it costs basically nothing to send one (for example, with curl, use the -A argument) and is not guaranteed to have anything to do with the truth. Most clients, including browsers, let you spoof the UA string as anything you (the user) want it to be.

Of course, if you tell the server that you're IE 5 running on Windows CE, you might get back some really abysmally shitty HTML/JS - many web servers use UA strings to send different versions of web pages based on the expected capabilities of the browser making the request - but that's your problem, not the server's problem. Same goes for sending no UA string at all.

Security-wise, you could maybe put a speed bump in an attacker's way by blocking requests with no UA, or with an untrusted UA, but all that an attacker has to do is just spoof the UA of, say, the current version of Chrome (which is easy to find and easy to use). It's nothing more than a speed bump. I wouldn't even call it defense-in-depth, since it's so trivial to bypass.

I think your service provider really doesn't grok security, and is falling for what I call the "no legitimate user" fallacy (not to be confused with "no true Scotsman"). It goes like this: "OK, so there's a security threat if the user [does X]? Well, no legitimate user would do that, so we're safe." In this case, [does X] seems to be "spoofs their client's UA string". A lot of people just don't understand that an attacker can, and will, impersonate a legitimate user well enough that you can't reliably tell the difference until you've been exploited.

Well, either that or they just aren't aware that the UA string is nigh-meaningless and trivially editable.


PCI DSS - mask PAN and log individual access to PAN

I think you have a good approach. I find it interesting that users would complain about not being able to immediately identify card numbers when they can view the first six AND last four in your results table--it is unlikely that there would be two results with the same masked number.

The way you currently have it implemented is good because it has very detailed logging of access to cardholder data. However, if the user has a business need to be able to view any of the card numbers on file (the ones presented in the masked results table) there is no stopping you from displaying the full card numbers in the results table instead of the masked results.

I agree that the wording on the requirement is a little confusing:

  Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN

My rewording of the requirement would be this:

  Mask PAN when displayed for user without a business need to see the full PAN

If the user has a business need, there is no restrictions on how much of the data you show them at a time. The only difficulty for you would be implementing logging on which card numbers actually got displayed to the user. While this isn't as straight forward as the single card approach, there are a number of technical solutions you can use to address it either in the database or the application.


Is it possible to decrypt but not encrypt using the private key?

This is useful for validating that the message was sent by A.

It would prove only that the message was sent by someone who has the B's public key. It's not only A, but since the key is public, it's everyone.

  B [ ] cannot encrypt a message and
  decrypt it by itself using its private key.

Yes. Technically B cannot encrypt the message using their private key and decrypt it using the same private key. But B can encrypt the message using B's public key, since it's public.


To quickly answer these:

Mostly no limits, assuming we're talking about WPA2. The password goes through a key-derivation algorithm, so the key is a fixed size regardless of password lengths. Some device vendors may put soft limits on their control panels, but these are usually pretty lax. I'd avoid unicode characters though, since they're not always identical in terms of encoding across different systems.
As long as your password is complex enough and long enough, it'll prevent the WPA2 key from being cracked. What "enough" is depends on your security requirements, but for home use I'd say 12 characters a-z A-Z 0-9 (3.22×1021 keyspace) should be more than enough, as long as it's reasonably random. You're highly unlikely to come across attackers that use complex statistical analysis to test "likely" human-random passwords first - most aren't going to be doing anything more than a dictionary attack.
Standard practice in most corporate environments is to store paper copies of mission-critical credentials in a safe. If you wish to store such backups, invest in physical security. Your desk drawer isn't actually particularly secure, but it's in your house and your house has locks. Are you really worried about attackers that break into your house to steal your wifi password?
Don't bother. For a start, there are hundreds of password generators out there that already do this; keepass has a good one. Most importantly, you don't really need to worry about cryptographically strong random passwords - just pick something "random" manually, or use an existing generator if you're paranoid. There's no need to do anything more unless you're protecting mission-critical data.

All in all, it sounds like you're overthinking it. Your main threat is dictionary attacks, which you can thwart by not using any common passwords or dictionary words.


IPsec Transport Mode NAT Traversal Security Risks

I think the answer refers to the Transport Mode Conflict, which is described in section 5.2 of RFC 3948. If two clients behind the same NAT device connect to the same server using Transport Mode this might result in duplicate IPsec policies (i.e. between the NAT device's public IP and the server's IP). This means the server may only be able to send traffic to one of the clients (usually the one that connected last). If the traffic selectors include ports and protocols this issue might be avoided (unless they conflict) and in some cases it's possible to work around it (e.g. by using strongSwan's connmark plugin).

The term "inherent security risk" might be a bit harsh (note that I changed that on the FAQ page in the meantime), which is why newer strongSwan versions support NAT-T with Transport Mode. Although users should be aware of the potential caveats. The ikev2/host2host-transport-nat scenario in strongSwan's regression test suite illustrates two possible problems that could arise when using Transport Mode over NATs.

However, the developers of the FreeS/WAN project, on which strongSwan versions before 5.0.0 were originally based, had some very strict opinions about NAT Traversal with Transport Mode, which is why it had to be specifically enabled with a configure option (i.e. the code was not even compiled in), which is what the rest of the answer in the FAQ explains (if the option wasn't enabled, the error message clearly conveyed their opinion: "NAT-Traversal: Transport mode disabled due to security concerns").

By the way, the FAQ entry's answer is based on a quote form an email by Andreas Steffen (founder of the strongSwan project) from 2009, which, unfortunately, is not available in the mailing list archives anymore. But looking at old versions of the answer in the history of the FAQ page does point to this origin.

For completeness, there is a similar issue with Tunnel Mode over NATs (described in section 5.1 of RFC 3948) if two clients behind different NAT devices with the same private IP address connect to the same server. However, this can easily be avoided by assigning virtual IPs to the clients (which is what's usually done in roadwarrior scenarios).


HTTP request smuggling, basic TE.CL vulnerability

The "\r\n\r\n" words. It's like the image, it's interpreted, not written


It uses ephemeral (single use) Curve25519 points in X25519 (Curve25519 ECDH) for key agreement and static long term Ed25519 keys for authentication. Like basically every other protocol from around the same era.

If you want to know how some cipher suites for SSH work, you should read the RFCs or openssh documentation (for their extensions). For example:

https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-12

https://tools.ietf.org/html/draft-ietf-curdle-ssh-ed25519-ed448-11


Why don't CDNs require authentication to access static files?

The reason for this is large scale applications. When you have large scale applications, checking for authorization takes unacceptable amount of resources. Thats why static resources, like pictures, videos and other content, are stored externally on static CDN servers using a random token, and then the authorized response can include this token.

This means they only need a few replicated database servers, and then they can have large amounts of CDN servers that cache each other permanently.

Distributed servers is what makes rotation difficult aswell, as then the static CDN servers need to be told to rotate that value. And that incurs unacceptable resource usage, as that needs to be done periodically. As opposed to a random value only needs to be set at upload.

Even calculating a md5 hash, generating a random value or something that seems "simple", can be a heavy lift for a distributed CDN server to do.

So the server is a simple storage of files. Basically, all authentication and generating of random values happen on the "active servers" (that run code), while the static servers only store files based on filenames, and serves files based on filenames.


Can you get rid of the ZeroAccess botnet without a complete reinstall?

Some background: The Zeroaccess rootkit/botnet is a multi-purpose, highly resilient bit of malware. It causes compromised devices to participate in click-fraud and mine Bitcoins. Compromised devices participate in a peer-to-peer Command and Control network, which makes the botnet resilient against takedown measures.

Overall, it is a very clever bit of malware that is still being investigated in detail:

  Ross Gibb and Vikram Thakur will be presenting their findings from
  this operation at the annual Virus Bulletin Conference to be held in
  Berlin, October 2-4, 2013. In addition, a comprehensive white paper
  will be released soon to coincide with the presentation laying out the
  inner details of the ZeroAccess threat.

Given how well-written this malware is, the usual recommendation applies - the only way to be certain is to rebuild the device from known good media.

If this machine is one you use regularly, then you should strongly consider rebuilding it ("rebuild" here means to reinstall or restore your Operating System to factory defaults).

If you must give up some security in order to save time or money, then there are some removal tools out there from reputable vendors: Symantec, AVG, ESET, McAfee to name a few.

Perhaps if the infected computer is only used by your 8 year old nephew to play Angry Birds, you could consider just using a removal tool or process.


PHP - How to do safe input filtering in the light of multibyte encoding vulnerabilities?

In order to mount a proper defense against a threat you need to understand it.  Blindly layering encoding schemes is very dangerous as this can introduce a problem when by default this usually isn't an issue.  In general security problems related to encoding arise because escape functions can act upon data differently than they are interpreted. But that is not the only concern,  it can also confuse the programmer in that they think a string is escaped,  when its not.

The first concern is that escape functions can build dangerous strings for the attacker.

mysql_real_escape_string()  is a special function that knows what encoding type the database is using,  and adjusts its escaping to follow suit. There for there can never be a disconnect between the encoding method the escape function and the interpreter.   Simply using addslashes() can be very dangerous for this reason.

As an example lets use 0xbf27,  which is a single GBK character. addslashes() doesn't understand GBK,  it only understands ASCII.  If this string where interpreted as ASCII the first character would be 0xbf which is an unprintable ASCII character lets call ¿.  The 2nd ASCII character is 0x27 which is is a single quote '.   After addslashes() 0xbf27 becomes 0xbf5c27 or if it where printed in ASCII it would be ¿\'.  The problem is that 0xbf5c is a valid GBK character,  so addslashes() has turned a multi-byte character into 2 characters,  one of them being a single quote.  Another way of thinking of this is that the backslash is being consumed by GBK encoding.

Character consumption can be a problem without escaping functions.   Lets use SHIFT-JS and HTML as an example.  This example was taken from The Tangled Web:

...this is still a part of the markup...
 " onerror="alret('this will execute!')"

...the page continues...

In this case the "> at the end of the img tag are very important control characters that are being consumed.  The " is being consumed by the encoding scheme,  and then the > and some other text appears to be apart of the HTML src attribute,  its not until it hits the " onerror that the attribute is terminated.

...  But that's not all.    Lets switch gears a bit.  What about urldecode()?

<?php
$id=mysql_real_escape_string($_GET['id']);
$id=urldecode($id);
mysql_query("select * from user where id='".$id."'");

Do you see the vulnerability?  From my experience most PHP programmers don't see it.   The problem is that urldecode() can be used to build a vulnerable string,  lets say the attacker provided a string like http://localhost/vuln.php?id=%2527 or sleep(30)--.  Well just about every web application platform will automatically run a urldecode over all HTTP inputs.  So the contents of $_GET['id'] is actually %27 or sleep(30)-- That is because %25 was decoded into a % (% is hex 25).  After mysql_real_escape_string() or even addslashes() the value is still just %27 or sleep(30)-- After running urldecode() again,  the contents of $id is  now ' or sleep(30)--,  which is dangerous.

So as a hacker tip,  when I am auditing a code base that uses magic_quotes_gpc or something similar,  I grep though the code looking for decode functions,  like urldcode(),  htmlspecialchars_decode(),  base64_decode() and similar functions.   Even though,  the application runs addslashes() blindly on all input,  a decode function will allow the attacker to build his attack string.

So how do you defend your self?  Well test your code.   Some web application scanners will test for encoding flaws exactly like this.  In fact I researched this topic while building a vulnerable scanner.   Another point,  always sanitize input at the time of use, this avoids the problem of decoding after escaping.  You cannot know how it will be used,  so encoding/decoding/escaping everything will always be flawed.   Used parametrized queries for building sql statements.  UTF-8 is a great default in most cases (but not always),  and *most* of these problems don't arise with this muli-byte encoding scheme.


Can Origin headers be sent with get variables or the whole url?

Origin is a Forbidden header name, and standards compliant user agent should only send the domain name in the origin header. They cannot be modified programmatically in standards compliant browsers. Note that user agents that doesn't try to be standards compliant, such as curl, or very old browsers before the specification was written, may not enforce this restriction.


SSL Cert for sub.domain.com and www.sub.domain.com

A wildcard certificate is a public key certificate which can be used with multiple subdomains of a domain. Depending on the number of subdomains an advantage could be that it saves money and also could be more convenient.

Note: But Only a single level of subdomain matching is supported

The workaround could be to add every virtual host name in the Subject Alternative Name (SAN) extension, the major problem being that the certificate needs to be reissued whenever a new virtual server is added.

Because the wildcard only covers one level of subdomains (the asterisk doesn't match full stops), these domains would not be valid for the certificate: xxx.sub.domain.com


How to use VNC with SSH tunnel - "is this howto secure"?

If you are connecting to localhost (127.0.0.1) on an ssh forwarded port (the 5901 your forwarded), then yes your connection to the remote host is encrypted.


If I accept a root Cert what am I opening myself up to?

If I connect to a WIFI AP and it wants to install a root cert. They read my HTTPS traffic, Right?

Yes, they can read all of your HTTPS traffic including all of your passwords to any sites you log in to, all of your emails if you load your email, your credit card number if you buy something, etc. And it isn't read-only - it can tamper with them too, basically impersonating you to do anything they want, such as doing a bank transfer of your life's savings to their offshore account, if you log in to your bank.

  Does using OpenSSH on my cell phone to my home router help protect me? Or can this traffic be decrypted as well?

SSH doesn't need certificates, and the normal use case for it doesn't use them. It just compares keys directly, so a root CA won't compromise it. However, in practice, this won't be helpful, as any network that insists on a root CA will almost certainly not let you use SSH (or they may even try to MITM attack it too, but since the key would be different, you'd notice).

Note that accepting a certificate for a WPA-Enterprise connection is different than installing a root certificate for everything your device does. The former is safe and doesn't cause the above problems; only the latter is dangerous.


How to detect when one or more devices in my local network have become DDOS attack nodes?

Set up a Pihole to block ads, malicious sites and to log DNS requests. When the numbers spike you'll know where to block and who is causing the issue.

As explained in the pi-hole documentation (and video documentation) you configure your router to use the pi-hole machine as a DNS server. See this video circa 0:57 seconds: youtube.com/watch?v=vKWjx1AQYgs

Any Linux box will do, not necessarily a Raspberry Pi. I added block lists for Microsoft Telemetry and Spybot immunization list.

https://pi-hole.net


Benefit to specifying JSON Content-Type character set?

Your biggest risk would be older versions of Internet Explorer that attempt to auto-detect the encoding as UTF-7 - called Codepage Sniffing.

It appears that Internet Explorer will only do this for webpages, and not for AJAX requests. Therefore JSON requests should be safe. Moreover, JSON requests do not cause rendering of content directly to the page - they would need JavaScript processing in order to manipulate the DOM, so this would only be of concern when you were retrieving data that has supposedly been pre-HTML encoded. Therefore if the JSON data is HTML encoded on the client, the encoding of the page should take precedence and would not cause conversion of +ADw- character sequences to angle brackets, which is where the risk lies with UTF-7.

So I would say specifying charset=utf-8 is only necessary for Content-Type: text/html pages.


How to find out the email host of a vanity email address?

Check the MX DNS record associated with the domain name.

e.g (under Windows, for @stackexchange.com):

O:\>nslookup
Default Server:  **********
Address:  **********

> set type=mx
> stackexchange.com
Server:  **********
Address:  **********

Non-authoritative answer:
stackexchange.com       MX preference = 1, mail exchanger = aspmx.l.google.com
stackexchange.com       MX preference = 5, mail exchanger = alt1.aspmx.l.google.com
stackexchange.com       MX preference = 5, mail exchanger = alt2.aspmx.l.google.com
stackexchange.com       MX preference = 10, mail exchanger = aspmx2.googlemail.com
stackexchange.com       MX preference = 10, mail exchanger = aspmx3.googlemail.com

aspmx.l.google.com      internet address = 74.125.136.27
aspmx.l.google.com      AAAA IPv6 address = 2a00:1450:4013:c01::1a
alt1.aspmx.l.google.com internet address = 74.125.143.27
alt1.aspmx.l.google.com AAAA IPv6 address = 2a00:1450:4010:c03::1a
alt2.aspmx.l.google.com internet address = 74.125.25.27
alt2.aspmx.l.google.com AAAA IPv6 address = 2607:f8b0:400e:c03::1b
aspmx2.googlemail.com   internet address = 74.125.143.27
aspmx2.googlemail.com   AAAA IPv6 address = 2a00:1450:4010:c03::1b
aspmx3.googlemail.com   internet address = 74.125.25.27
aspmx3.googlemail.com   AAAA IPv6 address = 2607:f8b0:400e:c03::1b
>

-> Google


Does AV software protect web applications (Twitter, Facebook, etc) from attacks? (CSRF, etc)

The main problem with attack vectors like XSS and CSRF is that they are largely the responsibility of the web application that is being browsed to rather than the client browser itself.  Both are in the OWASP top 10 coding errors and suggested approaches are to fix the validation of user input on the website itself - so there's not a great deal you can do to protect from the client point of view.

However, having said there is a small subset of XSS that relies on malformed JavaScript will only operate on certain versions of browsers.  Keep the browser up to date solves that problem.


Is a vulnerable router less of an issue when placed "behind" a secure one?

TL;DR: It is a bad idea to place a vulnerable router on the network in the first place. But depending on the actual vulnerability and on the trust one has into other devices in the network it might be possible to at least reduce the impact of the vulnerability.
From my understanding you are proposing the following setup:
    Internet
       |          WAN A
    ----------
    |  A     |
    ----------
    |  |  |  |    LAN A, WiFi A
       |
       |          WAN B
    ----------
    |  B     |
    ----------
    |  |  |  |    LAN B, WiFi B

Assuming that both routers do NAT from LAN/WiFi to WAN the following observations can be made:

The devices in LAN A and WiFi A are accessible from LAN B and WiFi B, unless an explicit separation is done in router A (which is not even possible with many routers).
The WAN interface of A is accessible from the internet.
The devices in LAN A and WiFi A are not accessible from the internet, unless explicit port forwarding is setup in A.
Because of [3] the WAN interface of B is not accessible from the internet.
Similar to [3] the devices in LAN B and WiFi B can not be accessed from LAN A and WiFi A due to NAT in router B (assuming no port forwarding is setup).

It is assumed that a successful exploit means that the attacker compromises a router in a way that they have access to both WAN and LAN/WiFi side systems and maybe can also modify any traffic passing through the router. Based on this:

If the router can be exploited from the WAN side then it would be a bad idea to use it as internet facing A. This way
all devices in LAN A and WiFi A might be affected and additionally
the internet facing traffic from devices in LAN B and WiFi B could be
impacted. Placing such vulnerable router inside as B prevents attacks
from the internet but still allows attacks from inside LAN A and WiFi
A.
If the router can be exploited from the LAN side or WiFi (for example by using a CSRF attack run through a browser inside LAN B) then it would be a bad idea to place it as internal router B. This way not only the devices in LAN B and WiFi B are impacted but is would also be possible to attack the devices in LAN A and WiFi A. Making such router instead internet facing as A, would still allow attacks from LAN A and WiFi A but no direct attacks against LAN B and WiFi B. But internet facing traffic from B might still be affected by a compromised router A.


Export Nessus Professional vulnerability scan results listed by vulnerabilities

When creating your report there an option to group by plugins.


Shmishing scam that targets Gmail access

There's not really an answer to this question, because all we can do is speculate, but I'd hazard a guess that the link they clicked on coerced them into accepting an application to have access to their Google account with full privileges. You can go to https://myaccount.google.com/security and look at the section called "Apps with account access" to check for this.

The other option is that the link presented her with a fake login page and she provided credentials - plain old phishing.


Benefit of remote wipe when the drive is encrypted?

It protects the device from attacks on the login process. If I can log in, then your encryption is meaningless.


Why do I need both root password and user password in Fedora Linux?

The user password ought to be asked when doing an administrative operation (which more or else maps to a call to sudo or something similar). Out of a lot of reasons (including Tradition with a capital 'T'), you should never use the root account directly (except for emergencies); instead, you connect as a "normal user" who is registered (in the /etc/sudoers file or equivalent) as "capable of doing administrative tasks provided he enters his password".

Asking the user password explicitly for administrative operations avoids or at least reduces the nuisance implied by some cases of "lunch-time attacks": when someone forgets to lock his system, and a facetious coworker decides to abuse the situation.


Is there a secure way to disable NFC and RFID on credit cards and personal IDs?

Yes. Your issuer can disable transactions that are generated by NFC card. For NFC card, the Integrated Circuit Card (ICC) contains an additional secret key which generates cryptogram (Message Authentication Code) over the transaction data. If you ask your issuer to disable NFC transaction, it invalidates this secret key so cryptogram is no longer authorised.

They don't delete this key so that you can request to enable it again. Contactless payment can be still be processed by the terminal but the issuer responds with decline message. Source: My friend did it by contacting his bank and we tested it later. Transaction results in decline.

Regarding personal IDs, it depends on the usecase. For example, my workplace uses NFC smart card to enter into the workroom. To enter into the building, the only way possible is to let the terminal scan my ID card. The ICC is embedded which does actual authentication for NFC. If your organisation supports both physical (as a fallback mechanism) and contactless then yes they can invalidate authentication done by NFC. The only reason why would they do that is if they want to prevent NFC relay attacks on employees who have access to confidential area but want to maintain both mechanisms for the others.

Note that, the issuer can only invalidate transaction generated by NFC card. It cannot disable the NFC chip itself. Unless you tamper with NFC or shield it, NFC card can be used as normal. A fraudulent NFC reader can still read your passive card data.

You cannot disable NFC of ePassport as it is intended to be used that way by the authorities.

If you want your card or IDs not to be read, you need what some people call Faraday cage which they are not. Faraday cage is grounded. The foil that shields the card from NFC reader only reduces the strength of the signal and does not block it. High power crafted NFC readers can still read your card from distance. What you really need is a reflector that bounces back the signal as noise or a jammer which creates its own field to jam the signal.


Track lost Android phone, if the thief is using it to access internet

Is the thief using your SIM card? If so, then you know the number and can inform your mobile service provider / local law enforcement, who will be able to track the phone based on cell tower proximity provided it is switched on.

If you want to track the phone based on IP, then you need access to the server logs for the chat services your phone is automatically logging into. From there you will be able to get an IP Address for your user account, which can be used (again via the mobile service provider) to identify the device and track its location.

Both approaches involve law enforcement. So the bottom line is: call the police.


https://www.theguardian.com/technology/2016/oct/21/dirty-cow-linux-vulnerability-found-after-nine-years (near the end of the article) seems to say its a YES.


Kismac is no longer developed. Besides, macs generally do not have the wireless chipset that is capable of injecting packets.

A more effective solution would be to create a linux VM (running under Fusion or your chosen VM software), investigate which chipsets are capable of injection, buy one, install the aircrack-ng suite and go from there.


Ciphertext can be output in binary format.  For example, gpg defaults to binary format, and you need to specify --armor to make it base64:

--armor
-a
    Create ASCII armored output. The default is to create the binary OpenPGP format.

The reason you see ASCII/base64 more often is that it is easier to transfer and manipulate than binary.  SMTP email, for example, cannot handle binary data without encoding it, so having a non-binary format makes it simpler to email encrypted text.  FTP may default to non-binary mode which will introduce errors when transferring a binary file.  Even something as simple as popping open a file in an editor to make sure it "looks like it's there" is easier with non-binary formats.


What is the difference between ATA Secure Erase and Security Erase? How can I ensure they worked?

As quoted from this page:

Secure erase overwrites all user data areas with binary zeroes. Enhanced secure erase writes predetermined data patterns (set by the manufacturer) to all user data areas, including sectors that are no longer in use due to reallocation.

This sentence makes sense only for spinning disks, and without encryption. On such a disk, at any time, there is a logical view of the disk as a huge sequence of numbered sectors; the "secure erase" is about overwriting all these sectors (and only these sectors) once, with zeros. The "enhanced secure erase" tries harder:

It overwrites data several times with distinct bit patterns, to be sure that the data is thoroughly destroyed (whether this is really needed is subject to debate, but there is a lot of tradition at work here).

It also overwrites sectors which are no longer used because they triggered an I/O error at some point, and were remapped (i.e. one of the spare sectors is used by the disk firmware when the computer reads or writes it).

This is the intent. From the ATA specification point of view, there are two commands, and there is no real way to know how the erasure is implemented, or even whether it is actually implemented. Disks in the wild have been known to take some liberties with the specification at times (e.g. with data caching).
Another method for secure erasure, which is quite more efficient, is encryption:

When it is first powered on, the disk generates a random symmetric key K and keeps it in some reboot-resistant storage space (say, some EEPROM).
Every data read or write will be encrypted symmetrically, using K as key.
To implement a "secure erase", the disk just needs to forget K by generating a new one, and overwriting the previous one.

This strategy is applicable to both spinning disks and SSD. In fact, when an SSD implements "secure erase", it MUST use the encryption mechanism, because the "overwrite with zeros" makes a lot less sense, given the behaviour of Flash cells and the heavy remapping / error correcting code layers used in SSDs.
When a disk uses encryption, it will make no distinction between "secure erase" and "enhanced secure erase"; it may implement both commands (at the ATA protocol level), but they will yield the same results. Note that, similarly, if a spinning disk claims to implement both modes as well, it may very well map both commands to the same action (hopefully, the "enhanced" one).
As described in this page, the hdparm -I /dev/sdX command will report something like this:
Security:
       Master password revision code = 65534
               supported
               enabled
       not     locked
       not     frozen
       not     expired: security count
               supported: enhanced erase
       Security level high
       2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

2 minutes are not enough to overwrite the whole disk, so if that disk implements some actual "secure erase", it must be with the encryption mechanism. On the other hand, if hdparm reports this:
       168min for SECURITY ERASE UNIT. 168min for ENHANCED SECURITY ERASE UNIT.

then we can conclude that:

This disk performs a full data overwrite (that's the only reason why it would take almost three hours).
The "secure erase" and "enhanced secure erase" for that disk are probably identical.

Depending on the disk size and normal performance for bulk I/O (can be measured with hdparm -tT /dev/sdX, one may even infer how many times the data is purportedly overwritten. For instance, if the disk above has size 1 terabyte and offers 100 MB/s write bandwidth, then 168 minutes are enough for a single overwrite, not the three or more passes that "enhanced secure erase" is supposed to entail.
(There is no difference between Linux distributions in that area; they all use the same hdparm utility.)

One must note that the encryption-based secure erase really wipes the data only to the extent of the quality of the encryption and key generation. Disk encryption is not an easy task, since it must be secure and yet support random access. If the firmware simply implements ECB, then identical blocks of plaintext will leak, as is usually illustrated by the penguin picture. Moreover, the key generation may be botched; it is possible that the underlying PRNG is quite weak, and the key would be amenable to exhaustive search.
These "details" are very important for security, and you cannot test for them. Therefore, if you want to be sure about the wiping out of the data, there are only two ways:

The disk manufacturer gives you enough details about what the disk implements, and guarantees the wiping (preferably contractually).

You resort to good old physical destruction. Bring out the heavy duty shredders, the hot furnace and the cauldron of acid!


Why do Certificate Authorites cross-sign each other?

Certificate Authorities cross-sign each other when they get married together.

When CA Y issues a certificate for CA Z, then any system who trusts Y will indirectly gain confidence in everything that Z issues, since, for any certificate X issued (signed) by Z, a system that trusts Y will build the chain Y→Z→X. Thus, this cross-certification represents an assertion from Y that basically says: "everything that Z signs is as good as if I, Y, had signed it myself".

If CA Z also issues a certificate for CA Y, then trust goes both ways. Every system that trusts either Y or Z will be able to validate certificates emitted by both. The two CA are now really one, at least as far as trust is concerned.

A divorce would require revoking both cross-certificates, or at least failing to issue new ones when the cross-certificates expire.

(In practice, this kind of things happens when a new CA is created but is "morally" a replacement for the old one; or when a merger occurs between two businesses and they try to fuse their internal computer systems together.)


Since the question is very long.. the answer will be short: do what you like and enjoy it. It doesn't really matter what path you take, as long as it makes you more knowledgeable each step.


What are some considerations before moving personal data to Google Drive?

Google has access (obviously).
The police will have access if they have a valid search warrant.
A national security letter will give the FBI secret access.
Various three-letter agencies may have access, depending on how they're doing at circumventing Google's encryption.  (Google started encrypting its internal traffic after it was revealed that the NSA was monitoring it.  Modern encryption, properly applied, is believe to be sufficient protection against three-letter agencies -- all known attacks are against the "properly applied" part rather than the encryption itself.)

As for deletion, Google uses a highly distributed storage system.  I don't believe they will intentionally keep data after you delete it, but because of how Google's storage works, residual copies may stick around for a while.


Locking Linux system to work on certain hardware only

The short answer is "No, there's no way to lock software to a specific piece of hardware that cannot be broken.".  You're essentially talking about implementing some form of DRM, and tying your software to a specific HW.  The brute force approach is simply to go into your code and modify it to stop looking for the HW check.  This is one approach that software crackers have taken for decades to defeat copy protection.  Many have tried to block crackers.  All have eventually failed.

The long answer is you might be able to stop some set people from using your software for some length of time on unapproved hardware.  Security doesn't have to be perfect to be useful.  A set of handcuffs can be picked with a paperclip, but they still have some marginal use.

After reading your edited response, the threat model sounds like it's professional reverse engineers who want to clone your product.  That essentially means you're doomed from a stopping reverse engineering perspective.

I'm not familiar with the example you have of the ELM327, but the wikipedia entry leads me to believe it's look a chip from 1976, so it's no longer protected by patent, and isn't copyright-able.  You can't protect your invention from being cloned after the IP rights have run out.  Someone invented the pencil with an eraser on it and had the rights to sell it exclusively for many years, but anyone can produce a pencil with an eraser on it now because the IP ran out a long, long time ago.

I'd say by far your best weapon against commercial cloning is intellectual property laws.  File patents,and make sure your software has the appropriate copyrights applied to it in the various districts.  Contact a good IP lawyer.  It'll only really become an issue if your product is successful, so you'll have money to pay lawyers to fight any IP infringement.


How do backup codes work in TOTP, like Google Authenticator?

On Google Auth and any other service using TOTP provides you the time-based tokens, but they understand the possibility of losing the device or not being able to access the codes.

Eg. Your phone got stolen or heavily damaged.

So when you add a service like this they provide you Another login mechanism apart from TOTP, those are the backup codes, they are not part from TOTP but remediation method if you lose access to them.


ISO 27001 compliance for application or hosting?

ISO 27001 is about how security is managed, not how secure a product is. It would, therefore, be very difficult to define a particular app as the scope for certification if the infrastructure is also under the company's control.
You manage the security of the infrastructure and then develop on top of that secure foundation. That's the intention of the certification.
If your scope of control is only the development of the app, then you still certify the development company, not the app.
That isn't to say that you couldn't convince some assessor somewhere to do certify you with just the app as the scope. I'm sure you could. But any potential partner/customer/stakeholder looking at the certification's scope will not take the certification seriously and start to doubt your competence more than if you had no certification to begin with.


Perhaps - proving that the developer uploaded a "dropper" would be difficult.  Considering that credentials were provided to the developer, it's possible that the credentials were passed-on or otherwise compromised (the developer's system could have already been compromised).  Regardless, unless you wish to initiate legal action, focusing on the point that your site is compromised and working to clean it is more efficient.
The "malware" can be harmful.  The difference in term is that the dropper app that Avast detected is a way to gain access to your system.  If the malware successfully compromised your system, then it's possible that an attacker have installed a backdoor.  With that said, it looks like Avast detected the dropper so it's possible that the infection attempt was blocked.

You could always try running other malware detectors to see if your system has been compromised.  Otherwise, if you know a good security practitioner, you could always have them take a look.  I'd recommend against going to big-box computer stores - the workers there often have little knowledge or experience in this area (you get what you pay for).

Alternatively, if compromise is a concern, then reimaging the system and reinstalling software only from verified sources (i.e. media, vendor's web sites, etc) will reduce the likelihood that you become re-infected.  Reinfections are common when people backup the binaries and re-install those on a clean system.  Again, this measure is if you are certain that your system is compromised and you want greater assurance that your system is clean.

FYI, if you're interested in learning more about the dropper, look here for other names assigned to this app by other AV/malware vendors.

YES!  You should change your password immediately and while you're at it, make sure that no other apps have been authorized access, password recovery features aren't modified, etc.  Any other sites that use the same password should also be a point of concern - change those password as well (i.e. banking, VPN, etc) - preferably to something that's different.  Password managers (i.e. Lastpass, KeePass, etc) helps manage using multiple passwords for each account.

Good luck


What are the risks of using a CDN to speed up my website? How do I avoid them?

Security risks:

Any risks that would be present on your own site.
Any risks relevant to a 3rd party site for the data you have given them.
Information may persist longer than expected.

Anything private or related to a single session shouldn't be served via a CDN -- not that I've ever heard of that happening. Anything static and non-private should be fine, including code, jscript, json data, etc.
Yes, you might run into issues serving scripts from a CDN. You should determine what issues you face via testing. However, javascript typically operates on almost anything that is part of the browser window regardless of the source domain (hence so many attack vectors and facebook ads).
No particularly special concerns about HTTPS. The CDN should have its own certificate and provide SSL service.
CDNs can determine pages visited on your site. They can determine more if you point to them using the same domain as your website (cookie overlap). That's why you often see domains like 'example-static.com' instead of 'static.example.com' -- it keeps *.example.com cookies private.


The email is usually a good thing as a username because:

the user remembers it;
it is unique worldwide, thus simplifying the management of collisions (if one user wants to use the same login name as another, then one of them did a mistake);
it can be coupled with an "email verification" system which is convenient if you want the server to be able to contact users in case of emergency.

Nominally, at least the right half of the email address (the domain name, after the "@" sign) is case-insensitive, so you should normalize that part to lowercase, which is easy, since it is supposed to be a valid domain name, hence limited to a subset of ASCII (Note: you will want to take care to use what .NET calls the invariant culture, and Java terms the root locale; otherwise, your code will break in Turkey).

For what is on the left, case sensitivity depends on the receiving site. Most sites are case insensitive for that part too, and it seems "reasonable" to do lowercase normalization, because it is improbable that a given site is both case sensitive and uses case to distinguish between distinct people (i.e. that bob@example.com and BOB@example.com are both valid addresses for two different Bobs). Thus, I suggest lowercase normalization of the whole address for comparison purposes (i.e. to decide which user we are talking about); but keep the address "as is" if you ever want to send back an email to the user, or even if you want to show it to the user (e.g. as a "Welcome, Bob@example.com" banner -- Bob might be quite fond of his uppercase 'B').

About the "+" sign: From your point of view, that's part of the address. This "+" is handled on some sites as a way for each user to generate a lot of functionally equivalent addresses: Bob will be able to use bob+work@example.com, bob+home@example.com, bob+the-ultimate-warlord@example.com... all emails sent to any of these addresses end in Bob's mailbox, but, in the eye of Bob, they still are distinct addresses which Bob types as such. Bob expects the addresses to be considered distinct. So your handling of the "+" depends on what you really want:

If you just want a unique "login name" so that management of collisions is easy, then leave the address "as is"; don't do anything special with the "+".
If you want to enforce uniqueness of accounts per human user (i.e. you don't want Bob to be able to create one million distinct accounts), you may want to remove characters from the "+" sign to the "@" sign, there again for comparison purposes. But don't believe this rule will deter most Bobs; obtaining zillions of email addresses without a "+" is easy and cheap (the ultimate way being to buy a domain and rent a server to host it).

Summary: keep the address as entered at registration time and use it "as is" for display and for sending emails. For comparisons (i.e. locating the user entry in the table of users, e.g. upon login), normalize the email to lowercase (with an invariant culture).


Are you looking to monitor packets between your computer as a client on the network and the router and other wireless clients and the router? If you're using windows, it looks like the answer is yes: you'll need to purchase Airpcap.

http://ask.wireshark.org/questions/8504/supported-adapters-for-wireless-packet-capturing

If you're attempting to monitor at some other point, you might clarify?  Are you capturing on the router?  On the WAN port of the router?  Or are you collecting as a client on the network and expecting to see activity of wired clients in your capture?


Until what point can I rely on HTTPS for client-server communications?

Is the choice of the CA to register my domain an important one?

Yes.  There have been physical on-premise breaches that have exposed signing certificates from some CAs (RSA).  There are CAs that have issued bogus certs for legitimate companies (THAWTE/Symantec, China).  There are CAs that have been banned for chronically/"mistakenly" issued bogus certs that have ended up used in malware or used to provide for illegal SSL interception of legitimate sites.  (China's Wosign and CNNIC)

Are there some CAs that are considered as more safe or less safe?

In my opinion, yes.  According to people who build and maintain certificate untrusted lists, yes.  Google actually maintains a list and API of untrusted certs via  project called Submariner.

Are there some CAs that are blacklisted or forbidden access in some
regions of the world? (This would make my clients from those regions
unable to access my platform through HTTPS.)

Yes, but the matrix of what country trusts what CA doesn't exist.  And even worse, unless you're living in a country who controls your Internet access, the problem becomes more nebulous with trying to determine what companies trusts what CAs...

Is it possible for ISPs to monitor the requests made from client for
certificates, and sometime issue fake certificates?

It is possible for people inline to your connection to perform an SSL/TLS Man-in-the-middle attack (commonly dubbed, SSL Interception) but if, as the user initiating the connection, you're checking your certificates when your browser complains about a problem, you should see it (e.g. go to https://www.google.com and the cert your browser sees is for some-other-registrant).

If you are still using SSL and some early versions of TLS, there are known attacks for them as well.

If you are still using old certificates that are using antequated hashing or encryption algorithms, there are attacks against them as well (e.g. DES, 3DES, MD4/5).


What makes a SQL Injection count as blind injection?

Most of what you say is correct.

The UNION statement in regard to SQL injection is just another way to attempt to break/change/extract data. It can be blind, partially blind, or not blind at all, this depends on the server, code, and error reporting.

If the injection doesn't output any data, but does effect the behavior of the site in a way that you can interpret as having done something different than normal, it is considered partially blind.

If the injection doesn't output any data, and there is no change in behavior of the site at all, this is considered totally blind.

Using UNION may or may not change the outcome, but isn't inherently linked to being blind or not.


What is the risk of a packet being sniffed when travelling over the internet without SSL/TLS?

It depends on your threat model.  If you're worried about big organizations who really really want to see your data, they're probably going to see it.  The hardware and software to do this is generally available to ISPs since they're required by law to provide for "Lawful Intercept" in many jursidictions: http://en.wikipedia.org/wiki/Lawful_interception  And unfortunately, the implementations by the router companies are pretty bad, as Forbes notes, so hackers may get access also.

Then there are all the other possible attacks, like DNS cache poisoning, phishing or routing (BGP) attacks, on connections that don't have the good endpoint authentication that SSL provides.  See e.g. how the Dalai Lama's organization was hacked.  Even security gurus figured they would be vulnerable to that kind of attack.

If no one (including insiders at your ISP or near your destinations) cares about you, you'll probably not be snooped on unless your local network is a convenient and easy target, like most wireless networks are.  But if sufficiently savvy and persistent folks (even individuals) do care, beware.


Does a rewritten file on NTFS use the same blocks?

In general, block allocation is the most expensive operation in filesystems, so filesystems will try quite hard to avoid it, in particular by reusing blocks when possible. This would mean the following:

When overwriting an existing file, the same blocks are reused. New blocks are allocated when the new file data exceeds that of the overwritten files.
When truncating an existing file, all the blocks are released, thus potentially reusable for other file operations. In that case, the new file may allocate new blocks. There is no guarantee that the new file contents will reallocate the same blocks, and, in particular, the old blocks might have been reallocated to other files in the mean time.

However, it depends a lot on the filesystem internals. Log-structured filesystems perform all writes sequentially, throughout the whole partition, so it is pretty much guaranteed, with such a filesystem, that the new file will not overwrite the blocks from the old file. Journaling filesystems may copy the file contents to an extra structure (the "journal") in addition to the actual permanent storage (depending on whether the journaling extends to the file contents, or just the metadata). Some filesystems also use a "phase tree" which can be viewed as a log-structured filesystem, with a tree instead of a list; for these, overwrites may or may not happen.

An important point to consider is that block allocation strategies do not depend only on the filesystem, but also on the implementation. There is no guarantee that Windows XP and Windows 7, for instance, behave similarly on the same NTFS filesystem. One OS version may find it worthwhile to keep around old blocks to "speed up (re)allocation" while another could employ another strategy. This is all heuristics, tuned and retuned. Thus, one cannot really answer your question about "NTFS"; one would have to talk about "NTFS as implemented in OS foobar, version 42.17, build 3891".

Moreover, all these blocks are what the OS sees; actually physical storage may differ, and move/copy data around. This is typical of wear-levelling algorithms in SSD. Generally speaking, overwriting/shredding files on SSD is not reliable (see this answer for details and pointers). But some data movement can also happen with magnetic disks (in particular when a flaky sector is detected; remapping is done on the fly, and the old sector remains untouched, forever).

This basically means that file shredding does not work well in that it cannot guarantee that the data will be destroyed. You should use file shredding only as an emergency measure when other methods have failed or were erroneously not applied. The correct ways to permanently destroy a file are:

Wholesale destruction of the complete disk, e.g. by dissolving it in acid.
Encryption: when the data is encrypted, destroying the key is enough to make the data unrecoverable. While this does not completely solves the issue (you still have to destroy a data element), it makes it much easier (a key is small: it is much easier to destroy 128 bits than to destroy 128 gigabytes).

Secure erasing, when implemented properly by the disk, works with the encryption trick.


The flaw with iMessage reference aboved was that it was:

A) Vulnerable to a brute force attack
    This was because of a bug discovered by the researchers that allowed a man-in-the-middle-attack to be setup, due to:

Strict certificate pinning was not used until iOS 9 -- so an attacker could create an impostor certificate and hack DNS on their local network to be able to start intercepting data and begin the attack.
No MAC is used in the encrypted payload after receiving an ECDSA signature -- thus, the contents of the message/message integrity is not controlled for.
The signature can then be tampered with or replaced with another signature.  See image provided by researchers:
The "error oracle" compression attack you describe allows one to painstakingly decrypt a message bit-by-bit by taking advantage of how CRC checksums are computed over the original data, but not the AES encrypted payload iMessage then creates.

B) Using a static 64-digit symmetric encryption key for message encryption.

Rather than use a symmetric key system, an asymmetric system or one utilizing perfect forward secrecy may have been able to prevent this.  Once the man in the middle attack was setup, a brute force attack could be launched until, successfully, retrieving the 64-digit key.

How?

Beyond the immediate technical answer, the question as to how this happened is the same for this case as it is for most other commercial, closed-source products; and even many open source packages -- encryption and creating bulletproof cryptosystems is hard.  Even given the most valuable company in the world, Apple, with the best engineers and seemingly unlimited resources; mistakes can be and are made.

For more information, I suggest looking at Bruce Schneier's article on the subject, and the researcher's blog post on the subject.


Does Wazuh have capabilities for handle virus/malware/rootkit ? If yes, How?

Wazuh engineer here.

I wonder how Virus are being detected in the first place. If you have some kind of AntiVirus solution, then you can do an integration and have Wazuh process AV alerts (triggering active response to remove malicious files or stop malicious processes).

Having said that, Wazuh can also detect malware looking for IOCs (rootchecks), detecting anomalies (hidden files or processes), and monitoring the file system (syscheck).

Something that works really well to detect malware is the integration with VirusTotal. This way, when a binary file is changed or created, Wazuh will check against VirusTotal and learn if it is detected by AV engines. If so, you can trigger an active response to eliminate it.

In addition Wazuh has done integrations with AVs like ClamAV or Karspersky to do that exact same thing.


Restrict user from executing shell commands using PHP

Disable exec and suexec, enable open_basedir and basically follow every suggestion in this post.

You mentioned still there are other ways to... if after reading that post you still have questions or weaknesses, please post them here or in Serverfault


It depends on the implementation and on the security requirements. There are solutions which have no back-channel at all in which case you can never be 100% sure that the data are received at the other end. One can try to compensate this by sending the data often enough or with enough error correction but at the end it will not be noticed if the receiver system is simply broken - because there is explicitly no way to get acknowledgments.

And then there are solutions which try to find a different compromise between usability and security by providing a minimum back-channel. One product I know deeper consists of three parts: a micro-kernel in the middle and firewalls on both sides of the micro-kernel. The one-way functionality  is implemented using a micro kernel task which uses only minimal code and can thus be better checked for correctness of functionality and robustness. And on both sides of this micro-kernel are the more complex firewalls where applications translate TCP, UDP, FTP or SMTP traffic into the custom one-way protocol transferred by the micro-kernel and back. The minimal back-channel provided by this protocol can signal only success or failure which is just enough to provide early feedback for example in case the receiver crashed and cannot receive more data or even if the FTP transfer failed because the password was wrong.  TCP flow control and similar features are implemented by the applications on the firewall and do not travel the micro-kernel.

  It seems that firewalls and proxy servers would pretty much do the same thing?

Not really true and not really wrong. The larger the code base is which implements the essential one-way functionality the harder it gets to be sure that there is really only the one-way to communicate. The nice thing about data diodes based on a physical one-way property (like light emitter and receiver) is that they are obviously one-way and can only be bypassed if the attacker has physical access to the system. But the more you move the one-way property away from the obviousness the harder it is to be sure that it is really only one-way.

For example: with physical one-way one could obviously compromise both sides of the  diode and still be sure that the one-way property is kept. With the micro-kernel based solutions I've outlined the firewalls on both sides could be compromised too without loosing the one-way property. But it will get bad if the micro-kernel would be compromised. But that's considered impossible without physical access in this solution because the micro-kernel is just what it says: minimal code base, interaction with the outside only through the one-way task and this minimal task is hopefully secure against exploits. With a proxy solution on a single firewall appliance it would be instead enough to compromise this firewall in order to work around the one-way property. Given that firewalls are complex this can be considered more likely than exploiting a micro-kernel or even a physical separation.

Thus: you could achieve one-way functionality using a simple proxy solution but it is hard to prove that it only does one-way in all cases, even if attacked. And the market where data diodes are used has usually high security requirements and often requires that you not only claim that your solution is secure and resistant against attacks but also that you can prove it more or less (i.e. certificates, independent evaluations...). And obvious robustness  by design really helps in this case.


Can my IT admin see websites I hit via VPN

It really depends on what you really mean. Can they see what is in the packets? Probably not. Can they see that the traffic is encrypted and you are using a VPN? More than likely. Can they see your browser history? I would say it is safe to assume they would be able to. So in short, yes but not at the network level.


How to configure .NET's PBKDF2 implementation (Rfc2898DeriveBytes) in 2019?

Salt length

As mentioned at some point in this answer

  16 bytes are enough so that you will never see a salt collision in your life, which is overkill but simple enough.

Pepper

According to a comment under this answer, you should indeed use it:

  You make a pepper look as something only useful with a HSM, which it is not. Its purpose is to have different salts on different places, thus forcing the attacker to compromise all of them. Typically, the salt is stored with the username in the db but the pepper is stored in the login server. Thus making some leaks resistant to offline guessing: A broken RAID disk from the database server is leaked, but the pepper was stored in the web server; or the db was obtained through a SQL injection but the configuration file is not.

However, according to this question, the server side key should not be a "pepper" (= added to the cleartext password and then hashed):

  There is a better way to add a server side key, than using it as a pepper. With a pepper an attacker must gain additional privileges on the server to get the key. The same advantage we get by calculating the hash first, and afterwards encrypting the hash with the server side key (two way encryption). This gives us the option to exchange the key whenever this is necessary.

Instead, the result of the hashing process should be encypted with a secret key which is kept out of the database (for example, it can be kept in the code). By using (two-way) encryption for this, it can be re-encrypted in case the key has been leaked. Example code for doing this  can be found in this answer(using 2 distinct keys instead of one in this case).

Iteration count

This needs to be tested on the actual hardware. More iterations make it take longer for an attacker, but also for your users. An often stated goal is to make it take around a second to log in.

Algorithm choice, Hash length

According to this answer:

  Choosing a derived key length that is less than the output length of the hash function makes little sense, [...] I'd suggest SHA-512 as the PRF, with a 512-bit derived key

So SHA-512 as algorithm, and in C# we would use .GetBytes(64) on our instance of Rfc2898DeriveBytes in order to get a 512-bit derived key.

How to combine the parts for the DB

There are several ways to do this. I would advise the following pattern:

{hasherVersion}${encryptionVersion}${payload}

hasherVersion is a number for the "version" of the hasher. Every time you change your way of hashing - be it increasing iterations or switching the algorithm entirely - you increment this number. This way, you can see if it was stored with an older version and can update it accordingly (e.g. when a user logs in).

encryptionVersion is pretty much the same, but for the encryption. Additionally, this allows you to update encryption in the database in parts.

payload is the actual encoded password. In order to create the payload, the steps are:

Create the random salt
Using the salt, create a hash from the password
Concatenate salt and hash into a single byte[80]
Encrypt that byte[], using the server-side secret
Convert the resulting (encrypted) byte[] to Base64

The size of the DB field(s) needed

120 characters should be enough for a long, long time:

108 characters for the Base64-encoded salt+hash
2 characters for the 2 delimiters
5 characters each for hasherVersion and encryptionVersion

The first 2 are hard numbers. For the versions, well, probably 3 each is already enough (if you need to change those more than 999 times, you should probably try something else), but 5 each gives us a nice round end result of 120 characters.


According to the linked forum thread, the target sharee is required to create an account before the password is "shared"...

The thread participants claim that no unencrypted shared password is stored on LP servers.  Once the target sharee creates an account and supplies a public key, the target password would be encrypted with the target user's public key on your client side and uploaded to the LP database.

Thread Ref:

by jonat » Wed May 25, 2011 4:46 pm

If you read the user manual about sharing, it sends the recipient an
email inviting them to open a LP account if they don't have one. As
Israel says, nothing is actually shared until the account exists and
the sharing accepted, by which time the keys are in place.


How can an NGO ensure secure mobile communication between HQ and their delegates in the field?

and don't have the possibility to provide a VPN connection

What has size (or budget) got to do with it? Both Android and iPhones (and many more mobile devices including Laptops running MSWindows, Linux of MacOS) provide PPTP, L2TP and IPSEC out of the box. They will also happily connect to HTTPS services.

The "server" end only needs an accessible IP address, a physical device and some software. And you must already have the first 2 if you are providing services such as email.

However if good rather than basic security is required then you should be looking at delivering a remote desktop type service - just delivering the display to the device - since you can't assure the physical security of the device, you cannot trust its integrity.

Trying to lock down the device, remotely manage it and maintain an encrypted filesystem is a common approach for enterprises (and required if you are going to maintain sensitive data on the device) but this is where the costs escalate even faster than the attack surface. A further issue is that this a BYOD model - why should you have control over a device not owned by you.

IMHO providing secure access to a centrally hosted user interface is more secure and cheaper. It also solves the ownership issue of BYOD.


Complex Consumer Matching Queries with PGP Universal

Examine the following filter:

(&(member=cn=PGPUsers,ou=Groups,dc=site,dc=com)(|(memberOf cn=Dept1,ou=Groups,dc=site,dc=com)(memberOf cn=Dept2,ou=Groups,dc=site,dc=com))

see also

LDAP: Search filters


Does WebDAV pose an unreasonable risk in IIS7.5?

WebDAV is more of a configuration nightmare than anything.  If it's misconfigured it can lead to a whole host of vulnerabilities like being able to access application files, directory traversal, bypassing authentication, etc.

If you aren't using it, the default settings are apparently reasonably safe, based on the IIS security model.  If you ARE using it, that poses a different problem as you need to create a proper threat model around it.

As you said, turn it off if you aren't using it.  WebDAV is reasonably safe at the moment, but that doesn't protect you from future 0-days.


How can one gain additional privileges from being able to read kernel memory?

You can do keylogging and learn people's passwords, SSH passphrases, etc.
You may be able to access filesystem buffers or process memory and learn SSH private keys, SSL private keys, etc.
You can access the internal pool for /dev/random and /dev/urandom, which may allow you to break crypto used by programs on the system.
You can access any crypto keys stored and used internally by the kernel.
You can defeat ASLR, which might make exploiting other vulnerabilities easier.

There may well be many more.


How to brute force a login page of an IP camera created in .asp?

"All the examples I have looked shows only how to do a brute force for the extension .php?. The login page of the IP camera I am testing however is in .asp"

extension of .php vs .asp should not matter.

  I do not see any <form> in the source code of the login.asp page.

how did you come up with the URL /PSIA/Custom/SelfExt.... etc?

  hydra -l admin -P wordlist.txt 192.168.1.3 -s 85 http-form-get
  '/PSIA/Custom/SelfExt/userCheck:lausername=^USER^&lapassword=^PASS^:User
  name or password is incorrect:H=Authorization: Basic
  YWRtaW46QkM1MUZFOTUyRkI3' -V

You appear to be using a mix of Forms based authentication and Basic Authentication with this command.  Also, you have expectations for two variables to be filled in with ^USER^ and ^PASS^ and are only supplying one variable as the file wordlist.txt just has one field.  How did you determine that this login is using Basic AUTH?  Does the basic auth pop up when you try to log in from login.asp?


Is browsing from a guest VM using an open Hotel WiFi secure?

If as you say, you're not worried about someone seeing what websites you visit / passwords you entered, open (without passwords) Hotel WiFi is not a significant factor at all.

In that case, YES. For your main concern, your technique of using disposable VMs for browsing is fairly good security if you are like most people.

It is not enough only if you are targeted by highly resourceful people (like Govt agencies). In that case you should expect that they'll use exploits that escape the guest VM and reach the host VM.


If you transfer the hash from the client, this affords no security benefit, and makes the hash pointless:
If a user can login by sending the hash to the server, then the hash is effectively the password.


Credit card data sent as a plain image format

Regardless of the format it is in, storing full PAN data increases security risk and, consequently, it’s scope of PCI compliance.

You would need to make sure that at every step, these compliance requirements are met:

One-way hashes based on strong cryptography
Truncation
Strong cryptography
Index tokens and pads

If you storing PAN data as indicated, then PCI DSS Requirement 3.4 requires that you render it unreadable and unrecoverable through one of those methods.

If you implement one of those methods, you are fine.

If not you have to implement one of those on that scanned image. Encryption of an image as a ZIP would be one option. Key management is always an issue with encryption, but if properly architected, it is feasible.


How many passwords is good for security?

No, it is not enough. Using the same password for both your email and your bank is a bad idea. If your email provider is compromised, that means the attacker will get access to your bank account, and vice versa. You don't want that.

Use one hard password per site. You won't be able to memorise all those, but don't worry. That's what password managers are for.

If you want this explained in a video featuring an animated octupus, the Electronic Frontier Foundation got you covered.


Format of finshed message when the cipher selected is "TLS_ECDH_ECDSA_WITH_NULL_SHA"

The format of an encrypted record in TLS can depend on the protocol version and (part of) the ciphersuite selected.

Even a null-encryption suite (which only exists through 1.2) still does MAC for message integrity (aka data authentication); for your example this is HMAC-SHA1. See rfc5246 6.2.3.1 (this one is the same in earlier versions); the record consists of: record header 5 bytes specifying handshake, 'content', and MAC (for HMAC-SHA1 20 bytes), where 'content' consists of handshake header 4 bytes specifying finished and verify_data 12 bytes.

The same format is used for stream cipher, except that the content and MAC are (together) encrypted by the configured cipher. However the only stream cipher in TLS was RC4, which is prohibited by rfc 7465 since 2015, so you shouldn't see this format in use. (Some implementations still can support RC4, so you might be able to use it in a test environment.)

For block ciphers using CBC mode in TLS 1.2 and 1.1, see rfc5246 6.2.3.2; the record format is record header followed by an IV and then encryption of the contents (as above) plus HMAC plus padding.
In TLS 1.0 (and SSL3) this is different, see rfc2246 6.2.3.2; instead of the IV being chosen and sent with the message, the initial IV (for the first message) is created in the key derivation, and subsequent messages are chained: the last ciphertext block of one message is used as the IV for the next message. Since the prior message can be seen on the wire, this allows a chosen-plaintext attack originally identified by Rogaway in 2002 and popularized by the 'BEAST' attack in 2011, about which this and related Stacks have numerous Qs. Note the order used in standard TLS, MAC-then-encrypt, is less secure with CBC because it allows a padding oracle, which was very severe in SSL3 (POODLE) and is less so in TLS1.0-1.2 (Lucky13). There is a recent option for 1.2 to use Encrypt-then-MAC, see rfc7366 -- but the easier and more common solution in 1.2 (and the only one in 1.3) is to use AEAD instead.

For AEAD ciphers, new in 1.2, see rfc5246 sec 6.2.3.3; this has the record header, 'explicit' part of the nonce (which in turn depends on the ciphersuite), and the authenticated encryption of content. All currently defined authenticated encryption schemes consist of encrypting content with a stream cipher (AES-CTR or ChaCha20) and appending a MAC (GMAC, CMAC, or Poly1305).

TLS 1.3 changes things. It no longer has ciphersuites of the form you reference; instead the ciphersuite specifies only the data cipher, which is always an AEAD cipher, and the hash used in key-derivation (what earlier versions called PRF); the key-exchange and entity authentication methods are selected separately. Thus 1.3 never has Finished (or anything else after CCS) in a null-encrypted record, nor a stream cipher, nor a CBC cipher. See rfc8446 5.2; now we have record header 5 bytes always specifying 'application data' (23) even for an actual handshake record, followed by the authenticated encryption (as above) of content, the real aka 'inner' record type, and optional/variable padding. In 1.3 the nonce for the AEAD cipher is (always) the record sequence number masked by a value from the key derivation, and is not sent; this is described in 5.3. Also for Finished in particular, in 1.3 verify_data is now a single HMAC (instead of the PRF in 1.0-1.2) of a very similar transcript hash, but is no longer truncated to 12 bytes and now varies with the derivation hash.