How to make a file detected by anti virus I know this question is kind of stupid but I am testing a virus database and I would like to know any kind of code in c++ or C#/VB.net that would be detected as virus by an antivirus, without actually having do download an antivirus.

Thanks.

There is a standard file treated by all AV software I have used - the EICAR test file but this is used for testing the deployment and integration of a malware scanner, not its database. The only practical way to test the latter is with a very large number of live viruses.


Would placing a hardened virtual machine in a VPS provide more security? I have been working with DigitalOcean for a while now and while I do like that they make it easy to start up with a fully functioning virtual machine ready to go. It makes me cringe a little though that I have to trust that nothing was tampered to work with their systems. If they did an install with you in the beginning that was mirroring an authenticated iso from the open source community, I wouldn't mind as much but this grey area leaves me unsettled.

I know they have their incentives to do well and that's fine in the terms of a base system. I'll even give them the credit they deserve for writing some of the best security guides I've ever read.

But, as I take steps down the computer security rabbit hole I find myself understanding more and more that the only way to truly have good security, is to trust no one.

While I can and always will follow best practices to harden the systems they are handing me to work with to make them as restrictive as possible, I am tempted to put the actual services in internal VMs that I know are running on operating systems that have been hardened to the best of my abilities in order to create an isolated sandbox where the processing can actually happen.

My question is, will using a textbook hardened and verified operating system in a VM inside an OS that cannot be defined as a "trust no one" system provide additional levels of security to make it possible to be a "trust no one" system again? Or is a VM not able to be any more secure than its host?

With the security concerns that still come with services like docker I am definitely still going to use VMs for instant rebuilds and isolation of mishaps but I would love to hear what everyone has to say about this now that VPS's are so cheap and easy to use.

Whether using a VM is more secure or not depends what you are protecting yourself against. If you fear that DigitalOcean may be trying to spy on you, illegally gives access to your system to hackers, or many other malicious activities, there's little you can do to protect against it. No matter how secure your VM is, they control the hardware and OS that it is hosted on. So they can install keyboard loggers, steal private keys and passwords from memory, etc...

On the other hand, if you're concerned that DigitalOcean monkeyed with the OS and somehow made it less secure, then running on a VM might help. It will depend whether whatever they did is still vulnerable when a VM is being used. For example, if they made some mistake that includes malware that allows a remote root shell on your VPS, then there's little that you can do to protect against that. But if they're mistake is only exploitable if you are running a web server on the VPS, then perhaps the VM will help.


Is bcrypt suitable for modern use? When the subject of password hashing comes up, a lot of developers get exasperated by people using outdated, broken, or hand-rolled hashing schemes, and I frequently hear "just use bcrypt!" repeated like a mantra.  But when I mentioned this to another developer recently, he said that bcrypt is based on Blowfish, whose author has been recommending that it be discontinued for at least 6 years now.

In the article, it appears that he's talking about Blowfish encryption, which I know is a completely different thing from password hashing, but on the other hand, you can't build a solid house on a shaky foundation.  So I have to ask, is it still a good idea to use bcrypt?

The suitability of blowfish as a cipher and bcrypt as a password hash are mostly unrelated. There are many better replacements for blowfish, but not so much for bcrypt.

Blowfish is mostly discouraged because it has a better replacement in AES, not because it's broken. AES has seen a lot of analysis, during and since the competition. Another problem with blowfish is its 64-bit blocksize, which leads to relatively small limits on how much data can be encrypted using one key, whereas AES uses 128-bit blocks and can thus safely handle larger amounts of data. It also has some annoying properties, such as a slow key-setup and relatively high memory use.

PBKDF2-HMAC-SHA-1/2/3 is significantly weaker than bcrypt, so I'd only choose it if you need standard compliance or if your language only ships it but not bcrypt by default. The underlying hashes may be secure, but that doesn't make it a good password hash.

As a modern replacement for bcrypt, the only currently feasible candidate is scrypt. It offers improved security, but it's relatively new, not very popular, and hasn't seen much analysis. It hasn't been included in many standard libraries yet either. So more conservative cryptographers will prefer bcrypt over scrypt.

A competition to find a new password hash resulted in a few interesting alternatives, such as its winner Argon. But I don't consider these suitable for production for another five years or so. Perhaps in 2020 we might have a similar opinion of bcrypt as we have of blowfish now, but we're not there yet. For now bcrypt is a good choice if you're conservative, or scrypt if you're progressive.


MAC filtering the internet traffic? I was trying to build a firewall where in the access to my LAN from internet should be allowed only if it matches the predefined MAC address of the device i.e,. MAC filtering, but later i found out that MAC filtering is not possible for the traffic coming from the internet, since it changes the MAC address of a packet for every hop(This is my understanding as far as i have read on the internet,please do correct me if I am wrong), please do suggest some alternative or solution, so that the traffic from only predefined MAC addresses are allowed to access the LAN.
I tried experimenting with linux's utility iptables
Any suggestions and corrections are greatly welcomed:-)

As others have already noted, filtering by MAC doesn't work because MAC addresses are not routable, only IP adresses are.

Filtering by MAC address wouldn't really work, anyway, because MAC addresses can be easily spoofed (changed). I can give my computer the same MAC address yours has, and as long as they're not on the same network segment, everything continues working just fine, except that if there was a way to look at the MAC address of a request in a routed network, I'd now look just like you.

What you can do is filter IP addresses by IP address block. There are services that provide geolocation services based on IP addresses; usually whole blocks of IP addresses are assigned to specific institutions. So you could in theory lock out anyone from china by blocking all IPs registered to chinese internet providers, chinese firms etc.

This won't be foolproof, however, because a) the geolocation lists are never perfectly accurate and perfectly up to date, and b) there are services such as proxies, VPNs and anonymization networks which can hide the actual origin IP of a request.

You'll have a bit more success if you whitelist IP blocks. For example, if you want people at your school to have access to your network service, but nobody else, you can whitelist the IP block assigned to your school.

But again, you should only consider this a first step. It also doesn't allow you to grant access to individual persons; IP addresses for the most part can't be reliably tied to people.

So if you really want to only allow specific persons / computers into your network, you'll have to secure it with an authentication and authorization step. For example, you could set up your own VPN and hand out access credentials to only those people whom you want to be able to access it.


Is USB type c vulnerable to BadUSB? Consider the new SanDisk ultra dual type c flash drive. Would that be safer once computers start to come with type c ports?

USB C is just a different physical port standard. It implements the same USB 2.0 / 3.0 interface. BadUSB revolves around reprogramming the USB micro-controller to act as a human interface device and input commands when it is plugged in. USB C is as vulnerable as any other USB port standard.


how are symmetric keys generated in TLS My confusion stems from reading that TLS handshake uses some kind of Diffie Hellmann, when I was certain that the symmetric key was generated by a digest of earlier packets encrypted with clients public key and safely decrypted with servers PK.

This does not strike me at all as diffie hellmann? Can somebody walk me through the correct process and explain why it is/is not DH?

My confusion stems from reading that TLS handshake uses some kind of Diffie Hellmann, when I was certain that the symmetric key was generated by a digest of earlier packets encrypted with clients public key and safely decrypted with servers PK.

The key exchange is used to generate the symmetric key (or at least the pre-master secret which the keys are derived from). There are two major types of key exchanges: Diffie-Hellman and RSA key exchange. What you refer to in the first part is Diffie-Hellman, what you refer to in the second seems to refer to RSA key exchange, although with many details wrong. RSA key exchange is considered obsolete and is no longer supported by TLS 1.3.


Are Https-only cookies vulnerable to CSRF attacks? Given the hypothetical situation:

A user logs into his banking website
The server returns a Http-only cookie containing the user's id, encrypted.
On each request (such as when transferring funds), the server decrypts and checks the id.

No CSRF tokens are generated on any of the forms, and request validation is based on the encrypted id.

Is a CSRF attack possible under this scenario?  If so, how would it work?

Yes, CSRF is still possible, and it works the same as CSRF would normally work.

The HTTP-only flag is useful for protected a cookie from an XSS attack which injects JavaScript to try to read the cookie and send it back to the attacker. For protecting against CSRF attacks, it is completely useless.


Are user-provided translation strings an attack vector Twitter and various other web companies allow users to help translate the user interface into their language.

  Crowdsourcing translations isn’t new for us. Since October, 2009, we’ve counted on Twitter users to volunteer as translators and help us localize Twitter.

An HTML template then probably substitutes delimited primary language strings with those from the output language.  Since the output language strings come from an untrusted source, they could contain a payload to exploit an XSS vulnerability, or, if the results show up in feeds, an XML entity attack or the like.

Does anyone know whether such attacks have shown up in the wild?

They obviously need to be sanitized/encoded. But I don't see how it is more vulnerable to XSS and the like than other user supplied data.

I'd worry more about messages that mean something different in that other language being substituted. That could be used for social engineering, or to lower the reputation of your website by inserting inappropriate or insulting content.


Is it better to choose less-vulnerable random password? I have created a random password generator function (which can be found here if anyone wants a look), which will churn out passwords with a random mix of letters, numbers, and other characters. This question and it's answer suggest that I should select the first chosen password because otherwise my passwords become more predictable based on what I like. But theoretically what if one came out with only letters or only letters/numbers or only one special character. Should I then generate another password or am I losing entropy? I feel as if the first password would be vulnerable to wordlists, but not using it technically makes my passwords more predictable. Is there is good place to draw the line?

P.S. Unlike that other question I do not care how hard these passwords are to remember.

In general

This depends on what information you are asuming that the attacker has.

