How could an attacker read the content of php session variables?

No. Generally, session data is only stored server-side and should not be readable by an attacker.

However, bad configurations or vulnerabilities in your code may lead to the disclosure of session content. Reading out the session content is likely not the most severe problem in these cases though.

Reading Session Data from a File

Session data is stored in the file system of the server (the location is determined by session.save_path). So anyone who can read files from the session directory can read session content. This may happen if:

you have a directory traversal vulnerability which allows the reading of files.
on badly configured shared hosts, the temporary directory that stores the sessions may be accessible by others.
you badly misconfigured your server, and session.save_path is publicly accessible
...

Reading Session Data from $_SESSION

If an attacker can read variables, they can also read their $_SESSION global variable.

This will mainly happen when you have a code execution vulnerability, so you have other things to worry about then.

But one could imagine code that makes it possible to read out variables, a simple example may be print_r($$_GET['x']);.


This might not prove successful but perhaps you can try something like the following as it does not use the specific tags (<>) you are referring to:

Set.constructor`alert\x28document.domain\x29```

This was found from the below OWASP source for attempting XSS by filter evasion techniques

Source:
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet


What is the meaning of "something AND 1=0" command in SQL?

The fragment AND 1=0 always evaluates to false and therefore the query always returns an empty set, e.g. if the SQL fragment in the application is

SELECT * FROM users WHERE username = '<placeholder>'

then I can turn this query to

SELECT * FROM users WHERE username = 'admin' AND 1=0 --'

when using admin' AND 1=0 -- as value for the placeholder.

I can now insert a second statement which is executed instead of the intended one, e.g.

SELECT * FROM users WHERE username = 'admin' AND 1=0; TRUNCATE TABLE users; --'

Here I will empty the table users as attack.

Another thing used is OR 1=1 which always evaluated to true. This is used to query a whole table and eliminate the where-caluse completely, e.g.

SELECT * FROM users WHERE username = 'admin' OR 1=1 --'

This is achieved by using admin' OR 1=1 -- as the placeholder in the above example.

In this case the complete table users will be returned.


Where and how to create secret on embedded Linux system?

The most secure way is to use a Trusted Platform Module. This is specific hardware made for storing keys and doing cryptographic operations. This is secure even against sophisticated attackers with physical access (e.g. the FBI), but you need specific hardware which will cost more.

Without this, attackers may just read the key from memory. In that case you may want to come up with a solution that when an attacker compromises one device he does not compromise all devices, as would be the case for example with WPA-PSKs derived from the SSID.

Another post that goes into this is Storing a secure key in an embedded device's memory.


Is it safe or even common to cache bcrypt checks in-memory

Password hashing is used for long-term password storage to deal with the case of an unwanted read-only database access by the attacker. This is a realistic threat; such a read access is a common outcome of successful SQL injection attacks.

On the other hand, a common model is to assume that the attacker cannot read the RAM contents of a live server. In that model, there is no problem in caching the password themselves in RAM, which avoids having to touch the database at all: password verification is just an in-memory comparison. Scenarios where an attacker can read the RAM without being able to take full control of the machine are quite convoluted and unlikely to apply.

Caching the bcrypt output does not make much sense by itself, because, for this information to be useful, it must be somehow indexed by the password and the salt (internally, there would be a map "password+salt" to "bcrypt output"), so the attacker who can read the bcrypt output from the RAM should be able to read the cleartext password itself. Still, in a given existing server implementation, it may be easier to retrofit a RAM cache as such a map (in the code, you can plug that in the "bcrypt engine" transparently); as explained above, caching bcrypt output is no worse than storing plaintext passwords in RAM, which is usually fine.


Is using MD5 in NTLMv2 protocol to store Windows passwords is secure?

Collisions are irrelevant to most usages of hash functions in conjunction with passwords. For password hashing, preimage resistance is important, not collision resistance. MD5's resistance to preimages is (almost) as good as new.

MD5 for password storage would be a poor choice "alone", though, because password hashing requires salts and slowness, both characteristics that MD5 does not offer. See this answer for a primer on password hashing.

NTLMv2 does not use MD5 to store passwords. What is stored is a "password-equivalent" value called "NT-hash", which is the hash of the password with MD4, not MD5. No, this is not weak; for that specific usage, MD4 is still fine. As for MD5, it is used within HMAC as part of the challenge-response protocol, but not for anything that is stored.

There is no known attack against HMAC/MD5. The known MD5 weaknesses void the "warranty": the security proof which guarantees (mathematically) that HMAC is secure relies on the compression function of the underlying hash function: that compression function must be a PRF. The known collision attacks on MD5 demonstrate that MD5's compression function is not a PRF; however, this does not break HMAC/MD5. This just breaks the security proof. HMAC/MD5 cannot be "proven strong". It just fell into the wider category of "we don't know how to break that".


Encrypted NAS where only clients know the (decryption) key

Yes: Windows EFS at least, can be used that way.

Each file is encrypted with a unique, random key and that key is the encrypted once for each user who has access to the file and the result is stored in the NTFS alternate data stream of the file

So, as long as the NAS supports NTFS, you can use EFS on it and the actual file storage server will never see the cleartext content of the encrypted files.


Are captchas based on ASCII art secure enough?