First, let's asume that the attacker is blind, and perhaps trying to crack a large dump of breached accounts, without knowing that you used that specific algorithm. Then you would be better protected if you discarded 123456 if it comes up, or more realistically, passwords that are only lowercase, dictionary words, etc. This is for the simple reason that any attacker is bound to try those first since in general they are more common.

On the other hand, if the attacker knows that your algorithm was used, discarding passwords will only make her job easier. If you dump 10% of the passwords, that is 10% she does not have to try, saving her 10% of the time on average.

So which one of these two scenarios are more likely? I would say the first one in most cases, but only you can determine what your threat model is.

A mathematical example

Let's do some math to see how many passwords you would actually drop. Let's say that characters are picked from three groups (upper case, lower case, numbers + special characters) and let's say that there are an equal number of character in each group. Furthermore, let's say that you require passwords to have at least one character from each group. What fraction of passwords would you drop?

If I get my math right, it is 3*(2/3)^L where L is the length of the password. For L=10 you get 5%. For L=20 you get 0.1%.

Unless you are completely sure that the only threat is an attacker that knows how the password was generated (I find it hard to imagine how you could be that), I would say that reducing the search space by 0.1% is worth it.


Overwrite File in Browser Cache I heard about a security incident where someone had accidentally placed sensitive information inside a cached JSON file. I was wondering, for the purpose of containment, what is the best way to force clients to overwrite this file so that the sensitive information is no longer available.

Would something like a Cache-Control: no-cache, no-store, must-revalidate followed by a new definition of the same cached file result in the existing JSON file being overwritten.

Looking forward to ideas and suggestions. Thanks.

Would something like a Cache-Control: no-cache, no-store, must-revalidate followed by a new definition of the same cached file result in the existing JSON file being overwritten.

No, because, if it is in the browser cache, and still cacheable, the browser won't fetch it. It is possible to force cache-busting by loading the content in an iframe (i.e. not via ajax) then performing an explicit reload (not refresh). The initial load will come from the browser, but (in most cases) the subsequent reload will fetch from the origin. However this does explicitly mean that the cache entry will be removed. Depending on how the cache is implemented, it may simply be flagged as stale for later garbage collection. This does mean that the cached data won't be accessible to the browser.

To be sure of removing the data you would need to delete the entry (or entire cache) from the filesystem.

But the data would still be recoverable - deleting a file on most filesystems just removes it from the directory and makes the blocks available for re-use.

To be sure of removing the data you really need to overwrite it several times.

Oh, wait a moment, on some filesystems that just creates new versions of the file.

So, really you need to erase the data, smash the disk to pieces using a large hammer then melt it down to slag. What was the question again?


Is it practical and/or secure to get my friends to remotely sign my OpenPGP public key? My best friends would trust who I am and I would also trust who they are, without looking at our government-issued IDs. We went to the same schools and same classes for many years.

However, they now live on the other side of the planet.

Is it practical and/or secure to get them to sign my public key, via something like a live video chat where I read my public key out-loud to them?

Would this have been good enough before recent advances in audio and video synthesis?

Are there still other ways to prove my identity remotely, without resorting to shared secrets from the past when we still lived in the same city?

There is no definition on how you have to verify identities for OpenPGP certifications. This is completely up to you -- some people define a certification policy because of this.

Whether to accept a video chat or not depends on the policy of the certifying side. I would still not expect an attacker being able to render photorealistic video footage in real-time; so embed the key exchange in a conversation, or include multiple persons and for example hand-writing the fingerprint while reading to a whiteboard. Additionally, the paper referenced used many hours of high quality video footage for training -- would you expect this to be available at all? Finally, is an attacker with such powerful computing resources and capabilities available that would risk being observed in such an attack?


How to generate a batch file with msfvenom? How do you generate a batch file for windows .bat using msfvenom, msfvenom does not seem to have a batch file like format and is it possible to convert a .ps1 to .bat file

A .ps1 file is a PowerShell script: unlike .bat and .cmd it's executed in Windows PowerShell instead of the Windows cmd.exe. While it's possible to "convert" a PowerShell script into a batch script that calls PowerShell, the requirement for the PowerShell framework remains.
If that's what you are looking for, for a longer script like the one produced by msfvenom, I'd suggest the method explained in Dmitry Sotnikov's PowerShell script in a .bat file:

Put the code inside curly brackets and assign it to a variable.
$code = {
    # code here
}

Base64 encode it with PowerShell:
[convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($code))

Use it in your batch script with powershell.exe -EncodedCommand


Can a hashing function be implemented insecurely? After working on a an imaginary security related project, it was decided that the project is going to use the imaginary hashing function X.

There are various implementations of the hashing function available as packages, all varying in terms of adoption rates and popularity.

Given that any package returns correct hashes for a small amount (n=10) of test cases, are there any serious security implications that could occur? My understanding is that a hashing function should return a irreversible value, and given that any implementation does this correctly, they should all be equally working & therefore secure.

Right?

Unlikely
First of all, the implementation of a hashing function could be faulty in terms of software engineering. That doesn't mean the implementation is insecure per se, but means that you are not returning the expected values according to the specifications.
N=10 test cases is a ridiculously ridiculous amount of testing to certify that a hashing function is ready for production. I am currently speaking about software engineering, not yet security
A concrete example

sha256("Hello Stack") equals 433247cccfd4105b7b60e810e372f3850ba4e518eb5fb0474e198228ddaabf65

Wherever in the world you are, that is the universal hash of that string. The security properties of sha256 are defined in the hash's specification.
If you have a faulty implementation, then it will have to return something necessarily different.
Now suppose for a second your sha256 does the following

yourSha256("Help Stack") equals 433247cccad4105b7b60e810e372f3850ba4e508eb5fb0474e198228ddaabf65

That's basically not sha256, because the correct value is 74aec9297f627396b3914f1a58213dada3ec30b0ed0cc5dafb029d0f326e2ec7
What I am saying is that in the world of hash functions, the properties of uniqueness and randomization have to be demonstrated at specification level, and they apply to the hash's specification. Any code that returns value other than the expected hash is not a correct implementation of the hash.
A bug comparing the hashes
So you have function H(x) that is deemed secure. I won't discuss further. Then you have two implementations org.acme.H (yours) and com.initech.H (another vendor's).
You must integrate two systems so that they compute and exchange hashes.
H is secure by definition, but Acme is faulty. That means on the 11th test case it is returning results different than Initech. That will mean whatever interaction between the systems will be inconsistent and/or failing. e.g. the two system use such hash to checksum a file, but since they yield different values they consider the file out of date.
So far, that's not a mere security problem
Exploitable faulty implementation
If you rely on that hash heavily and use it for security purposes, and have no other implementation from any other vendor, you might have vulnerabilities.
E.g. if your faulty hash code starts to return predictable values, an attacker can discover (part of) the plaintext after a number of similar-text attacks.
That is not a problem with the hash definition, but it's the binary code not returning the correct value. Simply because you are not using secure H(x), you are using trash(x) where trash is a brand new weak function.
Other considerations
Cryptographic functions are famous for timing attacks, where the amount of time to encrypt a block (emphasis mine) is variable and reveals info about the key. Hashing functions have the desirable property to take the same amount of time for blocks of equal length. It is worth to note that it is perfectly normal for a hash function to take increasingly time according to the payload size. Namely, the larger the file, the longer the time to hash it. Full stop!
Memory aging and leaked plaintext
I could imagine that a faulty implementation leaves traces of the original plaintext allocated in memory, without properly clearing these areas and returning them to the system. Combined with a buffer overflow attack, that could reveal pieces of plain text if not all.
But that is something unrelated to only 10 test cases. You won't find it with additional cases like assertThat(h(x),is(equalTo(precomputed))) or assertThat(acmeHash(x),is(equalTo(superTestedHash(x)))) which is a great way to test custom implementations
Consideration on timing attack
This is just a consideration. Suppose your correct-but-insecure-implementation of the hash yields a result so that the time it takes to yield it is related to the plaintext itself.
I quite don't see much security issue. Hash functions are public, so that you will run it on your machine. You have to know the plaintext before running it.
Compared to time attacks in crypto functions, the problem there is that you use the timing not to break the cyphertext or plaintext, but to break the key which is the other secret element. In hashing there is no key, so plaintext and hash digest are always known.


How to know if the response is from the CDN and not the origin? I am doing some bug hunting. I inserted a malicious payload into a request. But I am not sure if the response is from CloudFlare or the origin. Are there special headers which help me to distinguish the origin from the CDN? I always see the HTTP header Server: CloudFlare even if the response came from the origin. Why don't I see Server: Nginx?

I'm not sure how you're accessing the origin directly unless you're accessing the origin by using its IP. Once you point your domain name at Cloudflare, all requests go through Cloudflare.
Assuming you're accessing the domain name, the content itself did come from your origin even if Cloudflare is currently returning a cached response. You can see if it's a cached response based 'cf-cache-status' header (hit = Cloudflare cache, miss = Cloudflare had to make a request to your origin because it didn't have anything in cache).
You can also turn on Development Mode so Cloudflare bypasses cache.

Temporarily bypass our cache. See changes to your origin server in realtime.

Cheers.


How to analyze and pick a good crypto related lib I would like to know how one goes about analyzing and picking a cryptography related library. For example, today we have many TLS implementations, that use cryptographic primitives, for example: GnuTLS, OpenSSL, LibreSSL, etc... So how do we pick one?

How do you analyze the library? Do you check the source code?
What if I am not a crypto expert? Should I rely on the organizations behind those libraries?

I've been recently using crypto related libraries provided by GNU, basically because their are open source (which makes it possible for anyone to review the code), have a good documentation and because GNU's projects are in general trustworthy and reliable. What other parameters, besides the lib's track record should I take into account?

Evaluating external libraries is always a difficult balancing act. In many cases, the people performing the evaluation are not specialists of the library's primary functions (otherwise, they often wouldn't need to use a 3rd party library). This is even more true of crypto because expertise in the crypto implementation is rare, hard to acquire and hard to access.

Therefore, I'd give the following advises:

Do not bother with attempting to audit the code for security. Audit it for clarity, ease of use, capability and fitness to you needs.
Make sure that the people how will be using it will understand how to use the API properly. Most application developers have little or no understanding of crypto. Many do not even properly understand how much they don't know about the subject (hence the alarmingly common habit of writing "custom spaghetti code" as "encryption" function or hard-coding keys inside the source code). Make sure you're not going to require them to make decisions that they aren't equipped to make (like picking a bloc cypher mode of operation or selecting an IV).
Make sure the code is properly maintained, now and in the future. This is probably the most important point.
What is the library reputation and, perhaps more important, track record in dealing with past flaws ? If you can't find any such track record, stay away: the code is too new (or too obscure) to have been properly tested or the people maintaining it are actively discouraging such external testing (or even worse: they aren't doing much maintenance).
Try to avoid hard dependencies as much as possible: write your own interfaces to the code that you will program against instead of coding against the API directly. Hopefully, that should make it easier to switch library if it becomes desirable or necessary.

In the end, you're going to have to put some trust in the hands of some stranger. Best is to treat that as any other business relationship: trust but verify and always have a backup plan.


Name of this cipher/encoding method? I see a common method of encoding in PHP malware where there's some bytes of key, which gets used to decode that many bytes of encoded text. Decoded bytes get appended to the key on the fly. The decoding is subtracting the key byte from the encoded byte, modulo 256. It seems like this method of encoding would be prone to a known-text attack, since the cleartext ends up used in the encoding key.

What is this method of encoding called? I have absolutely failed to google up anything other than more examples of the algorithm in PHP. The method seems similar to Running Key Ciphers, but it recycles the cleartext. It seems like what I've called cleartext is often compressed (gzip, gzdeflate, etc) so that the "cleartext" is close to random bytes.

When I've seen it, the variables in the decoding function are obfuscated into $l__l_ or $g___g__, or variants with more or less underscores.

Here's an example of PHP malware that uses this encoding, if that helps.

The two variants of the algorithm I can readily find look like this:

$key = ...
$cleartext = ...
$i = 0;
do {
    $cipherbyte = $ciphertext[$i];
    $keybyte = $key[$i];
    $value = (ord($cipherbyte) - ord($keybyte))%256;
    $clearbyte = chr($value);
    $cleartext[$i] = $clearbyte;
    $key .= $clearbyte;
    $i++;
} while ($i < strlen($ciphertext));

A more compact form shows up sometimes:

$key = ...
$cleartext = "";
for($i=0; $i<strlen($ciphertext); $i++) {
    $cleartext[$i] = chr((ord($cleartext[$i])-ord($key[$i]))%256);
    $key .= $cleartext[$i];
}