All text-based CAPTCHAs are trivial to break if the adversary is motivated enough. There are been relatively serious claims from different teams of being able to break common text-based CAPTCHAs (although no public code that I'm aware of), including Google and Vicarious.

This is simply because computer vision tasks such as determining the regions of a 2D image or reconstructing partially missing borders of an object are now relatively advanced. So, even though a new CAPTCHA system might not be immediately broken, it would not take advanced attackers substantially more time to break it than it took to develop it.

In conclusion, don't use CAPTCHAs as a single line of defence against spammers and perform more clever forms of risk analysis. More importantly, don't harass legitimate users with CAPTCHAs that your attackers will solve more efficiently than them!


First of all, it would be a usability nightmare.

Second, it wouldn't even fix the problem it purports to. While it could be effective to phishing mails designed for 'normal' clients, attacks designed to suir such systems would probably be even more effective.

The users of such networks would be used to using all kind of alternative ways to refer to urls. Suppose I wanted to link to this question and ask you to upvote my answer, as you don't allow me to write  https://security.stackexchange.com/questions/215871/redacting-urls-as-an-email-phishing-preventative I could say:

security.stackexchange.com/questions/215871/redacting-urls-as-an-email-phishing-preventative
https:/ /security.stack exchange.com/questions/215871/redacting-urls-as-an-email-phishing-preventative
Go to security SE question 215871
bitly 2ZoZiTS
Link sent to your personal mail
Please call to 555-0123 so I can give you the actual url
Search "Redacting URLs as an email-phishing preventative?" in Google
See last active question
hotel  tango tango  papa  sierra colon double slash sierra  echo  charlie  uniform  romeo  india  tango  yankee dot sierra  tango  alpha  charlie  kilo  echo  xray  charlie  hotel  alpha  november  golf  echo dot charlie  oscar  mike slash quebec  uniform  echo  sierra  tango  india  oscar  november  sierra slash two  one  five  eight  seven  one slash romeo  echo  delta  alpha  charlie  tango  india  november  golf  dash  uniform  romeo  lima  sierra  dash  alpha  sierra  dash  alpha  november  dash  echo  mike  alpha  india  lima  dash  papa  hotel  india  sierra  hotel  india  november  golf  dash  papa  romeo  echo  victor  echo  november  tango  alpha  tango  india  victor  echo
Url sent in an attachment

Note that some malicious mails already use urls in attachments as a way to [attempt to] bypass email filters. You might think "I will just strip urls from attachments, too", but that will cause havoc when the documents your users are redacted get silently corrupted by the email system. The formatting may possibly break everywhere, too. Not to mention that such endeavor might require you to be able to (properly) recognize and edit almost every existing file format.

Additionally, your legal department will probably bar you completely from modifying the invoices (received as email attachments), no matter how innocuous the edit.

Also things like recovery links for forgotten passwords would not work at all for your users, either.

But IMHO the main problem would be that the users would be "trained" to do all kind of weird workarounds, a "hidden url" that made them go through such hoops would not raise any suspicion at all.

(And as noted by Joseph Sible, your antispam filter would not be able to examine the obfuscated urls)

Some examples:

Make the user to search "StackExchangeBank blocked credit card" on Google. Then make a phishing page for the StackExchangeBank appear top by using uncommon words, or even buying ads.
If you call me so I give you the url that would be otherwise filtered, I can send you to a phishing page, adding some live social engineering to make you it more credible than just a plain email.
Send them through a url shortener. The user will have no idea where it is getting sent
The n-th question on the list would obviously change, so it would not guarantee the user to arrive to the "legitimate" question you asked, instead voting on a different question "impersonating" the one he was expected to reach.

A much saner approach would be that you changed the urls to go through a redirecting service of yours. Some email security filters already do that. This way they can check, when the user clicks the link if it is listed on a blacklist (where it might not have been when the email was received), and thus block the access. You might also have it show a Big Scary Warning that they are Not going to a safe website, the moment they try to reach a not-whitelisted site (only those they have credentials to, supposedly). And still, such approach would be somewhat flawed since the users will actually have credentials to more sites than those whitelisted at the proxy to not show the warning, and legitimate sites often decide to put out content of theirs on a new domain (which wouldn't appear on the whitelist, obviously). If there are too many false positives, users will end up paying little attention to them, as it would be 'normal' to receive them.


What action plan a hacker can do to enter an iPhone

I'm not against explaining Hijacking techniques for educational purpose. But please, keep in mind that gaining access to device that you do not own without it's owner permission is strictly illegal

That being said, gaining a remote access to an up to date IOS device (without any physical access to it) is a hard task, even for an infosec guy. It's not something you can achieve by watching some Youtube videos explaining how to use Kali tools.

(Beside this, asking tips on accessing apple device 100% remotely on a public forum is bad.)

But since you're supposed to do this for shaping your information security knowledge, i will assume you own an iOS device and have a physical access to it.
The procedure include 4 steps, you will need to perform your own research, from my point of view it's the best way to learn.

So here we go.

1. Fetching the PIN.
Black boxes and the goliath tool might help.

2. Maintaining the access (Remotly).
You want to access the device from anywhere. Installing a VNC server on your iOS device will be the easiest way, Netcat should be ok as well.

3. Remain Stealthy
Here comes the hard part: not getting caught nor raising alert. Stealthy pushing & installing a handcrafted app that hide your presence would be my way of doing it.

4. Being contagious
Very hard but possible: Stealthy delete the iCloud backup and replace them with the corrupted version you just crafted with the 3 steps above. It should give you access to new iOS devices, if the OS is installed from the corrupted backup (your handcrafted app have a big role in this point).


if PCI DSS requires encrypted storage of credit cards, what are requirements for storing the decryption key?

You need to look at the full specifications (available https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss), rather than the quick reference guide to get more details - this covers it in detail in section 3.5.3:

  Store secret and private keys used to encrypt/decrypt cardholder data
  in one (or more) of the following forms at all times:

  Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data-encrypting key
  Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device)
  As at least two full-length key components or key shares, in
  accordance with an industry-accepted method

Other sections around this cover other points, such as how to check that these requirements are being met, and the specific types of documentation needed.


I've had some years of experience with hacking round in mobile environments, here's some of the methods and notes that may help you in getting up-to speed and keeping your own hardware a bit safer while performing your investigation.
For general threat modal and network sniffing ya may wish to check my answer posted to the question of detecting if a phone is secretly sending data noise will have to be sifted though though if the target device isn't compatible with non-root firewall options suggested there and be sure to pay attention to referenced malware jumping from Android to USB connected PC before attempting USB connected forensics. Another option I don't think I listed there was that DNS look-up monitoring/poisoning may help in sorting legit apps' traffic from non-legit traffic.

Small warning, while I've not seen it in the wild it's very possible that the infected device could attempt to attack the Wi-Fi networks it comes across, so consider making a VAP (Virtual Access Point) to separate the network of the infected device from anything else while performing MiTM investigations. Metasploit and others aren't too difficult to install on Android so be very cautious of that infected device sneezing on others.

Now because you've stated that network traffic is noisy and you'll likely end up plugging it in to a USB for imaging it would behoove you to consider either USBguard or disabling HID entirely and use ssh to interact with your forensic device. However, because malware keeps getting smarter it would be a good idea to only use a cheaply replaceable device for USB based forensics; hint web search "system on a chip" and narrow the available options to boards with x86 CPU architecture to have an easier time loading ADB (Android Debug Bridge) drivers and maintaining a solid connection for imaging the file system.

Note once you've sufficiently secured the device that'll be connecting to the possibly infected device the best thing to keep in mind is that push & pull commands with ADB are just as forgiving as in-file and out-file command line options used with dd, which is to say not very forgiving, so be careful.
Side note, Tripwire and similar file system tools can be very helpful for finding cross platform malware, but that and others would need setup prior to plugging in the infected device... only really applicable if your threat modal is sufficient to require forensic inspection of the device preforming forensics operations on the possibly infected device, and this also stats the line of questioning if the watcher is watching the watcher watching the watched in a trustworthy way... and if we go down that line of thought I'll hit the character limits for posting answers again.

Next up is emulating the imaged device, there's a few options but the AVD (Android Virtual Device) manager that comes with Androids' SDK (Software Development Kit) should be sufficient for this task. Make a backup of the possibly infected device, load a AVD to simulate the target's hardware and restore the backup to the emulated device's file system, then go to town on dissecting memory or setting breakpoints or even attempt to penetrate the emulated device in order to find egress points used by the original malware... it maybe possible to root the emulated device too to test if possible malware has been waiting for that before taking actions... oh and be sure to unplug/unmount and remove power from the physical device that maybe infected once you've loaded it's backup into the emulated environment. So long as you're working on an emulated version of the infected device your actions won't break anything for the client so get as rough with the emulated device as you like, however, if you've the space make a backup of the backup so that bricking the emulated device doesn't require re-plugging in the possibly infected device.


Why can't you work backwards with public key to decrypt a message?

There are one-way functions in computer science (not mathematically proven, but you will be rich and famous if you prove otherwise). These functions are easy to solve one way but hard to reverse e.g. it is easy for you to compute 569 * 757 * 911 = 392397763 in a minute or two on a piece of paper. On the other if I gave you 392397763 and asked you to find the prime factors, you would have a very hard time. Now if these numbers are really big, even the fastest computer in the world will not be able to reverse the factorization in reasonable time.

In public-key cryptography these one-way functions are used in clever ways to allow somebody to use the public key to encrypt something, but making it very hard to decrypt the resulting message. You should read the Wiki article RSA cryptosystem.


How to prove Bob has received Alice message

TL;DR Anyone can send a message and say it is from Alice if it is not signed; there is no way for Alice to prove that she didn't send those unsigned messages. However, Alice can prove she sent a message by signing it with a private key. Similarly, anyone can say Bob read a message, and Bob can't prove he didn't. But Bob can prove he read a message by signing it with his private key.

A small side point, I'm going to make a distinction here between having received and read a message. I can send an email to your mail server, (and the network will confirm that it was sent), but if your server is ignoring all incoming data, even though the network says it was received by your firewall, it doesn't mean the mail server actually read the message or has access to it in any way.

In good cryptography, it's assumed everyone can receive the message, but only the indented recipient can read it. Even though Alice here isn't actually encrypting specifically for Bob, we will assume that the message is posted in some public way that it guarantees that Bob could receive it if he wanted to, but encrypted so only Bob can read it (even though you might not technically encrypt it, just require Bob to log into Gmail with his username and password, but the same principle).

In such a case, there is no way for Bob to prove he hasn't received the message; after all, Bob could download (receive) the email from Alice from the mail server to his computer, but not actually open (read) it. If the message was encrypted, he could save the message and his private key to a non-networked computer and decrypt and read it there, burning the computer after he is done. No one could know if he successfully successfully decrypted and read the message or not.

However, at any time, Bob can prove that he has read the message by signing the decrypted message Alice sent, and sending back the signature. The only way he could have access to and sign the decrypted version (which would include having read the non-encrypted email from his Gmail account) was if he had read it.

Addendum: Ideally, Bob would sign the message with his own private key, but this isn't strictly necessary. As long as the message "encrypted" (or sent securely) in some way that only Bob can read it, the only one that could possibly have access to and sign the "decrypted" message is Bob*. If the message is not encrypted or sent securely, anyone could sign Alice's message with any key, claiming to be Bob that signed it.

* Technically, there is a second person who could sign the decrypted message: since Alice wrote the email to Bob, she has access to the unencrypted message and could sign it, claiming to be Bob. If she just wants to know if Bob read her message, this would be silly of her to do. However, if Alice wants to prove to the authorities that it was Bob that read her email, Bob would need to sign the decrypted message with his private key (which Alice would not have access to).


Is there something similar to pseudorandom generators but in the opposite direction?

It seems to me a cryptographic hash, such as the SHA family, would do what you are describing. If not perhaps you could clarify your question.


Automatically reset api key if sent via unsecured HTTP

I don't think this would improve the security at all. If your API endpoint does not have port 80/tcp open, nobody will ever be able to start a connection, let alone send API keys to it.

With a closed 80/tcp port, as soon as anyone sends a SYN packet to it, the endpoint will answer with a RST, the handshake never completes, and no data is sent.

If you have the "expire from HTTP" function at the endpoint, you will have to open another port, listen to authentication, verify the login details are valid, and revoke them. Until the user discovers it accidentally sent data from HTTP, it will frustrate him and forces him to re-login, re-create a key, alter all config files, and restart programming. Without that, and with port 80 closed, the user tries to send data, gets a connection refused error, changes port and happily keeps programming.


How can I create and use self signed server certificate?

If you're just trying to get trusted certs for local Web development that browsers won't reject, this works pretty well:

create a directory called [www.mysecuredomain.com] (make that custom to your project)

paste the following into a file named host.conf inside the directory:

[req]

default_bits       = 2048
default_keyfile    = server.key
distinguished_name = req_distinguished_name
req_extensions     = req_ext
x509_extensions    = v3_ca

[req_distinguished_name]

countryName                 = Country Name (2 letter code)
countryName_default         = US
stateOrProvinceName         = State or Province Name (full name)
stateOrProvinceName_default = [Your State Name Here]
localityName                = Locality Name (eg, city)
localityName_default        = [Your City Name Here]
organizationName            = Organization Name (eg, company)
organizationName_default    = [Your Org Name Here]
organizationalUnitName      = organizationalunit
organizationalUnitName_default = [ Your Org Unit Here ]
commonName                  = Common Name (e.g. server FQDN or YOUR name)
commonName_default          = [ www.mydevdomain.com ]
commonName_max              = 64

[req_ext]

subjectAltName = @alt_names

[v3_ca]

subjectAltName = @alt_names

[alt_names]
DNS.1   = [ www.mydevdomain.com ]

throw this in a shell file (example: create-trusted-cert.sh) above the directory you just created:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout "./$1/server.key" -out "./$1/server.crt" -config "./$1/host.conf"
certutil -d sql:$HOME/.pki/nssdb -D -n $1
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n "$1" -i "./$1/server.crt"
certutil -d sql:$HOME/.pki/nssdb -L | grep "$1"

type this at the commanline:

  > ./create-trusted-cert.sh [www.mysecuredomain.com]

Be sure to modify the values in the directory, host.conf and command line args to fit your project.

Happy developing.


Setting up a IPv6 Darknet/Network Telescope

I have developed such "telescopes" as part of passive network monitoring (company work, not available publicly). I did not find anything readily available but then I had some specific needs as well.

You can start with running a tcpdump on that address, getting rid of the predictable noise and the listen for what is addressed specifically to your address.


Why did Stuxnet have command and control servers?

You have 2 questions here. Let's start with the basic one:

  Why did Stuxnet have command and control servers if it was supposed to infect airgapped computers

The CC servers had multiple functions, which is mentioned in the same book your reading if I remember right:

1: Kill Switch. The entire operation could be killed with a kill switch on those servers in case of incident.

2: Time verification: the CC servers updated the time for the stuxnet virus so it wouldn't get confused and shut down (it had multiple kinds of timers built in)

3: Tracking, which is probably the main reason. These servers allowed for the monitoring of the spread of the infection.

4: Other metric collection.

5: Version control. Yes, when a new version of stuxnet was released the CC servers literally told the old version to destroy itself.

Question 2:

  why would a hacker need command and control servers for malware that primarily shouldn't have ever made it on to the internet?

They wouldn't. Stuxnet's original intention was mass infection. 70% of computers in Iran were infected. The hope was to infect the country so effectively that they were insured of a worker bringing in a flash drive with it. If the goal had been a one off sneaker kit drop it's much, much, less likely it would have CC servers.


Does HTTP/2's opportunistic encryption potentially allow man-in-the-middle attacks?

Opportunistic encryption assumes only a passive attacker (i.e. sniffing only) and thus of course makes man-in-the-middle attacks by an active attacker (which can modify the connection) possible. This is not restricted to HTTP/2 but a general limitation of opportunistic encryption. See also Wikipedia about this topic.


Kerberos unconstrained delegation for user

When you do Kerberos Constrained Delegation (or anything pre-Resource-Based Delegation) on Windows, you assign delegation rights to the identity of the process accepting the kerberos tickets from the inbound hop.

So in short, if the process is running as a domain user, that user needs delegation enabled. If it's running as a System-type identity, the computer does. But you should always Constrain delegation, or use the newer Resource-Based Delegation model (where instead of identifying back-end SPNs, you identify front-end Identities allowed to delegate to the target service identity from the target service identity).

Unconstrained delegation is a bad idea - it might best be considered a stopgap solution in Windows 2000 which gained constraints quickly in Windows Server 2003. It allows impersonation of any qualifying service principal (read: User or computer) to another service, with no restrictions. Get someone's ticket, do anything they can do - so control of a service set with unconstrained delegation meant control of any connecting user.

For IIS Web Applications, that generally means the App Pool Account - the base (non-client-impersonating) identity of the w3wp.exe processes associated with that App Pool. If the app pool is running as LocalSystem (don't do that), Local Service, Network Service or ApplicationPoolIdentity, then the identity used for decoding Kerb tickets and delegation is the computer account. (Couple of other caveats there like UseAppPoolCredential=true or UseKernelMode=false might also cause a non-custom user identity to be used to try to decode a ticket, but that's out of scope.)

Any Security Principal can be assigned delegation rights. Giving any User object a Service Principal Name (SPN - use SetSPN.exe), which computers have by default (HOST/computername) will enable the Delegation tab in DSA.msc.

One exception to the above is Group Managed Service Accounts (gMSAs), which should be your first choice for any new service which uses a Domain identity to run a service, as it self-manages its complex password, preventing easy long-term-password attacks on the account itself.


Preserving anonymity with ring 0 malware infected PC

With Ring 0 (kernel) malware anonymity can be preserved
You just need to make sure you are under control of Ring -1 before you get infected by using a Type 1 hypervisor (one that runs underneath the operating system's kernel), and that the Virtual Machine that receives the attack is completely isolated from anything that can leak any identifying information.
One desktop operating system that is specifically designed to prevent those attacks is Qubes OS, which integrates seamlessly the windows of different Linux virtual machines running on top of the Xen hypervisor (Type 1). One of the included Linux distributions inside Qubes is Whonix, which is designed specifically for anonymity, and it is run on two separate virtual machines: the workstation, which is the one that has the Tor browser, and the gateway, which provides the workstation with access to the Tor network only in order to prevent leaks.
As a bonus, Qubes comes with disposable virtual machines out of the box, which prevent a successful attacker from gaining persistence by destroying the virtual machine once you have finished using it.
Note: for virtual machine isolation to work properly, hardware Virtual Machine extensions and I/O MMU virtualization should be enabled at BIOS level, the CPU should not be vulnerable to speculative execution exploits (or at least have it completely disabled) and the laptop should have ECC memory in order to prevent Row hammer attacks.

With Ring -1 (hypervisor) malware, maybe...
Aside from the potential solutions you mentioned, the following measures could make it feasible:

If the threat is an authoritarian nation-state, while buying that laptop all identifying clothes should be avoided, the face and all identifying marks (scars, tattoos...) should be covered (covid mask + sunglasses, helmet, long sleeves...), the hair should be dyed or not visible, the means of transport should not have an identifying plate (bike, electric scooter...), no devices with radios should be worn to the meeting point and talking should be avoided. The laptop and BIOS clock battery should be both removed immediately (or in an unidentifying place) until the webcam, microphone and all the radios are removed from it (Bluetooth too).

With the laptop still switched off and with the batteries out (with an EEPROM Programmer) the BIOS firmware should be replaced with an open source firmware (Coreboot, Libreboot, Oreboot...) image modified in order to have ALL internal device controller's (SATA, USB bus...) names and serial numbers changed/translated into fake ones to the OS. Of course, the laptop should be compatible with your firmware of choice and the patch should be developed, but achieving that is far less work than programming a secure OS or hypervisor from scratch. The patch should also address other hardware deanonymization methods, like the ones listed on the Whonix Wiki:

The gateway's MAC address should be faked too and, to prevent traffic correlation attacks, it should run a Tor relay and/or use/be a Tor bridge with a pluggable transport that randomly pads the frames (like obfs4). It should also use a different OS with a different kernel (BSD...), a different Instruction Set Architecture than the laptop (ARM, PowerPC, MIPS, SPARC...) -and preferably a different open source firmware too- to prevent the malware from exploiting the same vulnerabilities on the gateway.

All human interaction should be kept unidentifiable.

With Ring -2 (firmware) malware, I don't think so.


Are hiding and obfuscating the URL parameter keys a protection against tampering?

It will obfuscate the actual location of the script, but on it's own there is nothing preventing an attacker from guessing/dirbustings/etc the product.php file and accessing it directly. The attacker would have to then identify the correct parameter names (id & action). Once the attacker is accessing the file directly the rewrite rule does not apply.

So you could potentially raise the minimum effort required to attack your script, however you would need may rewrite rules and they are not very performance friendly so you could be introducing a denial of service condition in the process.


I don't know if passing nonce as AAD would be security risk, I don't know much about the maths behind Galois authentication to answer it, other people in crypto SE might be able to answer. But you don't actually need to do that. All you need for GCM is use the same AAD used during encryption, during decryption if you want to pass authentication. AAD can be some plaintext and kept with the cipher just as nonce, why do you need to do that anyway? You can use any general tag as AAD. It only saves a few bytes/kilobytes of storage while possibly risking. And AAD is optional too, you can use GCM without AAD. What you should never do, however, is repeat nonce for the same key, it destroys both confidentiality and authentication provided. GCM is streaming mode cipher and nonce reuse has more devastating consequences than modes like CBC. I would also recommend you look GCM-SIV mode, which can help guard against IV reuse due to poor entropy source used by your random number generator. There are recommendations for using identifying information in GCM to prevent replay attacks.
EDIT:
Another option if you do not need to worry about replay attacks: You can also use constant AAD for one use case. It is not a security risk and does not require transferring AAD. It also prevents using one piece of encrypted data from being used in another context in case the format happens to match


Why would I use MAC over digital signature?

Performance alone is a reason to use MAC.

Consider a TLS connection. For every packet, the receiving party needs to verify that the packet wasn't modified in transit by a man-in-the-middle attacker. So for every packet, the sender needs to calculate a MAC/signature and the receiver needs to verify it. If you want, say, a 10MB/s transfer rate and an average of 10kB/packet, that means you only have a fraction of 1ms to calculate or verify the signature. That's too slow for a digital signature.

The amount of time it takes to create and verify an asymmetric signature is small enough to be a non-issue if you do it once when a connection is established, assuming you have high-end hardware such as a PC, server or smartphone (it can be an issue on embedded devices). But it doesn't work if you need to do it once per packet.

A digital signature has the advantage that it can be verified by a party that isn't able to generate a fake signature. This isn't useful in a case like a TLS connection. For TLS, the two parties set up a session key, which is a symmetric key that is generated randomly at the start of the connection. After that, the only two parties that know the key are the client and the server. If the client sees a valid MAC (that it didn't generate itself), it can only have been produced by the server, and vice versa. Similarly, once the session key has been generated, it (and not asymmetric cryptography) is used for encryption.

(Properly speaking, the same key shouldn't be used for different purposes such as MAC and encryption, even if it happens to have the right format. I simplified things a little above. The “session key” is actually some secret material from which an encryption key and a MAC key are derived — or, in some ciphersuites, a single authenticated encryption key is derived, although the AE algorithm then derives two keys internally.)


Sounds like you want dynamic security policies. A custom OS build may be the only way to  achieve this. Since Android is open source, it's been researched/hacked pretty extensively with this in mind. iOS has one or two projects going, too. Never seen any for Windows/Blackberry.

FlaskDroid, for example, is a child of Security Enhance Linux (SELinux). A good research paper written on it is here, but to surmise they implement a user-space security server which all API requests for sensitive data (SMS, Contacts, GPS, etc..) run through. (Alternatives are MockDroid, AppFence, and Taming Information Stealing Smartphone Applications (TISSA).. all very similar but I think FlaskDroid is the best).

This security server implements policies chosen by the user. As a bonus, they also protect against root level MAC queries, so if your device becomes infected by malware running as root, it cannot get to your data without an appropriate policy.

Obviously, this has a couple of drawbacks:

Kernel was hacked, so it must be installed on your device ad-hoc as rooting is required.
Trusting SELinux

Alternatively, the applications themselves can be hacked for increased security. Because it's Java, and in turn just a series of bytecodes, apps can be modified with instrumentation. Research has been done on this with Redexer, but that's written in OCaml, and nobody wants to do that.

One of my current projects is to implement instrumentation using Java, so that we can tie down any application with dynamic permissions. All the developer has to do is write what Java code they want to execute when contacts are accessed, for example, and my tool will go in and instrument the application to behave in that way. So, in this way, I've implemented dynamic permission policies... users can grant or revoke any permission to any application after installation. They can also be activated/deactivated depending on geophysical location, so at work the camera is shut off from all applications. Paper is pending review. No rooting of the phone is required.

In this way, you could block network access to all but a few "allowed" domains, such as your company's calendar syncing servers, disallow access to calendar unless the user clicks on a pop-up.. etc. As for encrypting the SD card, Android natively supports that now.

iOS project for dynamic security policies: Protect My Privacy. (Paper). Requires jailbreaking.

EDIT: To clarify, SELinux prevents any actors from performing actions they have not specifically been granted. It boils down to Mandatory Access Control (MAC) vs. Discretionary Access Control (DAC). DAC doesn't protect against rouge users/processes running as root. MAC does protect against malware running as root, assuming the malware wasn't specifically given full access privileges (which should never happen; the idea is that nothing is ever given more permission than is absolutely necessary).


How would you remove the malware from a router or switch?

If

the installed malware is only present within the storage that gets
overwritten by a firmware reinstall
you can trust the firmware you're about to reinstall, and
you can trust the mechanism by which you reinstall that firmware

then yes, it would be enough.


Can a site I browse in private browsing mode tell if I visited it in regular mode before?

Yes and this is by design:

  The point of incognito mode is not to prevent server side tracking. The whole design is about not leaking information on the client (about visited sites).

This comes from the Chromium team - look at Comment #8 I believe other browsers work similarly.

Some of the ways a site could do this:

ETags - these are cache directives. If the page has been cached in normal mode, then these cache entries are available in incognito mode.
IP address
Browser fingerprint - screen resolution, installed plugins, etc.

You may be able to get better privacy by using Privoxy in combination with incognito mode.


Compromise Google GSuite by buying expired domain

A couple of months ago I was searching google for the same questions, and I found that someone is providing the list of expired domains where free google legacy accounts are still active.

https://www.fiverr.com/share/DAPPA

I ordered that service and received a list of available domain names. All login pages for those domains were active but no login info was provided.

As per the guide provided by seller, anyone can reset admin user password by verifying domain ownership. But when I start the process by registering a domain name it was not like that, google asked me a lot of questions about account owner and old organization in order to give me the account access.

There were few recovery methods explained in the guide which were quite difficult to complete, I register 11 domains but failed to recover Gsuite accounts on all accept 3 with 500 users free license. It took me 3 weeks of research to succeed.

Conclusion:

Old Gsuite account recovery is a nearly impossible and quite difficult process but if you find any loophole or sufficient information about the previous account holder and his company details in archive web, you can reset admin password as I did.


How can I safeguard myself if share the same router with the people living in my apartment

To protect your own communication with the internet against sniffing by other on the same local network you can use a VPN, i.e. the typical VPN for private use which starts the VPN connection at the local system and has the VPN exit somewhere on the internet, outside of the reach of the other users of the same router and of your ISP.
Protecting yourself against liability issues this way is not possible this way though. All users behind the same router share the same external IP address and thus everybody able to use this WLAN (i.e. knowing the password and being locally present) will be suspect. While the external sites will see only the IP address of the VPN exit and not your original external IP address when using a VPN, it is likely impossible to prove that you've actually used a VPN all the time.


Are Free SSL/TLS Certificates Trustworthy ? Can Cert Providers Snoop On Traffic?

The SSL certificates used on web servers have two purposes:

They identify the web server, so that persons browsing to that site can be sure that they are not accessing the wrong site.
They encrypt the traffic, so that nobody can snoop on the traffic.

Identification
In order for any CA to be included in the common browsers (i.e. Firefox, Safari, Chrome, Internet Explorer, ...), the CA must follow the rules set forth by the CA/Browser Forum. This means that they must make some effort to make sure that a certificate identifying example.com does not get issued to anyone who isn't the owner of that domain. Different CAs do this in different ways. On the expensive side, in order to get an EV certificate from Verisign, you'd need to show actual proof of ownership of the domain as well as proof of your identity and your authority to request the certificate. This will include actual paperwork that gets inspected by humans - which is of course the reason for their certs being expensive. So a certificate issued in their Extended Validation program is about as reliable as is possible; you should be able to be certain that not only is the domain right but that the organization mentioned in the certificate is also verified.
On the free side, LetsEncrypt only need you to add a specific DNS record or HTTP resource to prove your ownership of the domain/web server. That way they have no idea of your actual identity, but they do know that the person making the request for a certificate is also in control of the domain. That is all the identification their certificates offer.
If you're not a company that needs to have the level of trust implied in an EV certificate, having a cheap or free certificate may be all you need. If you're a bank, or any big business, you probably want people to feel extra secure, and so you'll be willing to pay for the higher level of identification to get their company name next to the padlock in the browser window.
Encryption
TLS/SSL uses a public/private key pair. The CA that issues the certificate does so by signing the public key, aka the certificate. But they never see the private key - and it's the private key that is used to encrypt the traffic. This means that the CA has no way to snoop on the traffic.


What college majors are suitable for a career in security?

It depends on the type and level of security involved. "Security" is a MASSIVE topic: operational? network? web application? software development? defense? offense? penetration testing? auditing? policy? education? Each one of these can require vastly different qualifications and education.

Further, there is no inherent requirement to have any particular education. I got my first IT Security administration job without a degree at all, but I did have a lot of experience in network and database administration. On the other hand, for me to transition to top management requires an MBA, in some places. There is no defined path and no golden ticket.

To quote an old mentor: "It's not what you know, it's what you do with what you know."


JWT vs custom encryption for REST APIs over https

Don't roll your own crypto!

This is the golden rule of cryptography. If you do, your application will crash and burn, and all the hackers will laugh at you. It has been done time and time again, with companies boasting about how their "custom encryption algorithm" is perfectly safe, because it's closed source and no hacker could ever figure out how it works. Turns out that it had huge glaring issues and exploiting it was trivial, every single time.

Even expert cryptographers, who spent decades studying how to make good cryptographic algorithms, consider it extremely difficult to make an algorithm that is safe against all kinds of attacks.

But what should we do now?

That depends entirely on what your API actually does, and what you use these parameters for. What JSON Web Tokens do is "representing claims securely between two parties". If this is what your API needs, then you should absolutely go for JWT.

Basically, once the user has authenticated themselves to your API, the API can then generate a JWT and send it to the user, which they can use to authorize themselves on every subsequent claim.

But can't an attacker just copy my token and thus steal my authorization?

Yes, if you used plaintext communication. But you should not be using plaintext communication, you should be using HTTPS to secure everything.

So why would you actually use JWT then? Because it prevents the person you sent the token to from modifying the claim. If you sent

{
    "uid": 163495,
    "sub": "MechMK1",
    "role": "User"
}

to me, then I would not be able to modify the claim to set my role to "Admin", for instance, since then the signature would not be valid anymore.


Can YouTube thumbnails contain exploits?

They can, but it is VERY unlikely.

Since both Youtube videos and images go tru multiple stages of cutting, converting to other formats etc. it's very unlikely that your exploit would be kept in such environment. Best it could do is hijack one of Google's converters where it would probably easily raise some red flags on intrusion detection systems.

Even assuming your exploit would be able to survive such changes (which is basically impossible), then it would be subjected to many different OSes, web-browsers etc. It is very likely that many of configurations would detect something bad with your image, so most systems wouldn't play this video/wouldn't display this image, possibly even detect that exploit (because antiviruses, incompatible OS, EMET etc.). This again would raise some red flags, most likely before that video was seen by many people. And your impossible exploit would be ruined.

And that's exactly why most exploits are kept for valuable targets - it's very easy for them to be found in so diverse environment that Internet certainly is. And then they quickly become useless, because most of users who were vulnerable quickly update.


Did I stumble upon a cell hidden network or is my device being attacked?

I strongly suspect those four characters are an "A", a "T", an "&" (the Sun symbol) and a "T" again. Possibly the UTF8 for 4F10, 5418, E298BC and 5418.

Actually, as @Matt observed, the little-endian UTF16 sequence 4100 5400 2600 5400 ("AT&T"), if interpreted as big-endian, becomes 䄀吀☀吀 which closely matches the strange logo that appeared in the cellphone.

Possibly whatever packet contained the carrier "logo" got corrupted, CRC notwithstanding, and was interpreted as a foreign character set.

Update:
Two users added comments (unfortunately posting them as answers, which got them deleted) confirming that this happened to them; in one case on September 29th and 30th, "several times [...] traveling through North Dakota, Minnesota, Wisconsin, Illinois and Indiana... usually when AT&T signals were weak."


I'll answer for Nessus and AWS.

Nessus has several options for performing port scans (e.g. netstat (WMI), SYN scan, TCP scan, and UDP scan). Some scans have specific requirements. For example:

TCP scanning requires Nessus to be installed on Linux (otherwise this scan falls back onto a SYN scan)
netstat (WMI) requires the target to be Windows
Netstat 'scanner' requires the targets credentials and the target has netstat available

Assuming that you're meeting these requirements for proper scanning, then I believe you likely have a networking issue and would recommend some low-level testing of a specific example. For example, if you're performing a TCP scan and, using nmap, see port 22 open on your target, then attempt to telnet to that port at the target from your Nessus host to verify that it's accessible.

Best practice is to run port scans on both the internal and external networks to identify what's open both internally and externally. Running the scans on internal addresses within your VPC should be done from within the internal network. To protect against an attacker who has access to resources within your VPC, run the scan from within the VPC. To protect against an attacker positioned within your internal corporate network (e.g. with a direct connect to AWS), run the scan from within the corporate network (assuming this is outside of the VPC). Defense in depth would dictate performing each of these approaches and ensuring results meet your expectations.

One technique I've used to perform periodic scans: configure an AWS Lambda function to run periodically and perform the scan. It will take some scripting but is easy to configure and you have flexibility in where to send results.


You would want a large list of secrets on SPIFFS files (removing after use) or track used secrets (and search for usage using a set of nested 1st letter\2nd letter\etc folders) to prevent a replay attack.

A dash button is simple; depending on your other libs and code, you probably have enough RAM left to use HTTPS (depending on the cert). That would make replay a lot harder since the prior guesses would be "dark" to observers. You can likely re-use keys or at least parts of keys if you use HTTPS.

Another option would be to use secure ESPNOW to talk to another ESP which has an Ethernet controller which talks over the wire to a PC that then uses HTTPS to talk to the outside world, and can further authenticate requests in a PC environment (lots of easy options) instead of an MCU environment (few hard options).


First, your approach for usernames/passwords - it shows that you are a novice to security, which is fine, but means you likely ought not be designing a secure file store.  However, here goes with some more constructive feedback :

1) You NEVER store user passwords. Full stop. What you do is store a salted and hashed version of their password.  When they attempt to login, salt and hash, compare with the stored hash.  From OWASP : https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

2) There's no reason to use asymmetric encryption here - you can simply encrypt and decrypt from your data store.  Store your key (and IV) in a secure location - traditionally, this is a file only accessible to your application on the server, where you ensure your application is running as an isolated user.  However, more modern systems for key storage include HSMs (hardware modules, very expensive) or systems like Keywhiz or Hashicorp's Vault - complicated, but cheap.  This is better if you want key rotation (good!) and redundancy in application servers.

Seriously, if this is a real application, these are things that need experts beyond random ones on the internet - there are a lot of subtle errors you can make that will devalue all the other security measures you take.  You need to do everything right - get some professional help.


Do PKCS #11 keyfiles on a yubikey actually improve security for Veracrypt?

This question is indeed a very good one. I'm no expert but since nobody is jumping in (I guess because questions that already have at least one answer are less attractive).
Florian's answer to this question is just a boilerplate of how things are supposed to work with PKCS11 but not at all the way the standard was implemented in Veracrypt.
As the developers acknowledged recently here Veracrypt does not support asymmetric keys. If you try to use an RSA key from a smartcard as a keyfile the window "Select Security Token Keyfiles" will come out empty. Quoting from the link:

...I also have the idea of modifying VeraCrypt format in order to support using Asymmetric keys (RSA or Elliptic Curve) that are stored on such cards or tokens: these keys will be used to decrypt the header volumes instead of relaying [sic] on the password. This will provide stronger security and but it also requires a big development effort while at the same time targeting a very small number of potential users...

That's that then, private keys (CKO_PRIVATE_KEY) are out of the question, what about symmetric keys (CKO_SECRET_KEY)? Nope, that's not supported either.
How exactly is PKCS11 supported then? Well... if you take a look at the code: SecurityToken.cpp you'll notice on line 215 a reference to CKO_DATA. Let's go take a look at the PKCS11 standard to find out what that is:

Data objects (object class CKO_DATA) hold information defined by an application. Other than providing access to a data objects, Cryptoki does not attach any special meaning to a data object.

So, if it's not a key (public, private, or secret) and it's not a certificate it will be a data object (no strings or special meaning attached). I don't know exactly what was the original idea behind this kind of object, what I know is they ended up being used for different things, the one I've seen most frequently is to store personal data. One example could be your name and address on a European national eID card or your picture on an ICAO compliant electronic passport.
Is this CKO_DATA object supposed to be used to hold keys or passwords? I don't think so because if you do that you are basically giving up all cryptographic features of the smartcard or token.
Is this better than storing your keys on your disk unprotected and unencrypted? I guess it is, at least on most tokens your keys will be password protected. I would agree it is the same as storing your keys on a password-protected non-cryptographic USB drive.
On this topic, I'm sure you will find all kinds of opinions. There was an interesting debate on the opensc github some time ago.


How do I inform a company I found a leaked database of theirs on the Internet?

Don't give security info to non-security people. Use whatever contact method is available to ask for the right security person. Don't give details about what you found until you get someone who will understand it.

Then provide the details about what you found. Don't ask for reward or demand any kind of action or else you are very likely not to be taken seriously. Just provide help and leave it up to them to deal with.

I'm not sure what kind of template you need. Give them the info/steps they need in order to locate the information you found. If you sound too "scripted" you might sound like a scammer. Be human. Be helpful.


Authenticating Hotmail's certificate and connection security

Assuming the cert chain is actually valid, it looks like its for bing.com instead of the *.mail.live.com domains.

I'd be surprised if anything malicious is going on, but more likely a bad DNS entry, poorly configured certs by Microsoft, or potentially just one part of the browser not realizing another part of the browser is redirecting to the configured search page.

You can test this by comparing the cert on the bad page, with the actual bing.com cert. If cert details match up (thumbprints, CAs, issuance/expiry dates, etc.) then it might be reasonable to chalk it up to environmental issues.


Wifi penetration testing: waiting for beacon frame

If you know the channel you want to attack, then when setting your network interface in monitor mode, just specify it:

airmon-ng start wlan0 1

Also, I notice you use -1 0. Don't forget that this "attack" mode does not work with WPA/WPA2.


How much can domain admin really do without access to domain controller?

Maybe this will help:

You said:
"With almost all ports blocked on the domain, there is no way for intruder to remotely access domain controller and do big changes to the domain."

All ports blocked? inbound or outbound? This is the idea behind rats/backdoors.

If a domain admin can control any system, they can disable a system from domain restrictions if they wanted to. Leaving them more vulnerable than you'd expect (a monitoring note). If they domain admin wanted access to the domain controller, they'd pretty much just need to backdoor or monitor a user who does have access. They can launch exploits that may require admin privs locally to exploit. Fileshare and vm escapes sell for some good monies these days. I mean, there's a whole world of possibilities. If your single point of failure is your DC, you might want to think about the platform your DC is on. Most people, it's on windows, with other services, on a shitty physical box or virtual instance. If it's in a virtual instance, that's probably within a whole other realm. People have found attackers using dns, http, smtp, irc, xmpp, smb, nss, slack web api, other web api, etc... to pull data about your enterprise out depending on abilities of your network. Some attackers have dozens of malware generators just for these types of network and will rotate between sample structures until something else works (often from phishing).

So, to answer the question, your enterprise is at stake. You don't need domain controller access, which an intruder would have better leverage to attack at with domain admin creds, to own an entire company. That hasn't been thought of as needed or required for many years. The claim that ports being blocked doesn't really change that.

If your entire network has no external access, PoC campaigns have shown that this doesn't really stop someone dedicated to taking your company.

Soo.... The reason why people put so much effort into it is because it's a baseline monitoring requirement if nothing else to attempt to protect administrative accounts that can compromise any system in your enterprise.


How did Evernote detect the security breach?

Speculation: they look to hire people who have experience with:

OSSEC (host-based IDS)
Tripwire and Samhain (file integrity)
Splunk (log aggregation, reporting & alerting)
Nagios
firewall & threat management
grsecurity/pax/suhosin etc
Nmap, BackTrack, and Metasploit (proactive security tools)

When the perimeter was breached, their monitoring and system management worked.
Assuming a least-privilege model, non administrative accounts accessing tables/data to which they do not have access (logged violation); or queries which do not match "known good" patterns (adaptive or anomaly detection); or queries which match "known bad" patterns (SELECT * FROM USERS), i.e. signature based IDS; or atypical system load patterns; or atypical data volume per query.
DLP, i.e. outbound content filtering/inspection for canary values, or suspicious values (the classic case being strings that are valid credit card numbers or SS numbers)


Unexpected/unwanted/unknown participant joined WebRTC session

The WebRTC APIs provide the means to capture audio/video and transfer data to other peers. To get connected to another peer, both peers need to exchange their local session description (SDP) which contains (among other (authentication) data) the IP addresses and (random) port from where the peer can be reached. These IP addresses are found by querying the local network interfaces and via STUN. The WebRTC (RTCPeerConnection) API provides a way to generate this SDP, but not a way to transmit it to the other peer (known as signaling).

It should be clear that it is extremely unlikely to get connected to a random stranger by accident, because the browser needs to generate the SDP and also has to listen on the local port as stated in the SDP. So, most likely one of your libraries has a built-in signaling mechanism (commonly via WebSockets) to share the SDP with another peer. This turns out to be the case in your specific example: https://bitbucket.org/webrtc/codelab/src/c75c8e837a125441d2ee008c55348ac5a24a85d4/complete/step8/index.html links to http://simplewebrtc.com/latest.js, which defines a default (external) server for signaling (https://signaling.simplewebrtc.com:443/).

If you open the browser's devtools before (re)loading the page, then you can inspect the protocol messages in the Network tab.


Why would my SSO information be cached on my iphone?

SSO architecture has layers to it, we can usually break these out into two main components:
- The Identity Provider (IdP) sessions.
- The Service Provider (SP) session.

Each of these sessions will usually be preserved in the browser as a cookie, as you state above. The IdP session is usually the "key" to SSO, and has a set expiration date. However, in some architectures the SP issues its own session after a successful assertion from the Identity Provider. This SP session can be independent of the IdP session, and the SP may not check with the IdP for staleness of the session.

So, I don't think you have an actual SSO session. I believe you have a session with this specific SP you were testing against. If you clear your iPhone history/cookies/cache completely, this should certainly not work. The root cause is likely that the SP does not expire sessions, and the issued session is long lived and sitting in the iPhone browser cookie jar. I suspect your other browsers have cleared the session when closing the browser.


How can websites with URL traversal functionality protect itself from revealing its IP?

It generally all comes down to the question: how important this functionality is for your business?

Option A: said URL traversal functionality isn't very important for the Web site. Say, that site can do a lot of things, and taking screenshot is a feature the site can more or less still live without.

Then it's enough to use any VPN or proxy on a different IP address (or, better, in a completely different IP network or even ISP/hosting provider) to connect to untrusted sites. Make sure the proxy doesn't set X-Forwarded-For, Forwarded or X-Real-IP HTTP headers (some of them do it by default). Also make sure all service traffic like DNS queries is routed through the same proxy or VPN.

Option B: the URL traversal is a part of the core business critical functionality, the Web site won't run without it.

Then a DDoS mitigation of some sort should be applied there too.

Good news: compared to the complexity of a typical Layer 7 DDoS protection nowadays, protecting such a functionality is rather simple: a provider only needs a decent amount of bandwidth and a stateful firewall with a TCP connection tracking ability near the network border.
Bad news: as of early 2018, neither Cloudflare nor Incapsula can do that, so you need to choose another provider for that. If you happen to have your own IP prefix and an autonomous system number, probably a BGP-based DDoS protection suits you even better than DNS-based one in this case, especially as we currently are running out of IPv4 address space.


This seem to talk about using an alternative location for keys on a file system: Key storage providers in ASP.NET Core It is strange that I could not initially find it, but the result appeared as soon as I dropped 'Microsoft' from the DPAPI search terms.
The linked article must be talking about user keys, unless I am missing something. This would make sense, because, like I presumed, backing up a machine key is a security risk. I am pretty sure I can go from there and base any further encryption on user keys.
I was also interested in the article DPAPI and Roaming Profiles that is linked from Key encryption at rest in Windows and Azure using ASP.NET Core but it throws 404.
A high-level solution seems to be to use a file-system backed user key store and to enable key encryption at rest, making sure that the key encryption key is also backed up somewhere.


How can I find the size of an array just from compiled C program?

There is a pretty good explanation at the following link on stackoverflow:

reverse engineering c programs

Short answer: There is no way to get exactly the same code that you have on a C written program.

It passes through many stages until it reaches binary code for a specific machine. It is somehow compared to an ice cube that melted, assuming that you have lost no water through evaporation. There is no way to get the original ice cube EXACT shape, unless you have a mold(and yet, the internal formation will not be the same).

Having a good translator that could look at assembly pieces and figure out whenever it could be an array, would be the best solution. But this tool does not seems to exist as far as i know.

This guy at re.stackexchange have some tips on how to look at the disassembled code, and get the information you want about C arrays:

How to find the size of an array in binary?


How do I make safe login-emails? (GET/POST)

So, first of all, links from email change state all the time. While non-idempotent GETs are a violation of the de jure standard, the de facto standard is that any browser or email system which doesn't allow users to make GET requests for things like email verification, password reset, and the various other services that use email-based passwordless login (such as Slack) is a browser or mail client that everybody will consider broken. Another common example is the "logout" link (which on many sites is just a GET to https://example.com/logout, without even any CSRF protection); while this is potentially a security risk, in practice it is extremely widely used and difficult to exploit as anything other than a prank.

WITH THAT SAID the standard way to handle this is safely is for the link in the email to contain a (strong random unique) token that takes the user to a landing page, and the landing page says, basically, "hey, you appear to be [username], click HERE to log in" along with a "Not [username]? Click HERE instead" link in smaller text underneath. The emailed link expires after either link on the landing page is clicked, or after a certain period of time has elapsed (usually no more than an hour), whichever comes sooner. Loading the landing page does not immediately expire the link, though, and the "links" on the landing page can safely be buttons on a HTML form that POSTs to your service, or JavaScript triggers. The "links" on the landing page should ideally have CSRF protection.

This has a few advantages:

No problem if the landing page is visited "ahead of time".
No way for an attacker to trick somebody into signing on by accident.
No state-changing GET requests needed (though the JS event could just trigger a navigation to an unpredictable "complete this login" page, if you don't care about that part of the spec).
Allows the user to cancel the login if they clicked the link by accident, or have multiple accounts and used the wrong one by accident.

It also has some disadvantages:

The user has to click an extra time. You can mitigate this by have a timeout that automatically logs the user in after a few seconds, if they don't click anything or close the page.
The token sent in the URL can potentially remain active for a period after being visited. This is a risk because URLs are sometimes logged in places where untrusted users might see, or are otherwise exposable. I don't think there's any mitigation for this (aside from having the lifetime be very short) other than making the link itself single-use, which both breaks "GETs should be idempotent" (not actually a big deal, as explained above) and "pre-fetching this URL should not break stuff" (see above).

Incidentally, webmail services and web-based chat systems and so on pretty much always rewrite links in received messages (try copying the actual link out of a Gmail message, for example; the status bar text is a lie). When you click the link, you get bounced through a redirect page in another tab, rather than it opening the destination in that other tab directly. This prevents things like the linked-to page using the window.opener property to mess with the webmail/chat page.


Getting strange texts to an iPhone #PWD123456#00X

Regarding your dad's iPhone, there's nothing to worry about. This is just an automated attack against Wafer GSM-AUTO (SMS-capable) devices.
The Wafer GSM-AUTO is a very simple Microcontroller. You can think of it as a remote power switch. It control anything from a security door switch to a normal light switch.
I'll try to translate the commands for you

#PWD123456 : Use the password 123456, which is the default
password for this device. We all know how common it is for people to
leave the default passwords.

#WHL004=2398480389 : Add the number 2398480389 to the list of white-listed numbers.

#STATUS : You're basically asking the unit to give you all the information about it. A real device would have responded to the attacker with an SMS containing information about the whitelist, the status of the system, the mode of operation, and other information. Basically the device will send you all the information you need to continue the attack.

#OUT1=ON : As with any simple-to-use microcontroller, usually users will use the first ports for their outputs. Here the attacker is attempting to switch on the port #1. This could be a garage door, for example.

Another possiblity
There's a high probability that this is not an attack, this is very likely just someone testing his new Wafer GSM-AUTO device and mistakenly typed the wrong number. Hey, it could be one of your dad's friends (If your dad's name starts with "A", that's even more likely).


Has the hard drive been accessed or computer hacked?

There are some ways to detect tampering, you'd want to apply a tamper evident sticker on the computer case or drive's port. It's not fool proof, but it'll make tampering without getting detected a lot more tricky.

It's easiest to apply the sticker on the case. Although you may want to also apply the sticker on the cable ports, on the motherboard side and the drive side, if you can find a sticker that's small enough for it and sticks to the surface of the connectors.

Best way to prevent unauthorized copying though, is to encrypt the drive. They'll still be able to copy the data, but without the decryption key, the copied data is useless.


Comparing Session Hijacking, Fixation and Riding

In session hijacking the attacker somehow gets hold of the victims session ID and uses it to impersonate the victim. The attacker essentially takes over the victims session - hence the name.

To do this the attacker needs to find out what the victims session ID is. This can be done in many ways, e.g. MitM or XSS.

In session fixation, the attacker picks a session ID and forces it on the victim. For example, if a website accepts session ID:s in the URL, the attacker can fool the victim to visit http://example.com/?session=123456. The victim does this, and then logs in. When the attacker now browse the site with the session ID 123456 she will be logged in as the victim.

Note how this is sort of the opposite of session hijacking - the attacker sets the victims session ID instead of getting it - but the end result is the same. The attacker knows the session ID and can impersonate the victim.

Finally, session riding is just another name for cross site request forgery (CSRF). See this old answer of mine for an explanation of what it is.

The main difference from the two above is that the attacker does not know the session ID. Instead she abuses the fact that the browser will always send the session cookie with all request the victim makes, even if the victim did not intend to make them.


OAuth - What if the refresh token is stolen?

TL;DR: Yes refresh tokens are bearer token and so should be protected.

Refresh tokens are powerful because in general they are:

long term: meaning that they have long expiration times
privileged capability: meaning that they allow the bearer to renew their access token.

Refresh tokens are also bearer tokens, which means the service consuming the token will give access to the bearer of the token --  no questions asked. This is similar to access tokens.

So making sure bearer tokens are protected and stored securely is very important. The more critical a token, the better it should be protected.

As an example in OAuth2, implicit flow which is generally used with mobile apps, the client side app has a short lived access token. They are also generally not given a refresh token. Since a client side app can be easily compromised and any data/tokens be compromised, its bearer tokens have limited privilege and lifetime.

In contrast, in OAuth2 authorization code flow which is generally used with server side apps, the server app is given a longer lived access token or/and a refresh token. This is because it is assumed that server side is more trusted and less likely for it to be compromised. Having said that, server side tokens should still be stored securely given their usage pattern.

To summarize, when deciding what kind of tokens  you need, check:
- trust level of your client and the flow most appropriate for that trust level
- protect your tokens!


How are Bitlocker FDE keys stored in the TPM?

Plain text, but is stored on a "secure HDD" on the TPM.

Snippet from Microsoft website.

  Computers that incorporate a TPM can create cryptographic keys and
  encrypt them so that they can only be decrypted by the TPM. This
  process, often called wrapping or binding a key, can help protect the
  key from disclosure. Each TPM has a master wrapping key, called the
  storage root key, which is stored within the TPM itself. The private
  portion of a storage root key or endorsement key that is created in a
  TPM is never exposed to any other component, software, process, or
  user.

  You can specify whether encryption keys that are created by the TPM
  can be migrated or not. If you specify that they can be migrated, the
  public and private portions of the key can be exposed to other
  components, software, processes, or users. If you specify that
  encryption keys cannot be migrated, the private portion of the key is
  never exposed outside the TPM.

  Computers that incorporate a TPM can also create a key that has not
  only been wrapped, but is also tied to certain platform measurements.
  This type of key can be unwrapped only when those platform
  measurements have the same values that they had when the key was
  created. This process is referred to as “sealing the key to the TPM.”
  Decrypting the key is called unsealing. The TPM can also seal and
  unseal data that is generated outside the TPM. With this sealed key
  and software, such as BitLocker Drive Encryption, you can lock data
  until specific hardware or software conditions are met.

https://docs.microsoft.com/en-us/windows/security/hardware-protection/tpm/tpm-fundamentals


Differentiate normal flow and broadcast attacks

You'll want to capture the packets with a sniffer, such as Wireshark, and look at the payload and source addresses, and see if it is expected traffic.


What are possible approaches and arguments for securing corporate IT systems with most computers being portable?

Trust nothing.  All mobile devices should be placed on their own network segment,  which is doesn't have access to the entire infrastructure.  This untrusted network should be treated no differently than the open internet.  Make sure you expose only the services that are needed to this untrusted network.

Make sure all mobile devices have anti-virus software.  I am still skeptical of anti-virus software for phones.  Make sure devices are updated regularly.


The SSID is more about identification of the network, not authentication.

Wireless authentication is done usually in either of these 3 ways:

Open System authentication: no authentication done
Shared Key authentication: Done with cryptographic handshakes between client and AP based on some shared secret - of course trust is on the assumption that the key is shared only between these two parties. In WPA/WPA2 there is mutual authentication, in WEP only client authentication is done.
EAP authentication: Using a radius server, different ways it can be done, can be based on certificates etc, no need for one shared secret for everyone. Mutual authentication is usually done.


Single sign-on models for a mixed environment

If you try to implement a SSO system you have to distinguish two fundamental different solutions:

Server side SSO: in this approach every server application must use a central authentication system like a LDAP or it must trust some kind of ticket like in Kerberos or SAML or the authentication must be done with some kind of certificate.
Client side SSO: in this approach you have to use some kind of client software which automates the authentication process.

The advantage of Server side SSO is, that it can be implemented in a way that it gives you more security like a simple password authentication. But every server must be able to join the SSO system. In some cases this is technological complicated (SAML for graphical user interfaces other than the web browsers) and for legacy applications this may be a show stopper.

In those situations you have to use the client side SSO where some kind of software handles the authentication by sending login and password credentials to the input fields of the legacy application. This approach has a phishing weakness, because it is difficult for the client to trust the server, because a login window can only be identified by some kind of window title which can be easily hacked on every windowing system.

Rule of thumb: SSO in heterogeneous networks is complicated and very expensive.


The source explains an overarching concept and is perhaps slightly ambigious rather than outright misleading. Hashes sent alongside data in their "raw" format are definitely susceptible to a tampering attack and, therefore, we need to either:

Share the hash value out-of-band: A simple example is downloading a file off a website which shows the file's hashsum on the web page next to the download link (the out-of-band channel here is the web page content being served within a different communication channel or even better served by a different web server). Once you have successfully downloaded the file, you would calculate the hash of the file independently and compare the hash to ensure integrity. This is a common practice for critical files such as an operating system image.
Authenticate the hash sent along with the data: this is done by using what is known as a Hashed Message Authentication Code (HMAC), which provides both the "integrity" and "authenticity" security services to your message.  There are a lot of detailed answers about this topic here.


SASL Authentication Protocol with No Cleartext passwords

There are two mechanisms used to authenticate an LDAP session:

simple
SASL

The simple BIND mechanism takes one of four forms:

anonymous - null name, null credentials. This is the initial state of a session.
unauthenticated - non-null name, null credentials. Directory servers should be configured to reject this request because no authentication takes place.
name/password - name, credentials
undefined - null name, non-null credentials. The behavior of the server is undefined by the LDAP standards. Directory servers should be configured to reject this request because no authentication takes place.

When an LDAP client connects to directory server, that connection has an anonymous authentication state. The client can request the state be changed by using the BIND request. The BIND can also "reset" the authentication state to anonymous.

The recommended authentication method is simple BIND using either a secure connection (SSL) or a non-secure connection promoted to a secure connection using the StartTLS extended operation. Modern, professional quality directory servers support strong cryptographic hashes of salted passwords to make the construction of dictionaries difficult.

Another method is the SASL GSSAPI mechanism, which avoids transmitting the password altogether.

Another method is the SASL EXTERNAL mechanism, which uses information not provided by LDAP, for example, the client certificate presented during establishment of the secure session.

Another method is the SASL DIGEST-MD5 mechanism which avoids transmitting the password but has the disadvantage of the requirement that the server must have access to the clear-text password or be able to decrypt the user's password, which means using a reversible password storage scheme. DIGEST-MD5 should be avoided for this reason. If DIGEST-MD5 is required, AES might be the best block cipher.

CRAM-MD5 is weaker than DIGEST-MD5, and should be avoided.

see also

LDAP: Authentication Best Practices


Use OpenID Connect for authentication and custom authorization

The flow you are describing is exactly why OpenID Connect exists. It standardized a way to authenticate a user on top of OAuth2.0, which is simply an authorization protocol. That way you can simply do an identity check.

You're confused about the authorization part. What you want to do is not to separate the identity provider and the authorization with OpenID Connect itself, but rather use OpenID Connect only for the authentication part.

Pretending you're using Google to authenticate and that your own application handling authorization is called Melon, your flow would use 2 separate steps:

1. OpenID Connect: Perform the authentication with Google and receive user information (in form of an id token). At this point, you know that Google authenticated the user.

2. Melon: You now know that the user is authenticated and you have access to his information. You can now use your own authorization schemes to make sure the person can proceed with the request in your system. Of course, you need a way to associate the Google user to your system.


Is CSRF prevention logic required for api that is consumed only by mobile app?

A CSRF attack can only be done with requests with those three http request content types: application/x-www-form-urlencoded, multipart/form-data and text/plain. If your end point checks the request content type and makes sure it is not one of those three, that end point is protected from CSRF. So if you make the request content type be something like application/json, and you check that in the code (not just parse http request body using a json parser but actually verify the http request content type header), then you're safe. For existing deployed APIs with clients you do not control, maybe you won't be able to do this.

Another good protection, if you need to allow cookie authentication, use SameSite: Strict cookies if you don't need to allow cross origin requests.

If the end point you wish to protect doesn't do anything without authentication and only accepts authentication using a token, not a cookie and not http basic auth, then a browser doing an AJAX request from code on a malicious site won't be able to perform an authenticated request, and that is also a complete defense against CSRF. This seems to be your case.


UUID of type "v4" are supposed to be generated with 122 random bits:

o  Set all the other bits to randomly (or pseudo-randomly) chosen
   values.

However, it is not said that the said bits must come from a cryptographically secure PRNG (section 4.5 recommends it but does not mandates it).

IF the 122 bits indeed come from a secure PRNG, then they are immune to exhaustive search, because such a space is waaaaay too large for practical exploration (see this answer for more details). Adding bcrypt is thus just wasted CPU and gratuitous extra complexity, which is never a good thing, especially in security.

If the 122 bits are not produced by a secure PRNG, then you have a problem. It is conceivable that bcrypt might somewhat mitigate the issue, in the same way that bcrypt is good at tolerating passwords, which can only be described as "low entropy keys". But it really depends on how insecure the said PRNG is. A PRNG "security" relies on its unpredictability; here, "how much" the attacker does not know the 122 bits. If that "how much" is really low, then bcrypt won't save the day.

So my opinion is that when bcrypting an UUID is appropriate, then the UUID is not appropriate for use as a secret key, and you should fix that instead.

As for the "3 extra bits of randomness", this looks confusing, or confused, or both. I have no idea where that idea comes from.


OpenVAS is not being used; that name is arbitrary, and perhaps a red herring, or a nose-tweak of people analyzing it (such as yourself).

This is an example of the shellshock bug which was very big news four years ago. Use the search box to find dozens of Qs about it here on security.SX and nearly as many on unix.SX and serverfault. This example is clearly aimed at a CGI server, and causes it (if vulnerable) to output a simple HTTP response containing the output of the id command, which is harmless in itself but demonstrates unauthorized execution on the target which could have been used to do much worse things.


Found a few presentations by googling. Maybe some of these may help or get you started. Most android devices are ARM based so resources on ARM assembly/ shellcodes may also be useful. Hope it helps some.

Popping Shell on Android

Shellcode on ARM


Can the photos/videos I deleted a year ago can still be on my iPhone or on the Internet?

Once a photo/video is uploaded to iCloud or Google Photos, does it stay in their servers forever even after I deleted it

One can never be sure. They may have backups (I really hope so) that are kept for long time. What is deleted from the live system still stays in backups. They may have bugs in the trash-purging procedure. Whatever. In the general case, an ordinary user will not capable of accessing these obscure copies. Then again, data breaches do happen.

  certain forensic tools that can recover data from iPhones. Can they recover the data that was deleted from the phone more than a year ago?

It depends. The storage space in these devices is constantly reused and once a certain space is marked as free, it may or may not be overwritten. If your iPhone is, say, 32GB and you did save nearly 32GB (and got the storage full), you have some degree of confidence that the data you deleted before is overwritten. But you can still not be sure. These storage devices have spare blocks that are sometimes exchanged to active ones, so your data may have settled in some spare block. There are other possibilities, too.

  What advice would you give to continue my life being not worried about such things? It is definitely affecting my daily life.

Whatever you do now, it will not affect the possibility of someone abusing your personal information that you don't control anymore.

Don't worry. The probability of someone recovering your data is fairly low (except if you are a celebrity, a high-rank business or government official and the attack is targeted at you personaly). Most of the thieves just sell the phone to someone that is interested in the phone itself and the first thing they do is to wipe the phone clean. They have to in order to minimize the risk of the stolen item to be tracked back to them by the law enforcement or by a capable victim.

And you cannot do much by worrying anyway.

Learn the lesson - the phone has encryption functions, designed exactly to mitigate these risks. In the future, either learn to use them, or don't put sensitive information on your phone.


Is it possible to get XSS without event handlers inside  Payload?

Did you try other payloads for XSS?

Here's the cheat-sheet: https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

You can check the Event, Compatibility, tag as well as code there.

If 80% percent were blocked by WAF, you need to bypass it, some bug bounty hunters already bypass some WAF and here's the link:

https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/xss.md

For the browser, just test in all browsers.


VM escapes are typically local exploits in that they already need native code execution capabilities to talk to local virtual devices of the guest.

I believe the most convincing way would be to chain this together with a remote exploit, such as one for a browser. Open a Meterpreter session via the browser exploit, then you can use any local exploit from remote to perform privilege escalation or even VM escape. This tutorial summarizes the commands pretty well:

https://www.offensive-security.com/metasploit-unleashed/privilege-escalation/

Please note that CVE-2014-0983 is a memory corruption exploit, so you have to set up your test environment to precisely match the exploit target ("VirtualBox 4.3.6 / Windows 7 SP1 / 64 bits").


How to make a secure communication between UHF reader and UHF RFID Tag?

can we make a readable object, from any state, more secure?

You need an RFID tag that uses a challenge-response protocol. The reader would send a challenge key and the card must return a cryptographic signature of the challenge key, without ever exposing the secret signing key itself in the transmission. The card should then be designed with physical tamper resistance to make it difficult, if not impossible, to extract the key from the card without damaging the card.


Using MFA to connect to windows shares on domain controller

That's a really great question. My guess is that to allow this you must be trusting domains between the CDE and non-CDE, in which case I’d expect the admin to have logged in initially using MFA.

But it is a great question and I’d actually encourage you to submit it to the PCI SSC - I don't expect you will get a quick answer but it is the sort of question that would generate an FAQ in due course.


Need help with decrypting the "client key exchange" captured in Wireshark

First, before actually answering, I hope you do know that Wireshark can do all the hard work for you in this case (plain-RSA key-exchange and server privatekey available). Just go to Preferences / Protocols / SSL and give it the (clear) privatekey file and it will do the key computations and decryption.

If you want to understand a protocol, looking at the specification of that protocol (when available and IETF ones are) is usually a good idea. Note that SSLv3 is showing its age, most recently with POODLE (see several dozen recent questions), and you really should use TLSv1.1 or better (also addressing BEAST).
Under ClientKeyExchange we find:

5.6.7.1. RSA Encrypted Premaster Secret Message

   If RSA is being used for key agreement and authentication, the client
   generates a 48-byte premaster secret, encrypts it under the public
   key from the server's certificate or temporary RSA key from a server
   key exchange message, and sends the result in an encrypted premaster
   secret message.

        struct {
            ProtocolVersion client_version;
            opaque random[46];
        } PreMasterSecret;

   client_version:  The latest (newest) version supported by the client.
      This is used to detect version roll-back attacks.

   random:  46 securely-generated random bytes.

So your RSA-decrypted value is the premaster secret, and is for SSLv3 although you didn't say so. For any key-exchange once the premaster secret is established, you use it along with both Hello.random values to derive (compute) a master secret as described in 6.1. Asymmetric Cryptographic Computations
and then use the master secret with the nonces (which will be new nonces in the case of session resumption) to derive the working keys and if applicable IVs, plural, as described in 6.2.2. Converting the Master Secret into Keys and MAC Secrets.

Note in TLSv1(.0) and 1.1 the key derivation functions are changed to better mix MD5 and SHA1, the first more clearly named 8.1. Computing the Master Secret and the second moved forward to 6.3. Key calculation but both share a PRF moved to 5. HMAC and the Pseudorandom Function. Further in TLSv1.2 the KDFs are changed to use SHA-2.
Also note the "export" ciphersuites used a modified KDF in SSLv3 and TLSv1(.0); in 1.1 and 1.2 these suites are officially deleted and the modified KDF with them, but some implementations may still allow them (but if they do you shouldn't use them).


CVSS3.0 impact score and exploitability score

The CVSS calculator on NVD has a button "Show Equations" which, as you would expect, shows the equations for the various values including impact and exploitability.

The issue with the base score in this instance is that when dealing with a loss of confidentiality the equation doesn't take into account the sensitivity of the data that is disclosed.  Is it salted and hashed passwords?  Unhashed passwords?  Or the specific implementation of a web server?  It matters when assessing risk, but isn't taken into account by the score.

So, now it depends on why you're calculating the score, are you getting a CVE?  are you trying to access risk?  Or something else?  If you're trying access risk then use the base score as a guide and adjust as you believe appropriate.

To be honest I don't see this as a vulnerability as the banner information in and of itself cannot be directly used to attack the software, though it can be used to more easily find attacks.  We use Nessus to scan our products for issues and Nessus reports banners being available as "informational" for that same reason.


Is a donate button on a http only site insecure?

The problem with having a link to an encrypted site (https) from an unencrypted (http) one is that if someone could "man in the middle" the cleartext (http) traffic they could change which link you go to.

More importantly in the case of your PayPal button, an attacker could send you to a fake website where they copied all the current PayPal HTML for look & feel but then use that to collect username/passwords or otherwise gain access to you clients accounts. Fake websites like this which harvest user credentials have existed for years.

In this case, the risk isn't to PayPal so much as it is to your clients and your clients PayPal accounts.

This said there are a number of easy options to encrypt the page hosting your PayPal button, or it's equivalent.


Will using CTR mode with unique IVs, but only one password for encrypting multiple files, leak data or keys?

No, using different salt (IV) under the same key doesn't leak information. The problem with the CTR mode is the IV-reuse under the same key. Since CTR mode turns a block cipher into a stream cipher, re-using the IV with the same key will produce the same output stream that is similar to the reuse of One-Time-Pad (OTP). As in the OTP key is reuse, the information can be extracted with crib-dragging techniques.

There are better alternatives to what you are trying. There are Authenticated Encryption (AE) modes like AES-GCM and ChaCha20-Poly1305. AE mode ciphers can provide you Confidentiality, Integrity, and Authentication all-in-one. TLS version 1.3 has these algorithms in the standard.

With AE you don't need to provide two keys. If you are insisting to use HMAC, you can use a good Key Derivation Functions like Argon2id. By providing different salts you can derive two different keys.

Encryption, in general, doesn't protect the plaintext size ( if padding is applied the output size is always multiple of the block length in block-ciphers, which is not a case for CTR mode). The input size equal to the same output size plus IV and tag those sizes are known to the attacker. One way to mitigate, you can add some random characters at the end of the files. That must be uniquely removable like paddings. This can be helpful if you cluster the file into groups i.e make the size fixes length at some intervals.

Breaking the CTR mode with Known-Plaintext Attack (KPA) is equal to Breaking AES. Apart from the side-channel attacks, cache attack, power attacks, we believe that AES is KPA-secure. Since the attacker cannot access the key, they cannot find the password in this way.

The password, on the other hand, must be strong against the brute-force attacks. This may be the weakest point of your system.

If you consider only securing your files, there are already good alternatives for you; VeraCrypt. With VeraCrypt, you can create an encrypted volume and you can store your files in it. From your password to encryption/decryption of the volume are all handled for you.
It is cross-platform, and you can access your files from Windows/Linux/Mac. You can find some third-party for your mobile devices, too.