I believe that for the encoding function (which I've never seen), the key would get composed like this:

$key = $seed . $cleartext;

So the length of the key is always more bytes than the cleartext.

What's this method of encoding called?

This is an autokey cipher. Even if the key is not available in the source code, it's still quite vulnerable to a known-plaintext attack. (Compressing the output is minimally helpful; most compression formats have a standard header which can be used as a known plaintext.)


How can the Equation Group HDD firmware malware help bypass FDE? There is currently a lot of discussion going on across the Internet about the "Equation Group" family of malicious hard disk drive firmware.

One thing that has me wondering is the claim that malicious HDD firmware would be able to access details on any running full-disk encryption scheme. For example, we have How the NSA's Firmware Hacking Works and Why It's So Unsettling, by Wired which states, in part (referring here to unused portions of the firmware EEPROM):

  “Taking into account the fact that their GrayFish implant is active from the very boot of the system, they have the ability to capture the encryption password and save it into this hidden area,” [Costin Raiu, director of Kaspersky’s Global Research and Analysis Team] says.

Maybe I'm missing something obvious, but I don't understand how this follows. There are two cases I can see here:

Microsoft Windows, with Bitlocker enabled. The firmware loader is apparently a Windows executable, and Windows is a common OS, so you could have some leverage with "out of the box" code.
Some other OS with FDE, say Linux with LUKS or FreeBSD with GEOM. These would, at the very least, be immediately unaffected by a Windows binary.

When using full-disk encryption, the storage device (whether HDD, SSD, floppy, or whatever) is tasked with safekeeping the encrypted bits. Certain headers are known to exist in different FDE schemes, do often contain key material, and can presumably be detected based on magic numbers or on-disk location, but the meaty parts are encrypted by the time they reach the storage device.

How can a storage device's firmware meaningfully subvert properly implemented full disk encryption, in which the storage device sees only encrypted data in READ and WRITE commands?

The only real possibility I can see is if the storage device firmware can somehow influence other parts of the system perhaps by exploiting DMA, but wouldn't the CPU's memory manager step in there? Or is DMA always done in supervisor mode (ring 0 in Intel terminology)? That would seem to open up a whole different can of worms.

Let's assume here a fairly typical FDE setup: BIOS or UEFI, handing off to a tiny unencrypted bootloader that prompts the user for a password and proceeds to initialize the cryptosystem state before going resident to intercept disk I/O and doing encryption/decryption as the data flows between the normal I/O layer of the OS and the storage device itself. All "one way or another", leaving technical implementation details aside unless they directly pertain to answering the main question.

This is equivalent to an evil maid attack, which compromises the (unencrypted) bootloader to capture your FDE password the next time you start your computer.

This assumes the bootloader is kept on the same drive. If that's not the case (for example if you keep your bootloader on a removable drive) and you explicitly configure your computer to not boot from the main hard drive (as to not execute potentially malicious code planted on it) then this attack won't work.

By default, with both LUKS and Bitlocker, a small part of the drive is kept unencrypted and the FDE-aware bootloader lives there and is executed on each boot; so the drive does more than safekeeping the encrypted bits. A TPM could help mitigate that by verifying the integrity (hashes) of the bootloader before giving out the keys, and Bitlocker takes advantage of that by default. For LUKS, there is no official support for TPM but some solutions exist like TrustedGRUB (for actually extending the chain of trust) and tpm-luks for saving and retrieving the LUKS key from the TPM.


Wireless LAN router fingerprinting Does anyone know of a database that lists the range of MAC addresses that are assigned to each particular brand of router?  I would like to use this information for fingerprinting.

I know I can find the manufacturer given the OUI of the MAC address, but I do not know how to find the exact router version.

For example I want to know which MAC OUI belongs to D-Link DIR-645.

I found something, but not quite what I wanted, since there are no assignments between MAC and actual device.

http://www.wardriving-forum.de/statistiken/hersteller/


NMap to scan a private subnetwork I have a test network setup based on virtual machines. My host machine, a web server and the firewall is under the 192.168.0.0/24 network (gateway is 192.168.0.1); a server machine is located behind the firewall on the 10.40.1.0/24 network (firewall eth1 is its gateway with IP 10.40.1.1). Please note that the firewall has no rules at this point.

How can I use nmap to detect/scan the server behind the firewall on the 10.40.1.0/24 network?

The NAT software running on the Firewall system is going to block all inward traffic that doesn't match a current egress session or a port forwarding rule. If no port forwarding rules are in place, then the server behind the NAT is as good as invisible, barring compromises to the firewall.


Cracking diffie-hellman public key to obtain shared key I'm given 2 prime numbers, g and n, as well 2 public keys, ga mod n and gb mod n, as part of a leaked Diffie hellman key exchange. I need to derive the shared key gab mod n using the given information. I understand that I have to find a and b which are the private keys first but have no idea how to solve it since it states online that it is a discrete log problem that is very hard to solve. What are the steps I should take?

A "hard problem" in cryptography does not simply mean that the problem is difficult to understand or complicated to implement, but that there is no known way to efficiently solve the problem in all cases. The discrete logarithm problem, which is the difficulty of finding x given gx mod p, is a hard problem. The Number Field Sieve is the asymptotically fastest known method to compute discrete logarithms. If x is large and random, p is a non-smooth prime number, and g is an appropriate generator (like 2 or 5), then even this fast algorithm will not be able to find x before the sun burns out.
See also Can you give me a summary of cryptographic hardness assumptions?


What Enhanced Key Usages are required for PKI infrastructure tasks? (OIDs for OSPF and CRL signing, etc) I'm building a constrained PKI that specifies EKUs for the the entire hierarchy and want to document the OIDs required for PKI tree maintenance tasks.

I understand that clients may not validate the entire EKU tree, just as some clients may not even check CRLs or OCSP URLs.  My intent is to create a baseline of infrastructure that I can use to test interoperability and document how 3rd parties validate (or don't validate) certificates used by CAs.

Question

So assuming a client will validate a CRL, OSPF, or any other certificate that pertains to PKI infrastructure maintenance, what OIDs should I include at my Root EKU to enable a baseline of support + SMIME?

For example, a few OIDs that may relate to PKI infrastructure may include the signing of a sub CA (if such an OID exists), and also Qualified Subordination.  However the issue I have is that all OIDs I can find fall under the Microsoft namespace of 1.3.6.1.4.1.311 or are simply listed on this web page.  Since Microsoft didn't invent PKI, I don't want to create interoperability issues by only including their OIDs... I would want to include IBM's or Oracle's (Java's) implementation on CA validation.

Sample answer

The ideal answer would include a list of OIDs (in any format) and a description of what it's used for in as much detail as possible.  The following is in "Capolicy.inf" format for Microsoft Certificate server, but all I care about is the information...

 ;OID = 1.3.6.1.4.1.311.20.2.1; Certificate Request Enrollment
 OID = 1.3.6.1.5.5.7.3.9;  OCSP Signing (Required for OCSP)
 ;OID = 1.3.6.1.5.5.7.48.1.5; OCSP signing (SHOWS AS UNKNOWN in some software)
 OID = 1.3.6.1.5.5.7.3.4 ; SMIME
 ; OID = 1.2.840.113549.1.9.15 ; On MSFT.com... Safari reports SMIME
 ; Should I include timestamping OIDs?

Also if there are certain OIDs that I shouldn't include then please include them as well.  For example the following appear to be controversial and may escalate a certificates rights unnecessarily

;OID = 1.3.6.1.4.1.311.10.3.9 ; szOID_ROOT_LIST_SIGNER
;OID = 1.3.6.1.4.1.311.10.3.1 ; szOID_KP_CTL_USAGE_SIGNING

EKU is Extended Key Usage; this is a certificate extension described in X.509 (RFC 5280), section 4.2.1.12. As the RFC says:

  In general, this
     extension will appear only in end entity certificates.

because, contrary to "Certificate Policies", there is no notion of inheritance and propagation of EKU along a certificate path. The EKU extension tells things about possible usages for the public key in the certificate which features the extension, and only that public key. As such, your notion of "Root EKU" does not seem to make much sense to me.

As a general rule, lack of EKU does not prevent things from running, except in a few cases:

The certificate for a delegated OCSP responder (i.e. when an OCSP response is not signed by the CA itself) MUST have an EKU with OID 1.3.6.1.5.5.7.3.9 (see RFC 2560, section 4.2.2.2).
The certificate for a Time Stamp Authority MUST have an EKU with OID 1.3.6.1.5.6.7.3.8 (see RFC 3161, section 2.3, which also insist on the presence of only that OID in the EKU extension, exclusive of any other OID).

For other roles, the presence of the EKU extension is not mandatory, but shall be honoured if present. See for instance S/MIME Certificate Handling, section 4.4.4: if the extension is present at all, then the certificate should be considered as fit for S/MIME usage only if the 1.3.6.1.5.5.7.3.4 OID is present, or the special 2.5.29.37.0 OID is present (this is the "any extended key usage"). But lack of the extension is considered equivalent to an EKU with the "any extended key usage" OID.

There is no "extended key usage" for CA or CRL signing (for these, the basic "Key Usage" extension is considered sufficient).

Some systems can have extra system-specific requirements. For instance, for Smart Card Logon in an Active Directory context, certificates on the smart card and the certificates issued to the domain controller itself should both feature the Microsoft-specific 1.3.6.1.4.1.311.20.2.2. Microsoft are total fans of EKU; they even devised their own extension ("application policies", apparently not documented) which duplicates the information from the EKU extension.


How can a OAuth2 resource server relate an access token to the user that authorized it to prevent unauthorized access to other user resources? I'd appreciate if someone could clear up if, according to the OAuth2 RFC, the resource server could infer the user associated to an access token or not, or even if that is expected.

Let’s assume the following:

The authorization server and the resource server are separated and
independent.
The client is a printing service.
The resource server hosts user photos.
The client wants to invoke a protected API from the resource server to get user's photos https://es/api/users/USER_ID/photos and print them.
The client redirects the user to the independent authorization server and ends up generating an access token.
The client uses that access token to get and print some user photos.

Since the token is opaque and has no meaning to the independent resource server nor the client, nothing would prevent the client from using that access token to access and print photos from any user, not only the one who authorized it.

Is this right? Or otherwise, how does the resource server relate the user to the token to limit its usage?

oAuth 2.0 does not have a build in mechanism to do this, however there are a few scheme's you could employ to make this work.

use an Authentication layer on top off oAuth (like openID Connect) to retrieve the user information you need
Add a scope per user details to access said user details and only grant that scope for that user. Just be aware of the information leaks that can cause.
Use the Authorization provider as gatekeeper and have it provide the requested details for that specific user not the resource server where the pictures are actually being stored. sort of a cop out but would also work.


How does a new SMS message overwrite a previous one? During a talk from a vendor, the speaker mentioned that their product used a "little known feature" of SMS in order to overwrite the last text message received from them. This feature was being used to send a one-time token, so it was quite useful. He didn't demonstrate it at the time, but I recently noticed that my mobile phone provider does the same thing with special offer tokens. Every time I receive a new token, it overwrites the old SMS message. I've since verified that this works on other phones - even really old ones.

I can see this posing a security risk. For example, someone might send me an threat, then have the second SMS erase (redact) the message later, leaving me with no proof. There are also social engineering implications.

What feature of SMS allows this overwriting? What security measures are in place to prevent this feature from being abused, especially in combination with SMS spoofing?

This is built in to SMS and is implemented in the Protocol Identifier (TP-PID):

  For MT short messages, on receipt of a short message from from the SC,
  the MS shall check to see if the associated Protocol Identifier
  contains a Replace Short Message Type code.

  If such a code is present, the the MS will check the originating
  address and replace any existing stored message having the same
  Protocol Identifier code and originating address with the new short
  message and other parameter values. If there is no message to be
  replaced, the MS shall store the message in the normal way. The MS may
  also check the SC address as well as the Originating Address. However,
  in a network which has multiple SCs, it is possible for a Replace
  Message type for a SM to be sent via different SCs and so it is
  recommended that the SC address should not be checked by the MS unless
  the application specifically requires such a check.

  If a Replace Short Message Type code is not present then the MS will
  will store the message in the normal way.

In the SMPP protocol specification this is REPLACE_SM:

  This command is issued by the ESME to replace a previously submitted
  short message that isstill pending delivery. The matching mechanism is
  based on the message_id  and source addressof the original
  message.Where the original  submit_sm ‘source address’ was defaulted
  to NULL, then the source addressin the  replace_sm command should also
  be NULL

And in EMI this is Type of Service 08, code 01:

  This Type of Service requests to replace a previously submitted
  message. It is only present when an update is requested. By default a
  message is assumed to be a new message.

The reason that this exists is so that services that send lots of SMS messages can avoid consuming the mobile phone's memory.  There is no security built in as far as I know; if you can spoof the source id, then you can tell the phone to overwrite previous messages from that same source.


Is opening an SQL server insecure? I need to be able to remotely modify my SQL database. There are two ways:

A PHPMyAdmin like interface (write scripts which will do it)
Let the SQL Server through the firewall (so it listens on the Internet)
Is hard as my (Windows) box doesn't support PHP

Are SQL servers hardened for Internet use?

PS.: I don't have SSL, so the passwords go in the clear anyway.

The following would probably be considered "okay" around here:

Add another NIC on your db server
Connect it to a distinct management network
Remotely connect to this management network using a VPN, with client IP restrictions.

PHP runs on Windows, however you should modify your database with change-log scripts, like with liquibase.


How can empty USB sticks contain malware? I read a BBC article about empty USB sticks containing malware:

  Berlin-based researchers Karsten Nohl and Jakob Lell said a device
  that appeared to be completely empty could still contain a virus.

How can "empty" USB sticks contain malware?
Is this only a problem for (legacy) Windows systems?
Is there some way to use these sticks while protecting yourself?

This question may seem similar to other questions  but those have not concerned empty sticks.

I'm afraid this stems from a misunderstanding from the reporter:

  ... said a device that appeared to be empty could still contain a virus.

In the video the reporter's referring to it is clear, in fact, in the first two minutes Karsen says he's NOT talking about viruses. He then goes on to demonstrate, on screen, that the seemingly empty USB device is changing itself into a different device (e.g. emulating storage as well as a keyboard and playing keystrokes), as was alluded to in my previous answer (below), but I had not at the time reviewed the full resource to establish it as conclusive evidence.

So there you have it, the author somehow misunderstood the video presentation, and BBC published it...

  How can "empty" USB sticks contain malware?

This question doesn't form a clear picture.

Firstly we must define "empty".

Do you mean unformatted? If this is the case, can we just erase the first sector to unformat a storage device, leaving the rest of the bytes intact?
Could there be viral code in those unerased, yet technically unformatted bytes?
Do you mean looks empty when inserted? There have been numerous tricks for hiding files in the past, such as storing them in the recycling bin, using the 'hidden' or 'system file' attribute, using NTFS streams or even unsupported partitions. Delving further down the rabbit hole, is the drive empty but encrypted? A flaw in a major cryptographic library (we've seen those quite a lot recently) could expose the system to covert side-channel attacks, even from a seemingly empty device... Additionally, some USB sticks are bootable (on some systems; we'll get to that later), implying that you might be able to write a boot sector virus to infect them. Boot sector viruses don't really care what OS is installed, since they execute before the OS boots anyway... This leads me to your next question:

  Is this only a problem for (legacy) Windows systems?

No. We should consider what constitutes "malware". It's possible for an arbitrary sequence of bytes to be considered malware because it causes damage to one system (e.g. x86/x64 machine code on an x86/x64 prcessor) but not another (e.g. the same bytecode on an ARM/SPARC). To answer this question, we only have to find (or design) a system that decodes the arbitrary sequence as malware, even though it previously wasn't.

  Is there some way to use these sticks while protecting yourself?

No. Finally, consider the definition of USB stick. Is it possible that, instead of plugging in a storage device, you might be plugging in some kind of electronic bug, such as a wireless keyboard adapter or a USB thumb killer. Such devices themselves don't really constitute malware, either because they're not software or they weren't designed to be malicious... though they could nonetheless be security risks. It might also be possible for a device to access memory (e.g. by appearing as a charger for your mobile phone and then stealing all of your photos, videos, etc using the data line or a covert wifi network).

Don't insert untrusted USB devices. Period. They might not contain malware, but that isn't the only danger... especially in this day and age where competition, electronic sabotage & surveillance are all the rage.


Superfish vs. Corporate MITM I work for a consulting company, and I have been implementing a tool from a security vendor, which is a cloud proxy for all user traffic. It will perform malware scanning and filtering of all web traffic. It works by enforcing a proxy autoconfiguration file to redirect HTTP/HTTPS traffic to one of the vendor's global data centers. We, of course, need to deploy certificates to each workstation in order to proxy HTTPS traffic and perform the MITM for malware scanning.

My question: how is this different from Superfish installing a root cert? I've been reading about how the private key for Superfish is stored on the machine. I assume corporate MITM attacks do not have this same vulnerability, but how does the architecture work differently in a corporate environment?

What makes Superfish, and similar products (all herein just referred to as "Superfish"), different from corporate MitM is that Superfish is doing the MitM on the client machine. Corporate MitM is performed on a separate server or appliance.

This is important because the system performing the MitM must have the private key of a Trusted Root CA in order to work. (Strictly speaking, the Root CA doesn't need to be trusted. But the user will see red flags if it's not.)

For Superfish, that means the key has to be on the client device - one which is notoriously not well-maintained and generally very vulnerable to attacks.

For corporate MitMs, the key is on the monitoring server - typically maintained by experienced personnel who perform regular maintenance and do not do things (e.g.: web browsing, downloading extra software, opening documents, etc.) that would expose the system to unnecessary risk.

However, all SSL proxies (corporate or otherwise) still need to be carefully implemented to account for the fact that they are removing the client's ability to self-validate the remote system's certificate. Particularly this means:

The SSL proxy must properly validate the remote systems' certificates and either appropriately warn the user or drop the connection entirely when something is amiss. As Charles Duffy mentioned in the comments, properly validating certificates also requires that the proxy does not trust its own built-in CA.
Ideally, the SSL proxy should also do some integrity verification against historical or community-aggregated reference certificates. This is implemented in some web browser extensions, and under normal circumstances can be manually performed by the user, to help detect fraudulent use of otherwise-trustworty Root CAs. Since the SSL proxy removes the user's ability to do this themselves, or to effectively use a browser extension for this purpose, it would be best if the proxy could do its own checking to compensate. (Though I doubt this is available in most corporate MitM products.)

Another thing you need to be careful about, since you mentioned that this service is provided to you by an outside vendor, is that the SSL proxy can see all of your users' traffic as if it was unencrypted. (That's the very purpose of an SSL proxy.) This means that data you would otherwise want to have protected from third-party viewers is going to be fully visible by the vendor should they choose to abuse your trust.


What is the boundary between Information Security and Quality Control regarding Integrity? I was in a recent dispute with the CIO regarding this (I work as an InfoSec Officer).

There was an issue when one of our devs published erroneous code in production due to user error (copy-paste sort of error).

This resulted in faulty software behaviour, particularly in displaying faulty financial information to customers.

The CIO asked me to take over this issue as this can be considered a violation of Integrity. On the other hand, to me this seems more like a Quality Control issue, however I cannot argue on the Integrity bit, plus this could easily be part of our Information Security Risk Assessment.

I would welcome your ideas and views on this.

I agree it's not really infosec, you're of course not staffed to review code yourself, or do QC yourself.    However, your skills and position should be fine to address the issue at a management level.  I would focus on the controls and let the CIO know you're going down this road.  Keep the investigation details confidential.

How did the code pass peer review?  Can they demonstrate that peer review (or your similar processes) were documented, people were trained and the processes followed?  Are they regularly asking their neighbour to "+1 me!" without a culture of actually checking?  Did dev have a post-mortem of the failure?  Do they have suggestions or new processes to prevent this from happening again?

Did QC have an automated test?  Why or why not?  Did it pick up the bug?  Why was it not part of their test coverage.  Will be be added to their test coverage?  When?

Check that the audit logs match the story of the developers and QC.  If the stories don't match, ask more questions.

At the end of it all, you should have a report with recommendations and findings.  The CIO can call a review meeting.  I would privately ask the CIO if you want to put fear into the leadership for this "breach".  If you're not careful about your documentation and curbing your language around your findings, of course your peers will hate you forever, but that's a dark side of internal investiigations in infosec.

IMHO, QC leadership should be asking these questions, but given they haven't stood up to take the issue, the CIO might not have confidence in that leadership.

All of this information should be retained as it may  be useful as evidence of your dilligence in investigating a security issue in code.  Review it with the CIO, clean up the excessive detail, add your remediation activities and add it to your records.


Master dataset of all recent password and hash leaks? There has been a recent spate of password and hash leaks from LinkedIn, Ashley Madison etc. Is there a dataset available online which is a unification of all such leaks (major and minor) aggregated together by frequency and source?

As mentioned by @Matthew in the comment, the site https://haveibeenpwned.com/ is probably your best bet.  It is run by Troy Hunt (a respected security researcher) who collects the various leaks and data sets, and lets you search to see if your account has been part of one of the leaks.  He does not make available the raw dumps.  He does, however, provide an API if you want to search his data set, suitably cleaned up, to be useful for researchers, without propagating exploitable data.

API page here:

https://haveibeenpwned.com/API/v2


Linux Privilege Escalation I've been trying to solve a box. I got into the box by exploiting a web app and got reverse shell so I was www-data. I then found an ssh key that I used to login as another user and I ran sudo -l which showed me which files I could run as root.
I'm struggling with what to do to use this to my advantage.

Without seeing what server.py does, I would suggest performing the following checks:
Do you have write privileges on server.py?
If so, simply edit it to spawn a bash shell as mentioned by ThoriumBR.
Do you have write privileges on python library path?
Usually they are in /usr/lib/python*. If for some reason the directory is writable and server.py import modules such as os, you can edit the module to include reverse shell commands.
Good luck!


Windows Honeypot user account for tracking laptop I've been wanting to create a dummy "Honeypot" user account on my Windows 7 laptop in case of theft.

My question is: Has anyone come across useful resources and tips for doing this?  Is there a way to have what "looks" like an administrator account with lots of goodies but hides the real stuff; like a sandbox?

The main idea of this is to deter a thief from just reformatting the laptop right away.  I imagine most thieves would boot up the laptop to see if anything interesting is going on, so having a user account with no password seems like a decent trap.

What I have been using so far is just a guest account with some interesting start up scripts that makes it easier for me to track the laptop and remote control it.  Most tracking software I have looked at doesn't have the "sophistication" I'm looking for, and rolling my own seems like fun.

I know I left this question a bit general,  but I'm looking for general suggestions and ideas.

Might there be some value in going the whole nine yards and instead of just having a dummy 'admin' account, using the hidden operating system functionality of truecrypt to run your own 'actaul' os thereby giving them the whole (unhidden) operating system to play with (which you have installed your tracking rootkit onto etc)? This way, you can really give them the impression of having gained access to somebody's private data (without having to mess around with faking much), install whatever rootkitesque tech you're going to for remote monitoring/control (maybe its just me but installing this kind of thing on my everyday os would make me nervous!) and be more sure of properly protecting your actual data.


Ethical hacking requirements on a banking institution If I would be required to do an ethic hacking research by a banking institution would I use my own bank account, ask for an account to the bank or open a new account and transfer some money and do some transfers to make the account or "test area" the more real possible? Should I ask for all the possible cards the bank has to do side channel attack testing?

I'm not a hacker nor I plan to do research I just want to know how would it be in real life.

As far as I understood, the question is whether you would use your own, "real" account, a freshly created account or a test account provided by the bank.

From my experience, any company wants to limit the potential impact when doing penetration tests. Therefore, they probably won't be happy if you start attacking their production systems. Just imagine what would happen if some of the servers crash or hundreds of users are locked out of their accounts because you are bruteforcing usernames or alike.

If you want to do a penetration test, get the support of the institution and - if available - access to some testing environment. Yes, this won't be identical to the "real" system - but there is probably less danger for both of you. And you don't want do get in troubles, right? ;-)


Using SYN cookies to perform a DOS attack In my software security class, we had this question:

  You are the system administrator for a provider that owns a large network (e.g., at least 64,000 IP addresses). Show how you can use SYN cookies to perform a DOS attack on a web server.

I searched everywhere, I found that SYN cookies are used to prevent DOS attacks. But this question said to perform an attack (I verified with the professor, it's not a typo).  Can someone give me some pointers so I can head in the right directions?

As far as "the Internet" knows, there is no specific attack vector enabled by SYN cookies. The best I could think of is explained below:

First some explanations on SYN cookies (details matter). SYN cookies are a way to mitigate SYN flood attacks.

The gist of SYN floods is that keeping state for an opening connection is expensive (because it uses RAM somewhere). In a SYN flood, the attacker "cheats" by not keeping state: he sends a SYN but forgets it; on the other hand, the server remembers the SYN.

SYN cookies are the server's cheat: it just forgets them too. Instead, it encodes whatever it should remember in the TCP sequence number that it sends in the response to the SYN (an ACK+SYN packet); when a normal client responds to that, it sends its own ACK with the same sequence number (actually incremented by exactly 1), which allows the server to recover the data it did not bother to remember. A TCP sequence number is 32 bits, so the server must fit the "state" within 32 bits. SYN cookies are defined to use 5 bits for a timestamp, 3 bits for the MSS, and 24 bits of "output of a cryptographic function". These 24 bits are really a MAC computed over the server IP address, client IP address, both port numbers (server side and client side), and the timestamp.

A consequence is that when the server receives an ACK which looks like a response to an ACK+SYN (one with a cookie) then the server must consider it as the third element of a TCP handshake, and thus allocate the resources for a now fully open connection. This happens if and only if the cookie value is correct (when the server recomputes it, it matches the value sent in the ACK). The attacker knows the current time and can guess/observe the three-bit encoding for the MSS value, so there are 24 unknown bits. If the cookie value is computed properly (with a cryptographic hash or something equivalent in this situation), then an attacker has only probability one in 16 millions (16777216, precisely) to hit a correct cookie value. This severely limits the possibilities of the attacker.

There has been some discussion on the CPU cost involved in SYN cookie processing. Consider that a basic Core2 x86 CPU will happily compute 8 millions of MD5 hashes per second, using a single core. It will be hard for the attacker to DoS that way (it would require sending more than 8 millions packets per second to that server...).

What can be done is the following:

Attacker sends a normal SYN, then receives the ACK+SYN from the server. The ACK+SYN contains a valid cookie for the source address and port that the attacker used; the cookie is valid for a minute or so (since the timestamp changes typically once every 64 seconds).
Attacker repeatedly sends, using the same source address and port, two packets:

a packet containing a ACK and the cookie obtained above, and also some applicative data (a 'push') which encodes a valid HTTP request;
a second packet which does a RST.

Upon receiving the first packet, the server must assume that it is a valid third packet of a TCP handshake; it then reads the data and processes the HTTP request. While the HTTP server software considers the request (and this can involve considerable resources, especially if the request is a POST and/or requests HTTP-level compression with gzip), the target kernel reads the RST and considers the socket as closing -- the HTTP server will get a write error when it will try to send the HTTP response (but only then, not before).

Since the connection is closing, the source address+port is considered "free" again, so the next ACK+push from the client will be honoured similarly.

The 64000 IP addresses come here as a way for the attacker to "fly under the radar". Repeated connections from a single IP address are likely to be noticed by any half-decent firewall, and blocked early on (before reaching the target Web server). Since the evil admin "owns" 64000 addresses, he can simulate connections from any of the 64000 addresses. The attacker would use a first SYN to get a cookie, then send a hundred or so ACK+push,RST pairs from that address. For increased effect, he would do that with a hundred addresses at a time, regularly getting new ones. He has 64000 addresses to play with, so it will take some time before he has to reuse an address.

In that scenario, the SYN cookies have the following aggravating effect, when compared to the same setup without SYN cookies: they allow the attacker not to wait for an ACK+SYN most of the time. This disables one of the classic countermeasures against DoS, i.e. adding a bit of latency when responding to a SYN.

This is still unconvincing. The SYN cookies, here, do not multiply the attacker's power by a large factor. With 64000 addresses, the attacker could maintain a million open connections (or at least seemingly open, from the server's point of view), with or without SYN cookies, and no Web server will resist that.


How do software keygens work? I have seen them plenty of times, with many different types of software, but the one thing I have always wondered, is how software keygens know what key to generate. I know the basic principle of it: the keygen looks somewhere in the software installation files and creates a key that matches some encrypted file which allows the program to work. But I wanted to know how they do that, and how to prevent it. This is really a multiple part question.

  How does the key-system work?

  How do programmers usually create software that works based on a key. I am an intermediate programmer, but I never learned much of the security/anti-piracy aspect of it. How do they create and/or recognize the keys to allow the software to start working?

  Where does it usually look to find this "encrypted file"?

  Is it in a physical file on the computer, or an of-site database that it calls?

  What do the companies do to encrypt that file?

  I would emagine that the key must be stored in more than just plaintext, what do they do to keep it encrypted?

  What method is the keygen using to create the key?

  I have played around a llitle with some password-cracker software such as "cain & able" and I have noticed, that with some of the password-cracking methods, such as brute-force and dictionary, it gives me ETAs in years, however keygens seem to create keys instantly. Are they using different methods entirely?

  What measures can companies take to prevent the use of keygens in pirated software?

  I am starting to write my own software to be distributed, I was wondering what existing, relitivly easy methods can I use to prevent

How does the key-system work?

Well it depends there are many implementations. One of them was discussed in stackoverflow:

Assuming you don't want to do a special build for each user, then:

Generate yourself a secret key for the product
Take the user's name
Concatentate the users name and the secret key and hash with (for example) SHA1
Unpack the SHA1 hash as an alphanumeric string. This is the individual user's "Product Key"
Within the program, do the same hash, and compare with the product key. If equal, OK.

Note: every key scheme can be cracked. That's why a lot of tools use online validation.

Where does it usually look to find this "encrypted file"?

There usually is no encrypted file when using the previous method. There might be other methods to generate keys with another algorithm, but they never store all keys in the program.

What do the companies do to encrypt that file?

Well if you are referring to storing the key the user typed in your system, then sometimes it's saved plaintext in a config file. Sometimes they use symetric (like AES) encryption with a hardcoded key to encrypt this file.

What method is the keygen using to create the key?

Because there are people that can figure out the scheme the program uses and just implement it in their own keygen.

What measures can companies take to prevent the use of keygens in pirated software?

Online activation, but the harder you make it for the customer to use the software the less likely you they will buy it. In the end there isn't a single piece of software that is piracy-proof. If there was, companies like Adobe and Microsoft would be hiring you instantly.


XSS echoed in pages html code but no pop up window So i have a https login page with standard username and password inputs. I put in simple xss test such as,

alert(‘XSS attack’)

the page displays a "credentials you have supplied are incorrect" warning. I dont get a pop up window but the whole line is reflected in html code. Is this still xss or?

With an XSS attack you normaly try to put JavaScript Code on a website.

In your example a user tries to log in and on the next page there may be a warning like 'Username [input string] is not valid'.

Now if you try to log in as alert(‘XSS attack’) it would not be considered as a xss attack because the browser doesn't even recognizes your input as JavaScript - it is just an ordinary string. The example warning from above on the page will look like this:

'Username alert(‘XSS attack’) is not valid'

But if you enter something like this:

<script type="text/javascript">alert("XSS");</script>

the browser will recognize it as JS, and likely evaluate it. The warning would look like this:

'Username  is not valid' (this is because JS will not be shown on the page)

Conclusion: Only by sing the script tags you will get a browser to recognize a string as JavaScript and therefore only with these tags your popup will show.

Update:

As your comment states, the input will only be printed in the value of the textbox, the approach won't work, as textboxes escape the values automatically.

But you could try this as username: " autofocus onfocus="alert(1), so the box markup will change from this:

<input type="text" name="loginidtextbox" value="" autocomplete="off">

to this:

<input type="text" name="loginidtextbox" value="" autofocus onfocus="alert(1)" autocomplete="off">


Double signature with GPG, only validate one key I have a file which I have signed with two GPG keys and want to validate that file trough a script.
The scripts validates that the signatures are correct by checking the returned status from GPG. If its not zero, the check fails.

The problem is that the machine where I'm running the script on only has one of the keys (and adding the second key to that machine is unfortunately not an solution in this case). So since I don't have both the keys, the validation fails or 2 is returned from GPG.

My question is: Is there some switch that I can give GPG so that I only need one of the public keys on the machine (one or the other) to pass the validation? GPG must of course be able to at least verify one of the keys but not necessary both of them.

Sign the file two times with detached signature and move the signature files to file.sig1 and file.sig2. When verifying, move the one you have the key for back to file.sig.

If you do not know which one should match, test both, i.e. gpg --verify test1.sig || gpg --verify test2.sig.


Use John the Ripper to break Password Protected Zip I installed kali linux, that comes with John the ripper. I have a password-protected zip file. I'm pretty sure the password is complex. I first convert the zip into a hash:
sudo zip2john FILE_LOCATION > zippedzip.txt

It took around 20 seconds to run that command.
I got this output:

Then I try running john on it:
sudo john --format=zip ZIPPEDZIP.TXT_LOCATION

However I keep getting an error:
Using default input encoding: UTF-8
No password hashes loaded (see FAQ)

I'm pretty new to John the ripper, but didn't I already load in a hash?
I then took a look at the FAQ but that confused me.
So next I tried to just run a wordlist through the hash
I used the following wordlist: https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10-million-password-list-top-100000.txt
So I ran this:

So after trying both methods, I'm not really sure how to crack this zip.

The zip2john command already tells you that the output format in PKZIP, so you should use that format if you decide to explicitly specify it in your john command using the --format switch.
If you omit the --format specifier, john obviously recognizes the format of the hash file correctly.

When you read the output of your john command, you see that the passphrase is not found within the words contained in 10-million-password-list-top-100000.txt.
Your challenge now is to find a wordlist suitable or big enough to actually contain the password.


Can iMessages be spoofed? I am subject to legal proceedings where fake iMessages (not SMS) are being introduced by the opposing party and proclaiming to have come from me. I read about spoofing SMS messages. Is it possible for iMessages to be spoofed? If not through spoof, what other ways can someone make a screenshot of iMessages with a fake phone number in the "contact" region?

Other than blatant photo editing (online tools exist for this!), it's possible to modify the message database to create seemingly native messages. All data is stored in an SQLite database and while the format is pretty complex (so as to support advanced features such as attachments, interactive apps, etc). This would mean that a sufficiently advanced person could modify their local database and insert messages from a person that never happened. They could literally present their phone to the judge and jury and unless an advanced security analyst were brought in no one would be the wiser.

As far as I know there are no known (or publicly known) exploits which allow iMessage to be spoofed before it is received on the end user device. This would be a major, ultra valuable vulnerability.

Here's what a row in the database looks like. There is more info to the left but the good stuff is pictured (click for the full size):


Is checking a token without checking a header sufficient for CSRF protection? In their guidelines for securing your application against CSRF attacks, OWASP recommends two separate checks:

1. Check standard headers to verify the request is same origin
2. AND Check CSRF token

This question asks if it suffices to check the headers without having a token. I am wondering the converse - is it sufficient to create and check an encrypted CSRF token without checking any headers?

Yes. This is the first time I see anyone recommending to do both. Checking the headers always feels a little hacky: the Referer header was not designed as a security header (there might be obscure cases where it fails) and is not always set. We typically recommend using tokens and don't suggest checking the "Referer" header.

It can't hurt to do both if you reject when either condition fails, but tokens are enough -- assuming they're implemented properly.


Why are salted hashes more secure for password storage? I know there are many discussions on salted hashes, and I understand that the purpose is to make it impossible to build a rainbow table of all possible hashes (generally up to 7 characters).

My understanding is that the random salted values are simply concatenated to the password hash. Why can a rainbow table not be used against the password hash and ignore the first X bits that are known to be the random salt hash?

Update

Thanks for the replies. I am guessing for this to work, the directory (LDAP, etc) has to store a salt specific to each user, or it seems like the salt would be "lost" and authentication could never occur.

It typically works like this:
Say your password is "baseball". I could simply store it raw, but anyone who gets my database gets the password. So instead I do an SHA1 hash on it, and get this:
$ echo -n baseball | sha1sum
a2c901c8c6dea98958c219f6f2d038c44dc5d362

Theoretically it's impossible to reverse a SHA1 hash. But go do a google search on that exact string, and you will have no trouble recovering the original password.
Plus, if two users in the database have the same password, then they'll have the same SHA1 hash. And if one of them has a password hint that says try "baseball" -- well now I know what both users' passwords are.
So before we hash it, we prepend a unique string. Not a secret, just something unique. How about WquZ012C. So now we're hashing the string WquZ012Cbaseball. That hashes to this:

c5e635ec235a51e89f6ed7d4857afe58663d54f5

Googling that string turns up nothing (except perhaps this page), so now we're on to something. And if person2 also uses "baseball" as his password, we use a different salt and get a different hash.
Of course, in order to test out your password, you have to know what the salt is. So we have to store that somewhere. Most implementations just tack it right on there with the hash, usually with some delimiter. Try this if you have openssl installed:
[tylerl ~]$ openssl passwd -1
Password: baseball
Verifying - Password: baseball
$1$oaagVya9$NMvf1IyubxEYvrZTRSLgk0

This gives us a hash using the standard crypt library. So our hash is $1$oaagVya9$NMvf1IyubxEYvrZTRSLgk0: it's actually 3 sections separated by $. I'll replace the delimiter with a space to make it more visually clear:
$1$oaagVya9$NMvf1IyubxEYvrZTRSLgk0
 1 oaagVya9 NMvf1IyubxEYvrZTRSLgk0

1 means "algorithm number 1" which is a little complicated, but uses MD5. There are plenty others which are much better, but this is our example.
oaagVya9 is our salt. Plunked down right there in with our hash.
NMvf1IyubxEYvrZTRSLgk0 is the actual MD5 sum, base64-encoded.

If I run the process again, I get a completely different hash with a different salt. In this example, there are about 1014 ways to store this one password. All of these are for the password "baseball":
$1$9XsNo9.P$kTPuyvrHqsJJuCci3zLwL.
$1$nLEOCtx6$uSnz6PF8q3YuUhB3rLTC3/
$1$/jZJXTF3$OqDuk8T/cEIGpeKWfsamf.
$1$2lC.Cb/U$KR0jkhpeb1sz.UIqvfYOR.

But, if I deliberately specify the salt I want to check, I'll get back my expected result:
[tylerl ~]$ openssl passwd -1 -salt oaagVya9
Password: baseball
Verifying - Password: baseball
$1$oaagVya9$NMvf1IyubxEYvrZTRSLgk0

And that's the test I run to check to see if the password is correct. Find the stored hash for the user, find the saved salt, re-run that same hash using saved salt, check to see if the result matches the original hash.
Implementing This Yourself
To be clear, this post is not an implementation guide. Don't simply salt your MD5 and call it good. That's not enough in today's risk climate. You'll instead want to run an iterative process which runs the hash function thousands of times. This has been explained elsewhere many times over, so I won't go over the "why" here.
There are several well-established and trusted options for doing this:

crypt: The function I used above is an older variation on the unix crypt password hashing mechanism built-in to all Unix/Linux operating systems. The original (DES-based) version is horribly insecure; don't even consider it. The one I showed (MD5-based) is better, but still shouldn't be used today. Later variations, including the SHA-256 and SHA-512 variations should be reasonable. All recent variants implement multiple rounds of hashes.

bcrypt: The blowfish version of the crypt functional call mentioned above. Capitalizes on the fact that blowfish has a very expensive key setup process, and takes a "cost" parameter which increases the key setup time accordingly.

PBKDF2: ("Password-based Key Derivation Function version 2") Created to produce strong cryptographic keys from simple passwords, this is the only function listed here that actually has an RFC. Runs a configurable number of rounds, with each round it hashes the password plus the previous round's result. The first round uses a salt. It's worth noting that its original intended purpose is creating strong keys, not storing passwords, but the overlap in goals makes this a well-trusted solution here as well. If you had no libraries available and were forced to implement something from scratch, this is the easiest and best-documented option. Though, obviously, using a well-vetted library is always best.

scrypt: A recently-introduced system designed specifically to be difficult to implement on dedicated hardware. In addition to requiring multiple rounds of a hashing function, scrypt also has a very large working memory state, so as to increase the RAM requirement for implementations. While very new and mostly unproven, it looks at least as secure as the others, and possibly the most secure of them all.


DC server integrated with DNS trying to contact Blacklisted DNS hostname Need some help in understanding below attack.

The below logs are extracted from the firewall and i could see a outbound connection from ldap server to 194.169.218.42. But walking through the logs(given below) you could see DNS hostname martinhot.xyz
This dns domain has differnt ip(93.158.205.211) and is blacklisted by almost all threat feeds. is this kind of attack? Why my ldap server Contacting  this domain?

<13>Sep 13 07:29:13 10.30.130.7 13Sep2016 07:29:13 monitor 10.x.x.x product: New Anti Virus; src: LDAp IP; s_port: 54661; dst:
194.169.218.42; service: 53; proto: udp; rule: ;Confidence Level: 5;Destination DNS Hostname: martinhot.xyz;Protection Type: DNS reputation;Protection name: Malware.ytire;Source OS: Windows;Suppressed logs: 4;__policy_id_tag: product=VPN-1 & FireWall-1[db_tag={79357CCC-7962-D34A-B8E9-BED995AEA705};mgmt=SecurityManager.com;date=1473679193;policy_name=Col_fw];action_details:
*** Confidential ***;description: Connection was allowed because background classification mode was set. See sk74120 for more information.;has_accounting: 0;i/f_dir: outbound;i/f_name: eth0;log_id: 2;malware_action: Malicious DNS request;malware_family: Malware;malware_rule_id: {00000040-0096-004E-9D42-F129618FF42F};origin_sic_name: ;protection_id: 0020287A0;received_bytes: 0;scope: 10.25.165.254;sent_bytes: 0;session_id: <57d7e309,00000022,0bfc190a,c0000002>;severity: 3;snid: 7951c679;src_machine_name: *** Confidential ***;src_user_name: *** Confidential ***;user: *** Confidential ***;vendor_list: Check Point ThreatCloud, ;

So My LDAP server is contacting the DNS server which is blacklisted. How saFe is this.
Should i be concerned?

If the LDAP server is actually an Active Directory Domain Controller, then it will have a bundled DNS server installed. By default, recursive resolution is also enabled.

Many Windows admins also set this DNS server as the default on clients as it is the easiest way for the domain DNS names to be picked up without delegation.

You're probably seeing that DNS server resolving the domain for one of the clients.

While the DNS server can be configured to log each resolution, it is not very efficient. So the best way to find out which clients are involved is to look for connections to the IP that is returned by DNS.


Is HTTPS meaningful for Jenkins Docker container behind Nginx? I have a Docker Compose setup that starts up Nexus, Jenkins and Nginx containers. All calls to Jenkins and Nexus must pass through Nginx.  I accomplish this by only port forwarding the Nginx container.  The Nexus and Jenkins container ports are merely exposed towards the Docker network.
This is my (simplified) docker-compose.yml:
version: '3.7'
services:
  nexus:
    build: ./nexus/.
    expose:
      - 8081
  jenkins:
    build: ./jenkins/.
    expose:
      - 8080
      - 50000  // no longer needed if Jenkins does not need HTTPS
    depends_on:
      - nexus
  nginx:
    image: nginx:1.19.5
    ports:
      - 80:80  // will also need to port forward 443:443 for HTTPS
    depends_on:
      - nexus
      - jenkins

My nginx.conf (again simplified):
http {
    upstream docker-jenkins {
        server jenkins:8080;
    }
    upstream docker-nexus {
        server nexus:8081;
    }

    server {
        server_name  jenkins.homenetwork.dns;

        location / {
            proxy_pass http://docker-jenkins;
        }
    }

    server {
        server_name  nexus.homenetwork.dns;

        location / {
            proxy_pass http://docker-nexus;
        }
    }
}

I am using this on my home network and will allow BitBucket to trigger jobs from Jenkins (through Nginx!). This means that the port must be externally accessible.  Obviously Nginx will need to encrypt the incoming urls with HTTPS. So the expected addresses are https://jenkins.homenetwork.dns and https://nexus.homenetwork.dns with the HTTP versions redirecting to HTTPS.
The question is, do I need to setup Nexus and Jenkins with a SSL certificate?  They are included in many tutorials for setting up Jenkins and Nexus, but the network traffic between Jenkins/Nexus and Nginx should only be visible from the machine that's hosting the Docker containers.  Do I run a security risk somehow by not encrypting the traffic between the Docker containers?

In practice I haven't seen that often.  As long as

the traffic is secure without encryption between the reverse proxy (nginx) and the application (e.g. on the same hardware or safe network); and
it is OK for you that the nginx instance handles all your network certificates

nginx would handle HTTPS and proxy_pass the rest upwards.  This has advantages of speed as well as simplicity in the apps.


Setting up a IPv6 Darknet/Network Telescope I would like to setup a IPv6 Darknet/Network Telescope. It is unused address space a network that is completely passive and sends no outbound traffic. This talk gives more details.

Most residential IPv6 internet connections get a /64 subnet. Considering with IPv6 there is not NAT in the way it seems like it would be a great opportunity to setup a darket/network telescope.

I have searched online but I have not found any resources to setup an IPv6 darknet/network telescope on Linux.

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.


Android app man-in-the-middle attack Let's suppose I have an Android app that after strong authentication pulls sensitive data from server A and sends it to server B without storing it. The data appears only in the network traffic (encrypted obviously) and in the memory segment of the app.

The question is: is it feasible or even possible to modify the apk and hook it somehow to replace the data which is forwarded from server A to B with a predefined string?

I know that relying on client side security is a huge no, but I'd like to understand the complexity of this hack (getting the apk, decompiling, finding the function to hook, compiling, installing) and the possible show stoppers.

In this scenario how much more security could code obfuscation give? How easy to decompile and reverse engineer an obfuscated code?

I'm neither an android nor a java developer, but I'm more or less familiar with security concepts

My answer assumes that your attacker is "skilled in the art" of doing this sort of work.

  getting the apk

It would take less time than it took you to write the question.

  decompiling

It depends a bit on the speed of the computer, but it should be on the order of a few minutes.

  finding the function to hook

If you go way out of your way to try to make this non-obvious... perhaps a day? It is a bit difficult to say in the abstract, as it depends a lot on the size and complexity of the app, whether this is just a single "function" or if the work is substantially more involved, etc.

Suffice it to say that anyone who wants to take the time will be able to find what needs to be changed.

  compiling

It depends a bit on the speed of the computer and the size of the code base, but again it should be measured in minutes.

  installing

It would take less time than it took you to write the question.

  In this scenario how much more security could code obfuscation give?

A few years back, I was told by one security researcher that using simple ProGuard obfuscation actually made it easier to do this sort of attack.

There are more powerful obfuscators out there, including ProGuard's "big brother" DexGuard. Similarly, there are people who create de-obfuscators, tools that knock DexGuard-level obfuscation down to something more akin to ProGuard. For example, DexGuard tries to encrypt as much of your app as it can; de-obfuscators would generate a decrypted edition of the code.

Hence, the benefit of high-level obfuscators varies, based upon the current state of the arms race between obfuscator developers and de-obfuscator developers. I can't say with any certainty where the arms race stands now, let alone when somebody else reads this answer years from now.

I liken obfuscators to the old tale of two hunters in the woods being chased by a bear. If you were one of the hunters, you don't have to run faster than the bear to escape. You just have to run faster than the other hunter. In the case of obfuscators, the objective is to make fussing with your app unappealing, causing attackers to move onto other potentially easier targets. The problem with this approach is that it assumes that the attacker does not care about your app specifically, that your app is merely one target among many. Attackers who care about attacking your app for specific reasons will not behave that way, and they will spend the time to crack it. In other words, running faster than the other hunter assumes that the bear is not pissed off at you specifically.


Is it ok to send plain text credentials in a XHR GET request? When testing my api server, I often requested the website http://domain.tld/api/?username=john&password=123456 to test things and after a while of course, my browser would autocomplete the url, because it was in my browser's history. Seeing my password in plain text there made me feel very uncomfortable. Of course, this will never happen in the XHR request, which is the only way the api url is accessed.

But still, it got me thinking. First I did my research on if it is right to send sensible data in plain text and if I shouldn't encrypt or at least base64 encode it, but it's said it is normal to send data in plain text when you're using HTTPS (which of course I do on my website!).

Then I was like: fine, then let me just swap to a POST request instead. This feels better for me than seeing the data in the URL.
But this would interfere with the idea of RESTful APIs. It should be a GET request.

So what can I do? What should I do? Or what you just do nothing? I'm curious.

What do you use username and password for? If you are using them for logging in/authorization then usually:

You would have an end point like /login and you pass your username and password 1 time using POST method,
Then depending on the authentication system you are using, the end point returns a token or session information,
You pass this token or session information inside the header part of your subsequent requests. So you don't have to pass your username/password every time you make a request to your API.

It is ok to pass your username and password as plain text on first POST request when you are using HTTPS, but don't put them in your URL.


What companies drive around recording license plates? What do they do this for and on what grounds are they able to do so, legally speaking? A friend shared a "security service" he just read about. Apparently the product is in beta and can thus be tried by anyone right now. I found it very interesting and surprising. I'm curious to know who provides the license plate photos for this product and what legal implications exist with this sort of thing. The service can be found at

https://learn-nvls.com/learn/gui/index.aspx?ProviderType=NormalProvider
for the username: stakeout
password: beta

Entering any valid license plate will return photos of that vehicle both on public and private property as capture by both private and public agencies (e.g., toll cams, traffic cams, police, et cetera). The app also shows metadata regarding each photo such as location and a time profile for when the vehicle is at a certain address.

Thanks for sharing thoughts and answers,
TJ

Vigilant Solutions claims to have the largest repository, with over 2 billion records. http://www.wired.com/2014/05/license-plate-tracking/

The information is shared with law enforcement (local, state, federal), insurance companies, etc. Unfortunately there seem to be few if any legal restrictions on collecting and using the information, despite the potential for quite a detailed dossier on your movements (with implications for free speech and association, not to mention basic privacy, especially of your health, religious, financial info) being available to untrusted entities.

See also:

You are being tracked (ACLU)

License plate reader firm releases dubious poll to show public support

Your car, tracked: the rapid rise of license plate readers


Password policies and keyspace question After reading several answers to Are randomly-generated passwords starting with "a" less secure?
and the link to JtR keyspace topic, I had a thought/question.

Even though most PW policies are reducing the total keyspace, they are attempting to remove the password from the "dictionary space" and put it into the "brute force" space.  Which is much much larger, especially as we increase the password length.

Is that correct?

While that is what many password policies attempt to do, moving the user passwords from dictionaries and into a form that can only be brute forced, they're forgetting the most insecure part of the password: The human mind.

Human minds are terrible at generating true randomness.  They're even worse at memorizing random values.  If there's a pattern that they can follow to help them remember it, they'll use it.

And, most damning of all, humans will reuse passwords.

Attackers have caught on and, rather than making their dictionaries based on words found in various languages, they make their dictionaries based on previously leaked passwords.

The current advice to users is to remember two passwords: The one to log into your computer, and the one to log into your password manager. Never try to memorize any other passwords, and never try to generate a password on your own. Let your password manager make truly random passwords, as these are the only ones that are guaranteed to not have shortcuts like dictionary attacks, keyboard pattern attacks, and the like.

The current advice to people setting up authentication systems is to follow the NIST standards.  Specifically,

Do not force users to use different character classes like at least one of each upper, lower, number, and symbol characters.
Check that the password hasn't been leaked before when the user sets or changes their password (i.e., use the Pwnd Passwords API).
Do not force users to change their passwords for arbitrary reasons, such as periodically.
DO force users to change their password for specific reasons, such as a suspected leak of your database (and be honest when such a leak happens).

etc.


KeePassXC for managing passwords, threat model: Entire world actively trying to decrypt my password given the file I use KeePassXC on a Linux distribution for managing my passwords.

For the sake of the argument, let's assume that the file is publicly accessible, and the entire world's number 1 priority for the next 100 years is to try to decrypt my kdbx file. No more Facebook, no more extra activities, the whole manpower of the world (Including individuals, corporations, organizations and so on) is suddenly dedicated to this in the best of their ability and knowledge, 18 hours a day, for the next 100 years.

Let's also assume, for the sake of the argument, that me and my computer are out of the equation (no Rubber-hose cryptanalysis, no system hacking, etc), all the world has it's the kdbx file, the protocol info (below) and some hints about the password.

Details: Encryption Algorithm: AES 256 Bit Key Derivation function: Argon2 (KDBX4) Transform rounds: 11, Memory usage 64 MiB Parallelism 4 Threads, (Benchmarked for 1 second delay). Only Password, no key file.

Password: 49 characters, that don't include words in the dictionary (perhaps just accidentally, 3-letter words), however, not even randomly generated.

The question is: how likely is it that the file is decrypted within 100 years?

It all comes down to the strength of your password. First, you need to know how many bits of entropy in your password. Keepass will estimate password strength in bits, but I find that the zxcvbn test gives better estimates (I *believe* that website runs zxcvbn locally in your browser and does not upload anything to the site, but would forgive your tin-foil-hattery if you don't want to type your master password into some random website).

According to this Quora post there were estimated to be 2 billion personal computers in the world in 2014. So let's pick 10 billion for the number of personal computers, cell phones, and servers in 2019. possibly off by a factor of 2 or 4 if we assume that all machines are multi-core. Possibly off by more than that if we include all GPUs on the planet. So "plus or minus a few orders of magnitude".

You say your crypto params were chosen for a ~ 1 second delay in key derivation from the password, so calculate:

2^num_bits_of_passwd * 1 [second] / 10 billion [machines guessing]

would give you the expected number of seconds to crack.

As an example calculation, KeePass just generated me a 20 char password which it estimates at 117 bits, so *math*, the crack time is 3.8 x 107 x age of the universe, plus or minus a few orders of magnitude.