Can Acronis True Image decrypt your files? I use Acronis backup software to create images of my system, have a copy of important stuff in the cloud and all other backup related things.

As Acronis states, their software uses AES encryption which happens locally.

But I have found that Acronis have some catch in EULA:

So does it mean that their encryption worth nothing?

The 'worth' of the encryption in this case (which has nothing to do with the actual encryption as I'll explain below) is completely opinion-based, so you better rephrase that. But I'll try to explain the meaning of the EULA:
This means that they have the symmetric AES key to do the decryption. Their encryption isn't worth nothing per se, it is worth as much as you are willing to trust Acronis. Meaning, the AES encryption is in place, but they have the ability to decrypt your data. The question is do they? or will they? These are questions no one on this site will be able to answer. And the decision of trusting them is yours to make.


Is there a security reason to require email address and password in separate steps? I have noticed lately that instead of having an email address and password entry box on the same page/screen, a lot of websites and apps will instead ask for your email address first, then it will ask for your password in a separate step.
As I use a password manager, this means I cannot just fill in the email address and password in one easy step - I either have to manually type my email address, or I have to autofill with the password manager twice.
My question is: is there a good security reason why they are increasingly doing it this way, or is it just bad UI design?

The main reason might be neither, but the ability for conditional authentication steps. Some services e.g. support multiple single-sign on (SSO) providers, and the username is required to pick the correct SSO to forward the user to. Some may even have different authentication methods altogether. From security and privacy perspective this is also a bit problematic, as it may reveal whether a user exists or not.


Can an xss vulnerability without authentication be exploited? I am confused about the attack surface made possible by an XSS vulnerability. Suppose I have a simple web application that does not involve authentication (perhaps a "word of the day" kind of thing). If it is naively written and allows injection by crafting a malicious link, what kind of damage can the injection do?

To make things concrete, here's a PHP script (what else) that is wide open to attack, since it will send back any nonsense added to the request URL.

  <?php echo 'Access denied:' . $_SERVER["PHP_SELF"] ; ?>

How bad would it be to have this problem on my server? What can happen exactly? My script does not collect or store any data, so there is no chance of a persistent injection on my server.

If the user clicking on the malicious link trusts my domain, they could be tricked into doing or accepting things that they wouldn't otherwise. But if my domain enjoys no special trust, is there still danger? The attacker has already had access to the user/victim to trick them into visiting me through the doctored link, so is my website really posing an additional danger?
Since the reflected code appears to originate on my domain, could the attacker gain access to my intranet? I suppose in this case no trickery is needed: the attacker can run the malicious requests directly on my server, right?

I must be missing something here, please help me understand what that is.

If the user clicking on the malicious link trusts my domain, they could be tricked into doing or accepting things that they wouldn't otherwise. But if my domain enjoys no special trust, is there still danger? The attacker has already had access to the user/victim to trick them into visiting me through the doctored link, so is my website really posing an additional danger?

The attacker doesn't necessarily have access to the user. They may have just sent a spam email with a link, or made up a fake social media profile to send them that link. Since your site seems benign enough (they may even know of the site and trust it) they may be more likely to click the link.

You're right that there is a lesser impact by way of your domain not having any secrets on it and no authentication. This is certainly true for the general users, at least. But consider that if you had, for example, a CMS admin panel on your site for managing the content or a blog, the attacker could instead trick you into clicking a malicious link and trigger XSS to get access to that panel.

While unlikely, it may also be possible for an attacker to leverage your site as a trusted domain in order to deliver a browser exploit via the XSS. A common example of this is where an attacker writes a script that reveals identifying information about someone who is browsing via the Tor browser, and tricks the user into enabling scripts on what seems like a benign and trusted domain.

  Since the reflected code appears to originate on my domain, could the attacker gain access to my intranet? I suppose in this case no trickery is needed: the attacker can run the malicious requests directly on my server, right?

If by "intranet" you mean other sites on your local LAN, not in general. Cross-origin requests are denied unless the target server allows them using a CORS header. Subdomains are also not reachable due to same origin policy unless you override this - http://foo.com cannot reach http://x.foo.com or http://y.foo.com, and http://x.foo.com can reach neither http://y.foo.com or http://foo.com without a permissive CORS policy applied by the target domain.

I'm unsure what you mean by "run the malicious requests directly on my server" - XSS results in client-side script execution, not server-side.


How do i use a guessable ID for authentication This question doesn't fit well in many categories but hopefully someone's run into it before.

I'm developing a web api that will interact with a physical device. Each new physical device has it's own unique ID, but those IDs are guessable (essentially they are sequential as they come off the assembly line.)

When the device is plugged into a computer via USB we will launch a client app which the user will have installed and sync data from the device to the API. We can't rely on a 1:1 relationship of computers to devices, a user might sync on multiple machines or multiple users might sync on the same machine.

We want to authenticate to the API using nothing more than the device ID, but i don't want someone to be able to spoof another users ID by calling my API directly with a different device ID.

I'm wondering what I could do to the device ID that could enable me to securely use it for authentication.

My first thought was to encrypt the ID with a private key and then share the private key with the client software. The client software could then encrypt the device id before calling the API and transmit that encrypted value. The api compares it against a stored value and your good, but I'm worried that it will be difficult to secure the private key when it has to be stored on the client computer.

Thoughts?

Given your premises, the problem cannot be solved in the form you want it to.  You have said that (1) the device ID is guessable, (2) the device ID is the only secret that you want to allow us to use, (3) you want to authenticate using the device ID.  Well, that's not solvable.  If I can guess Alice's device ID, then I know all of the secrets necessary to masquerade as Alice, and your system won't be able to distinguish me from Alice.

You mention something about encrypting with a cryptographic key, but if you had a secure way to share the cryptographic key with just Alice (in a way that prevents me from learning it), you could simply use that key for authentication -- you wouldn't need to use the device ID.  However, this is ruled out by your rules that no other secret is permitted.  So I don't really understand what you are asking or what are the real constraints here.

Why don't you tell us about the application domain and what you're trying to achieve and why you think the device ID is the only thing you can use for authentication.  We may be able to come up with some approaches or solutions that haven't occurred to you.

For instance, here is an approach you could consider.  When the device first registers itself with your service, it generates a new, unique public/private keypair, store the private key on the device, and send the public key to your central server.  There might be some secure registration procedure where the public key is sent to the central server and registered and associated with Alice's account.   In the future, when the user wants to sync on a machine and invoke your central API, the device can set up a secure connection to your central server and authenticate itself using its private key (think client certs and SSL), then send those API calls.  The encrypted communication can be routed through the machine/desktop, so that it does not require trust in the machine/desktop.  The private key would never leave the device.  Please note that this is just an example of a possible approach -- depending upon your requirements, it might or might not meet your requirements.  Please don't get too caught up in the details of this particular example.  Rather, the point I'm making is that if we are clear on your requirements and constraints, we may be able to come up with some suggestions about the best way to solve your problem, within the constraints you face.


JPEG artifacts leaking information about redacted contents It was mentioned that JPEG should not be used between image creation and redaction of sensitive contents, because compression artifacts around the redacted area may leak information. Given how this lossy format works, this makes sense. Is there any public research on this subject?
The core of the issue is that, for a lossy format like JPEG, the pixels are not entirely independent of each other, and each pixel has a certain relation to the value of the neighboring pixels. This relation is called the DC coefficient, and applies to the 8x8 pixel blocks that are mostly independent.

JPEG compression is a form of transform compression using DCT. A quick Google gives this overview of the algorithm:

http://www.dspguide.com/ch27/6.htm

Now the important bits here are:

8x8 (or whatever size you set during compression) fragments are independent of each other
Most of the compression happens in the high frequency components

The #1 point is the most practically useful one. If your redaction allows you to add ample border space, extending it by the fragment size ensures that all the related information is likewise lost.

The #2 point is something that someone else can potentially elaborate on. Essentially, to be recovered by forensics, the correlation between the pixels to be reconstructed would have to impact the final encoding in a statistically significant way. That does not seem to me to be a trivial task. However, as JPEG is deterministic, educated guesses can be verified, or even brute-forced.


Using a virtual machine as a buffer between USB media and OS I was directed here from the Unix & Linux site. I've gone through some of the related questions, but they seem to be more concerned about whether a guest OS can access the host OS in someway. Since it doesn't seem very likely, I'll tell you about my requirements.

When the user puts a USB memory stick in a USB port, the system should automatically download the data to a virtual machine, perform some analyzing, virus scanning, what not. After this, the payload should be made available to the host OS.

Beforehand the guest OS should be completely insulated from the host, so no access from the network, no mapped drives, nothing. But after the processing is done successfully, the host would need to find some way to get access to the payload. As well as destroying the VM.

Do you have ideas on how to implement this sort of thing, know of any existing solutions or any other insights?

Update:
So this seems to be a feasible (and not a completely insane) solution, but there's one more issue. How to actually implement the communication between the Guest OS and the Host OS.

The most obvious solution is a network based approach, but due to the isolation requirements this can't be considered really. So what other approaches are there?

I think this security solution could work if implemented properly.

Clearly the host OS could override the guest at any point, but in this case they are working together. The general case is that the auto-mount daemon needs to work with the guest OS to check the device.   Each window manager will have their own way of auto-mounting devices.  Its possible to disable this feature,  and replace it with an auto-mount daemon that you can hook. In this hook you want to perform an action prior to mounting the device.  (I think Halevt might be the best choice,  but you should look at the other auto-mount daemons listed)


Best way to secure file removals in Windows remotely I have Windows 2008 R2 box on colocation. I want to remove certain files with a high degree guarantee it cannot be recovered from physical HDD access.

Could someone please explain what levels of security (NTFS-wise) can be achieved with different tools?

Please note I have RDP into this computer and plane IPMI - I can reboot it safely even if OS is frozen

Also a side note - by physicall access I mean that there are bunch of commercial labs who does fairly good job recovering data from damaged disks (even with damaged margnetic plates) - so I'd like this to be covered.. However I understand that technology available to such labs is not the same as say specialised government agencies (these I dont want to cover).

All you need is a file shredder program, there are plenty of freeware ones. Chances are good you have one included with your AV software anyway. These tools over-write the disk sectors multiple times with different data patterns to completely erase their original pattern so that they cannot be recovered even with physical access.


Protecting yourself from DNS spoof How does one protect themself from a DNS compromised site, which also has had their SSL private key stolen? Short of monitoring which IP the packets are being sent to.

Edit: Or even without the private key, could they not just use something like Zero SSL, provided they have full control the DNS server?

Detecting the use of a valid but somehow compromised certificate is hard:

If the target site has their private keys stolen and did not realize it yet then the attacker to spoof the site perfectly, i.e. the client will not realize the difference to the original site.
If the site has it's private key stolen and realized it then it should revoke the certificate. In theory the browser will check if the certificate was revoked and refuse to connect in this case. But in practice this check cannot really relied on except in special cases (like EV certificates or sites deemed important by the browser vendor) since browsers either don't to an revocation check with OCSP at all or will ignore errors during the check - where such errors might be caused by the attacker.
If an attacker managed to get a publicly trusted certificate for the site  (for example by taking over the sites DNS long enough to get such a certificate, see recent issue with Fox-IT) it is also hard for the client to detect this as a problem since using a new certificate might actually be valid. Projects like Convergence might help in this case because they allow to detect if other users see a different certificate for the same site. Also, certificate pinning (HPKP) used by the site itself might help.

Since detecting the use the bad certificate is impossible in many cases this leaves only detecting the DNS spoofing:

IP monitoring like you suggested might help to detect if the attacker is using a target IP very different from the one usually used by the original site. Note that this does not help against ARP spoofing in local networks or internet wide BGP redirects since the target IP is not necessarily changed in this case - only rerouted.
If the site supports DNSSec it should be used to verify what the real IP is. Of course this only helps against local spoofing and not if the primary DNS server for the domain was hacked.
If the target does not employ DNSSec it might be useful to ask a DNS server which is not affected by the (local) DNS spoofing. For example one might use DNS over HTTPS so that the attacker is not able to spoof these DNS answers too. An attacker might of course try to make these sites unavailable for you in the hope that you fall back to the locally spoofed DNS.


Mandatory Access Control Rulesets, how to deal with Python, Bash and other interpreters? Question
(a) Is there? and if so (b) what is a standard or accepted way for MAC systems to deal with complex software and in particular with Python, Bash and other interpreters?    (in terms of creating rules for this kind of "complex" and "versatile" software)
With python for example, it appears to me to be impractical to regulate the access the python process receives on the basis of the executables (which will always be the python executables etc). It at best would rather be regulated according to the trustworthyness of the "python-script" code involved (as this also defined the resources needed).
Background

Referring to MAC (mandatory access controll) here is meant to give reference to certain software like SELinux, grsecurity, TOMOYO, Apparmor and alike. (I am still struggling with the right term to reference to those concepts and software, which is why I express it here, trying to avoid ambiguity.)

The MAC is conceived here to be a tool/way to enhance security that goes in some way beyond things possible with discretionary access control (DAC).

This "additional security value" is caused by controlling the access in a more detailed manner than it might be possible with the DAC. As an example the access which a software receives may be based on more than just the USER its process is started with. And of course the files and resources that can be touched by a certain process is at best fine-tailored to the bare limit the programm actually needs.

It can be seen as a key goal of a MAC to limit the access to the minimum necessary.

If limiting (for security concerns) the access of a programm to those resources that it actually only needs is something which is wanted from a MAC system, than this seems most easy/practical for software which has a very limited functionality. Likewise more versatile and complex software seems by very far be much harder to be confined and limited.

For Turing-complete languages, you can't detect what they're going to do or access ahead of time. You can try to detect certain things based on usage of various language-specific framework classes and keywords, but it's not easy.

Let's say you're trying to stop someone from calling alert() in Javascript. Consider the following:

exec(
  atob('dmFyIHQ9MSx4PTA7eD1NYXRoLmxvZyh0KTsgaWYoeDwxKXthbD9ydCgnZGVycCcpO30=')
    .replace(/\?/g,'t')
);

Can you really write something that always identifies alert calls? Nope!

The only way to achieve this is to provide the control at a low level, e.g. within alert() itself. Obviously this isn't ideal; can you hook every possible JavaScript engine in every browser? Again, no. So you have to go lower still - maybe hook all calls to the system API used to create new windows. Oh, but now you need to be able to tell the difference between an alert() message and a normal window.

Not as easy as it first might seem, is it?

This is precisely why most mandatory access control systems focus entirely on access to resources, rather than operations. You have to know what you're trying to protect against in advance, and you have to know how that resource is going to be accessed. As such, there's no generic way to do what you want, even on a specific language. You need to manually configure the restrictions ahead of time.


What is the impact of certificate validation level (or class) on deployed web applications? Certificates can have a class level (or validation level). What is the impact of these levels on deployed web applications?

More specifically:

Is the certificate level included in the certificate itself?
Can a level 1 certificate be used to deploy a web application including a paid service?
Do pop-ups appear on the user side if a website's certificate is too low? If yes, at which level?

Thanks.

The certificate level usually can be seen in the certificate (e.g., StartCom free certificates have OU=StartCom Free Certificate Member, O=Persona Not Validated in the subject DN — apparently not anymore (see below), and separate intermediate CA certificates are used for different levels). But at least in Firefox this information is not easily available in the browser UI (you need to get to the certificate properties window with lots of technical information to see it); only EV certificates are clearly indicated, and everything below EV is basically treated the same.

CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (version 1.0 adopted on 22 Nov. 2011 with an Effective Date of 1 July 2012) specify two Certificate Policy identifiers which could optionally be used by CAs to assert the identity validation level:

2.23.140.1.2.1 — only a domain validation was performed;
2.23.140.1.2.2 — the subject identity was validated before issuing the certificate.

At least StartCom now uses 2.23.140.1.2.1 in newly issued Class 1 certificates, and no longer includes a human-readable OU=StartCom Free Certificate Member, O=Persona Not Validated in the subject DN. However, browsers currently do not seem to pay attention to these policy OIDs when displaying the certificate information (e.g., the Mozilla bug #740571 is still open).
Using level 1 certificates for commercial purpose may be against the CA policy. The CA may refuse to issue the certificate if the domain name obviously suggests commercial use, or revoke the certificate later for violating the policy.
If a certificate is valid (not expired, the corresponding root certificate is trusted, there are no problems in verifying the trust chain, and revocation checks pass successfully), there will be no warning pop-ups irrespective of the certificate validation level.


Compiling a buffer overflow example in modern Linux? I'm trying to compile a simple buffer overflow example on a Debian i386 VM.  The executable builds ok, but EIP does not get overwritten correctly despite being supplied a sufficiently large input to overflow the buffer and overwrite the pushed EIP on the stack.  Here are my commands as root:

sysctl -w kernel.randomize_va_space=0
gcc test.c -z execstack -z norelro -fno-stack-protector -D_FORTIFY_SOURCE=0 -ggdb -o test

As you can see I have:

Made the stack executable
Removed stack canaries
Disabled ASLR system wide
Removed relro protections
Disabled gcc's FORTIFY_SOURCE protections

Here is test.c:

#include <stdio.h>
#include <string.h>

int main(int argc, char **argv) {
  char buf[128];
  if(argc < 2) return 1;
  strcpy(buf, argv[1]);
  printf("%s\n", buf);
  return 0;
}

I have experimented with crash strings (just all As) in length from 128-256. In gdb, the pushed EIP never gets overwritten.  Realistically it should just be a string of 132 bytes to overwrite EIP as there are no other local stack variables.

Is there some other protection I need to disable when compiling?  Or is there something else to disable with sysctl?

While the accepted answer is correct in suggesting moving everything to a different function does not explain why.

As you can see in this question and answer main() functions often perform a stack alignment to ensure that the stack is setup properly.  The following instruction is performed:

83 e4 f0                and    esp, 0xfffffff0

This will align the stack to 8 bytes.  What this means is that a subtraction operation was performed on esp.  So in order to overflow the return address you need 128 bytes + <variable stack alignment> + <optional saved ebp> + <new_return_address>.

I compiled and ran your program (I had to add a -m32).

Starting program: /home/user/Private/misc/overflow_test
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBCCCCDDDDEEEEFFFFaaaabbbbcccc
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBCCCCDDDDEEEEFFFFaaaabbbbcccc

Program received signal SIGSEGV, Segmentation fault.
0x63636363 in ?? ()

I used 128 As, and then 4 of each new letter.

Decompiling the program we see the following lines:

;      .//overflow_test.c:4
;-- main:
;-- sym.main:
0x0804842d    55             push ebp
0x0804842e    89e5           mov ebp, esp
0x08048430    83e4f0         and esp, 0xfffffff0
0x08048433    81ec90000000   sub esp, 0x90

Here we see that 0x90 (144) is subtracted from the stack.  Which means that more than 128 bytes of space is allocated for local variables.  This SO answer gives some reasons why this might occur.  So if you account for the 128 bytes, the 16 extra bytes added for the local variables, and assume 8 bytes of stack alignment: Then you have EBP overwritten with 0x62626262 and the return address with 0x63636363.

Normal functions generally don't perform this step of aligning the stack.  Which is why when you moved it into a separate function everything worked as expected.  In real exploitation the chances that you're exploiting the parameters going into a main() is highly unlikely.  It's more realistic to be running in a different function's scope.


Does EV SSL certificate makes any difference while used instead of self signed ssl in case of API for android app? I understand that self signed ssl is risky incase of dns spoofing since the attacker may generate a self signed ssl himself and place it in his ip address and it will trigger a warning in the client browser.But what makes the EV SSL different from self signed ssl in case of dns spoofing?I am going to make traffic to that self signed ssl site only from my android client app, do i have make those checks myself (those checks which browser does upon getting ssl certificate)?

Generally speaking there are three types of certificates:

Self signed certificates:

These are certificates that are often generated by an internal certificate authority (CA) where the root certificate is injected in all clients. This way when visiting an internal web application over TLS, no certificate warnings are displayed to the end user.

Signed certificates:

These are certificates that are signed by public or internet facing certificate authorities (CA). The root certificates of these CA's come with the web browser.

EV signed certificates:

An EV certificate is the same as described in the section signed certificates however, by obtaining such certificate the issuer is required to retrieve a lot more information regarding the company requesting this certificate.

Extra checks are in place before the EV certificate is handed out.

  Does EV SSL certificate makes any difference while used instead of self signed SSL in case of API for android app?

Yes, it does make a difference and self signed certificates should not be used in production environments.

The difference is that with a self signed certificate, users are presented with a warning. In case of a man in the middle attack, the certificate is not valid and a user will also be presented with a warning.

Users that are taught to always accept these warnings are prone to man in the middle attacks.

When using a valid certificate, users are not displayed with certificate warnings. When a man in the middle attack takes place, the users will see a warning which should indicate something is wrong.

Nowadays there is no valid reason to use self signed certificates. Free certificates can be obtained quite easily. The use of an EV certificate would be overkill in my opinion.


Network and data security for small online businesses? What is the most efficient way of protecting small online business from outside threats. Everything too much expensive is not a solution.

I've been looking for good web application firewall and at the same time not expensive, since the business is using applications, but other than WAF, I need hardware security.

You can use open source  solutions for that and try to make it perfect based on your environment.

For IPS you can use Suricata engine.

For Firewall you can use PFSense or ClearOS.

For WAF you can use IronBee or wafw

For SIEM you can use AlieanVault OSSIM.

All the above products are free and open source, but some of them has missed feature and need to be paid to go with pro edition.

I hope this fits your requirements.

Rami,


Is HTTPS secure over public Wi-Fi with an expired certificate? I am staying at a hotel with free public Wi-Fi. To get Internet access I had to visit a web page and agree to the terms and conditions. This website has a security certificate, but it expired over a year ago.

Evidently this means I can't verify the identity of the sign in page for the Wi-Fi. If I proceed to the page anyway, does this compromise the security of other HTTPS websites in any way (say by enabling MITM attacks)?

I have read other threads on HTTPS over public Wi-Fi, and it seems like it's OK provided I verify the URL and only proceed if the website's certificates are trusted. But does the expired/untrusted certificate on the sign in page introduce any additional security risks?

So you were redirected to a captive portal page that had an expired certificate.

Theoretically this puts in risk only the data you transfer over this particular connection, ie. accepting the rules and eventually your personal or payment data if you had to provide any. In fact the captive portal did not have to use https connection at all and you wouldn't probably notice it.

It does not introduce additional risk to the fact that you are already using a public, potentially highly insecure network with all its consequences.

Mind that you were on the insecure network from the moment you established the connection, before you even opened a browser and were redirected to the portal.


Generating an unguessable token for confirmation e-mails I'm generating a token to be used when clicking on the link in a verification e-mail. I plan on using uniqid() but the output will be predictable allowing an attacker to bypass the confirmation e-mails.  My solution is to hash it. But that's still not enough because if the hash I'm using is discovered then it will still be predictable. The solution is to salt it. That I'm not sure how to do because if I use a function to give variable salt (e.g. in pseudocode hash(uniqid()+time())) then isn't the uniqueness of the hash no longer guaranteed? Should I use a constant hash and that would be good enough (e.g. hash(uniqid()+asd741))
I think all answers miss an important point. It needs to be unique. What if openssl_random_pseudo_bytes() procduces the same number twice? Then one user wouldn't be able to activate his account. Is people's counter argument that it's unlikely for it to produce the same number twice? That's why I was considering uniqid() because it's output is unique.
I guess I could use both and append them together.

You want unguessable randomness. Then, use unguessable randomness. Use openssl_random_pseudo_bytes() which will plug into the local cryptographically strong PRNG. Don't use rand() or mt_rand(), since these are predictable (mt_rand() is statistically good but it does not hold against sentient attackers). Don't compromise, use a good PRNG. Don't try to make something yourself by throwing in hash function and the like; only sorrow lies at the end of this path.

Generate 16 bytes, then encode them into a string if you need a string. bin2hex() encodes in hexadecimal; 16 bytes become 32 characters. base64_encode() encodes in Base64; 16 bytes become 24 characters (the last two of which being '=' signs).

16 bytes is 128 bits, that's the "safe value" making collisions so utterly improbable that you don't need to worry about them. Don't go below that unless you have a good reason (and, even then, don't go below 16 anyway).


What should a CRL file name look like when "new" and "delta" CRLs are generated? I suspect my Windows 20012 Certificate Server CRL revocation configuration is incorrect every time I generate a new CRL or a new Delta, only a maximum of 3 files are generated.

When I created the offline root (pictured below) it generated the file ``
When the offline root created its first certificate it signed with the name Root01+.crt

Partial Certificate Dump of what the root added to my certificate request file from the sub (policy) CA:

 2 Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:
          URL=http://classic.freesmime.com/Root01/Root01_.crt

I then looked on the file system and noticed that the intermediate was referencing a cert that was never created.  So I went to the root CA, clicked on the node that said "revoked certificates" and hit publish.

I then had the choice to create a new CRL file or create a delta.  I wasn't sure which one do to do so I did both of them (this is a test lab). I noticed that the following files were generated:

 ROOT01+.crl  (updated for Delta and new CRL)
 ROOT01.crl   (Updated only for new CRL)
 ROOT01_.crl  (Never updated ... only created when CA installed)

Question

So my question is.. is it correct that a given CA will have a maximum of 3 CRLs with a varying suffix as listed above?
Is it correct that a underscore name is never updated?

For those who read this far, here is an image of my CRL configuration within a MSFT offline CA:

Sorry for the large size, I'm on a Mac and think something is making the images appear too big

A "normal" setup with Microsoft's Certificate Services involves two CRL files: a base CRL and a delta CRL. The base CRL is destined to be referenced from a CRL Distribution Points extension in the issued certificate. The base CRL will contain a Freshest CRL extension which itself points to the delta CRL. Whenever a new base CRL is issued, a new delta CRL is issued immediately after; but the delta CRL can also be updated more often than the base CRL (and that's the point of using a delta CRL, by the way). By default, Certificate Services will force a new delta CRL whenever the previous one will soon expire, and also whenever a certificate is revoked.

You do not need more than these two files. Remember that a CRL has any value only insofar as clients (who validate certificates) can find them, and they find them by following the URL found in other objects. End-entity certificates contain one URL for CRL download, therefore the current CRL must always be stored under that name.

Furthermore, Certificate Services allows you to configure the names of both CRL (base and delta) only through a common setting, the two names differing only by the "<DeltaCRLAllowed>" keyword, which is replaced by an empty string for a base CRL, and a "+" sign for a delta CRL. That naming scheme is imposed; you cannot change it. (Incidentally, if you go for Web-based distribution of CRL and your Web server is IIS, then the "+" sign will cause you trouble; in order to allow IIS to serve the file, you have to activate double escaping.)

For the third file with an underscore, verify whether it is a ".crl" file (i.e. a CRL) or a ".crt" file (i.e. a certificate). It is normal and expected to have a copy of the CA certificate in that location. The name for that certificate will be derived (still by default) from the host name of the CA, and its domain name -- if you get nothing after the underscore, then I suppose that your CA is not part of an Active Directory domain. The CA certificate is referenced from the Authority Information Access extension of issued certificates, while CRL are referenced from the CRL Distribution Points extension of the same certificates.


Simple buffer overflow trying to leak address of system() Code:

#include <string.h>

void vuln(char *arg) {
    char buffer[10];
    strcpy(buffer, arg);
}

int main( int argc, char** argv ) {
    vuln(argv[1]);
    return 0;
}

I've determined I can input a buffer of 26 total characters to overwrite EIP. In gdb the address of

system():                      0xb7e41b40
"/bin/bash" portion of $SHELL: 0xbffffdac

if I run

run $(python -c "print ('a' * 22) + '\x40\x1b\xe4\xb7'+'FAKE'+'\xac\xfd\xff\xbf'")

in gdb it will drop me into a shell. Unfortunately this doesn't work in the shell due to ASLR. GDB tells me that strcpy is at 0xb7e7c750 which has an offset of 0x3AC10 from system(). What I'm thinking is if I can somehow store the address of strcpy at runtime and use the offset (and the offset to the string) I can get it to run system("/bin/bash") which is essentially what I'm doing in gdb without the ASLR.

Any tips or directions towards applicable documentation would be greatly appreciated. I'm trying to successfully exploit the bug without disabling any security measures.

Currently there's ASLR , PIE, ASCII Armor, NX (I'm assuming), and SSP (this is also assumed). I'm on Debian 9 stretch. Thank you!

Because you're not saying anything about RelRO, I'm assuming no RelRO (so no leaking of the address of strcpy because it isn't called yet). Yet, this doesn't matter much, here's why:

You say PIE is enabled, which in combination with ASLR will randomize the location of the binary in memory and thus the location of the PLT and GOT. Hence you cannot leak from the PLT or GOT because the locations are unknown.

There's a silver lining tho: You didn't say anything about the bitness. ASLR (and PIE) can be brute forced on 32 bit systems.

If you are on a 64 bit system, you are out of luck: The program is obviously designed to teach you the basics of binary exploitation and those are (successfully) mitigated by ASLR, PIE, NX and stack canaries.

If you want to learn the basics, you should deactivate the security features that mitigate those basic exploit techniques.


How to counter or fix banner grabbing vulnerability During an audit i came across banner grabbing findings,and would like to know how to mitigate that on IIS and apache server.

For IIS, you can use IISLockdown and for Apache you can set ServerSignature  to Off (more info here)


Jira external users verification I have a Jira site where my customers' employees can open bugs, view bug statuses and so on.

I manage these users inside my Jira (external users) and they have username and password with limited access rights.
About 100 customers, between 5-10 users per customer.

My questions are:

How can i verify that they still work for my customer and didn't
move to work for other company?
Or maybe they moved in to different role in the organization and don't need to access Jira any more?

1 is more critical then 2.

Thank you

A

It'd probably be very frustrating to do it for that many customers, but in theory you could do it via IP address filtering (only allow signins from customer IPs) and trust your customers to deny network access / VPN for people who have left.

You can also require that people sign up / sign in with their company (i.e. your customer) email address. Then you could do something to make accounts deactivate unless the users click a "yes, I still have this account" link (with a unique random token in it) every so often, like 1/month, and only sent those links to customer email addresses. That'd take some setup work and be a little annoying to the users, but it would limit the amount of time somebody could get access.

If your customers are using something like Google Apps (or whatever they call it now) and the users are using SSO to sign into Jira, then you're probably fine; your customers should revoke access to the accounts of anybody who leaves, which will also mean they can't access your Jira. That doesn't work for usernames and passwords, though.

Alternatively, you can just ask your customers to tell you when people leave (or change roles in a meaningful way). It's not foolproof, of course, but presumably they already have a system in place for handling employees leaving; they can just add "notify the Jira admin" to that list.


Different password for each login - based on some variable This might sound a silly question, but I was thinking this as and extra option(which is not required) mainly for advanced users, who want to protect their accounts even more. Lets consider that other security measures exist(e.g. protection against online brute force attacks, requiring strong passwords when registering/updating the password, warning the user for possible failed login attempts, requiring some extra info when logining in from unknown IP or between two distance locations within short period of time, showing the list of active sessions (like in gmail), 2 factor auth etc.). So, this is like trying to add extra layer of security.

Here is the idea. When the user activates this security option, he has to choose the variable type that he should concatenate to his usual password when trying to login. E.g. the user can choose the current (day + 7). So, if my password is myPassword, and today's date is 11, then I have to type myPassword18. Which means that if I have to login on another day I will have to insert another "total" password - based on that day. Of course the date is an example, it can be different variable type, e.g. the first 3 letters of my current ip address (in case if the user frequently logs in from different locations), maybe smth associated with a browser(and/or its version), so the idea is to have smth that constantly changes, but the user can easily identify that change and make the right input.

Though this will create issues with browser's password autocomplete, but who do not need that autocomplete, I guess it will be no problem from that viewpoint.

Validating the user's password during login:
I am using password hashing/validation as it is described here https://crackstation.net/hashing-security.htm#properhashing

so, the hashing part looks without issues, and I am hashing only the myPassword part of course. During validation when I fetch the user's data from the database I can check and see that that option is enabled, and based on the user's choice I can calculate what should be concatenated to the "main" password, so it will be checked and if valid, will be cut from the string for validating the password.

So,

If that security option is disabled it will be a usual password validation
If enabled, lets say the user chose current (day + 7) option, then I know that the password should end with 18, if it does not - then login failed. If its correct I will delete that 18 from the password provided by the user and check the remaining string's validity comparing it with the password's hash that was fetched from the db.

I admit that overall this makes the login process more complex (which is bad), but on the other hand I guess it might be helpful if someone saw your password (directly or maybe through keylogger, or just when you accidentally clicked save in a non-trusted computer), because next time that variable part(possibly) will be changed and that last number/string will be already smth else, and if the malicious user tried to login, the account owner will be notified that someone tried to login from whatever ip/location, providing a valid password (the first part), though failing to give the correct second parameter(variable part), which might help the user to change the "main" password and/or the password variable part.

Any ideas whether this might boost the security or there are some flaws that I did not consider that will have the opposite effect ?

Thanks

While this is an interesting idea, I would suggest keeping it normal as you have it but give users option for 2 factor authentication in their account settings.

In this when a user successfully enters their credentials, they would be emailed a link to click / follow. Once followed their session would be started.

You have to assume your clients are stupid, over complication login features with variating passwords will confuse them.

as for extra features for security many websites use features such as:

approved devices
2 factor authentication
advanced logging
IP restrictions
fail2ban (x amount of tries = lockout)
advanced analytics suggesting the real person isn't using the account (common with banks)

I hope some of these features give you some good ideas.

WARNING:

Your idea might interfer with password security, adding data onto the end of a hashed password could cause numerous errors, you should never be able to decrypt passwords and to do this something like this right you would want to change the password hashes in the database to have that number added onto it. I see you did mention hash and therefore you cant reverse the obfuscation. Though once again I do suggest that you avoid your idea as if this is a feature everyone knows about it.

anyway I imagine you would do this number feature would either be:

Predictable and therefore pointless (if i was a hacker I would simply expect this)
dirty coding forcing the feature rather than applying extra security


GnuPG can see a card under root user, but not under normal user When under an unprivileged user:

$ gpg --card-status
gpg: selecting openpgp failed: No such device
gpg: OpenPGP card not available: No such device

With sudo or under a root user:

$ sudo gpg --card-status
Reader ...........: ...

Problem similar to that circa 2011.

When comparing with a different card reader it is immediately obvious a permission problem.

$ getfacl /dev/bus/usb/003/021
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/003/021
# owner: root
# group: root
user::rw-
user:sanmai:rw-
group::rw-
mask::rw-
other::r--

Where for the problematic card reader there's no extra user permission:

$ getfacl /dev/bus/usb/003/020
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/003/020
# owner: root
# group: root
user::rw-
group::rw-
other::r--

Under Debian-based these extra permissions are set by udev rules:

cat /lib/udev/rules.d/60-scdaemon.rules

These rules can be extended by adding a line to, say, /etc/udev/rules.d/60-scdaemon-local.rules with vendor and product IDs of the problematic reader:

SUBSYSTEM=="usb", ATTR{idVendor}=="xxxx", ATTR{idProduct}=="yyyy", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg"

Then reloading the rules:

udevadm control --reload-rules


What are potential risks of using PGP for website login? I'm currently using a login system outlined below:

String of 1000 characters is generated on the server each time the website is opened and works for maximum of 5 minutes at which point a new string is generated which will be in memory until next login
String is then encrypted using my public key which is stored on the server
PGP encrypted message is then shown on the login page
After I decrypt PGP message using my private key I copy/paste the decrypted message onto the login page
and finally server-side script compares the decrypted message to the string generated in step 1 and after login previously generated string is no longer available

Pros of using this system:

password is only stored in server memory for a very short time
PGP message can only be decrypted using my private key(RSA - 4096 bits) AND my passphrase

Cons:

inconvenience
my implementation might be flawed

This is for educational purposes only, and won't be used on any production system.

I also uploaded the code to github if anyone wants to see the code

What are some of the potential security risks of using such system?

As this is for education/learning purposes and not a production solution, the normal warnings about not rolling your own security solutions don't apply. However, still strongly recommend looking at some of the established solutions - possibly doing so after attempting your own solution is a good idea as you may understand why things are done a certain way or some of the issues a little more.

Some things to consider with your solution (just off the top of my head, no real deep thought).

Cut and paste - or using the clipboard generally has a number of security risks. Last time I looked (a while ago now), Metasploit even had a module which you could use to steal the contents of the clipboard.
Your scheme is really only providing assurances in one direction. There is nothing which would prevent me from getting your public key, spoofing the site and then creating a situation where you think your authenticating against the site, but are actually authenticating against my spoofed site. Similar issues with man in the middle attack - attacker can simply pass through the encrypted string to you, get back your decrypted version and then login to the site. You will need to ensure your connections are over SSL with a valid and verifiable SSL certificate.
Randomness of 1000 character string. This is often the big weakness. It is vary hard to generate true randomness and is why some programs which require randomness will do things like require you to move the mouse around while the random value is being generated. If your initial 1000 character string is at all predictable, then it would be possible to narrow the search space for decrypted versions of the string and effectively bypass the need to have your private key to decrypt it.


What is meant by IPSec is "transparent" While reading a guide on IPSec, i came across this sentence:

  IPSec is transparent to the user and the applications.

Can someone please tell me what is meant by being transparent from security view point?

Nothing. Transparent means it does not change anything for the user and application, so you don't have to rewrite your apps to use it, unlike TLS. You don't have to copy certificates and keys around etc. It is basically an ease of use thing. You just enable it and it works.


Should I really treat memory leaks like classical bandwith dos? I recently found that a big company use an outdated product in their file-storage servers (I got the hidden name and version). The bug is corrected in recent version, but they weren’t any cve or exploit until I create them. (their is still no cve and many distributions still sheep affected git packages in current branches)
They do set limits on ram usage on their http backends but not on their virtual storage servers (a single process can stall the server on swaps)
They do per account load balancing which means each storage server contains the entire data of http accounts (they have hundreds thousands accounts). I was unable to find how many they have, but considering their site is a top web site (in terms of worldwide traffic) I just guess this should be a lot.
I tried the issue and finally crashed one of their storage server during several hours with a single crafted request (the http server was sending 500 pages to the users trying to access the accounts stored on it)
I apologised and mailed them about the behaviour. I raised the concern of a larger scale attack that would shut down all file servers leaded by a team of 5~10 peoples without requiring botnets.

Hello again,
In these cases we feel that our compensating controls can make this significantly harder to exploit. You are probably correct that all of these things are possible and ideally would be fixed, but we consider this to be very low risk. I'm very impressed with the investigations you have done !

They really seems to treat this like classical attacks from botnets affecting bandwidth.
I learned to always update software that suffer from exploitable memory leaks. However I’m only a student, I have no experience at managing such a large website (~47 valid requests per minutes). But here are some points :

According to their status page, none of the classical dos attacks they faced impacted users (which isn’t the case here)
While their “controls” might prevent the whole site to be put offline, it definitely won’t prevent a large downtime of several of their storage servers (affecting thousands users).
The purpose of the site is to host software, it’s perfectly possible to target the most downloaded ones.
Since storage servers have 50Gb of ram I don’t think they have so much of them (I don’t know if large needs like this can require a >20Tb of ram)
It can only be used for dos. There is no longer possibility for things like remote code execution.
Once a storage server recovered, it’s possible to put it down again immediately since nothing prevent a crafted request to be made from a different machine with a different ip and it don’t require to log‑in (then the repository is unavailable most of the time for several days)
In the meantime, they do many things to prevent a push request from filling ram, like limit the maximum object size, or disallow deep nested tree objects. They also took actions on a prior problem allowing ram exhaustion from one of my report.

Something I can’t understand is they worry about non‑root remote code execution on a single of those server whereas the software that power them is public (they don’t worry about the fact a large part of their configuration is accessible from outside).
So are there situations where keeping exploitable memory leaks is Ok ? (only 1.2Gb of network data is required for stalling a 50Gb server)
Or more generally, should ram be limited on ɢɪᴛ servers ?

The answer to this comes down to a risk-management decision that the organization makes. There are best practices, but even the bestest of practices can be compromised by risk-management decisions. There are no absolutes, even patch broken stuff is not an absolute.

You had a clue in their response:

  compensating controls

This phrase is used to justify leaving potentially breaking code in place. The compensation could be anything, but whatever it is limits the scope of the exploit in such a way that it isn't an SLA-threatening problem. Perhaps the exploitable leak causes a brief outage in a small percentage of overall users, which in the grand scheme of their SLA monitoring gets lost in the statistical noise.

It is also entirely possible that they've misunderstood the magnitude of what you've found. Unfortunately, only they can judge whether or not their compensating controls are sufficient.

As the reporter, your role here is to provide them with a clear assessment of the risks this presents. You will be more effective in changing their perception of the risks if you can provide a realistic scenario where this weakness can be leveraged to a wide-spread outage. Be specific, try not to invoke mega-scale botnets, and a reasonable assessment of how easy the problem would be to exploit once the weakness is known it exist. Use terminology from the Common Vulnerability Scoring System; or better yet, cite any CVE numbers for the problem.


How can someone access data that I am requesting when I use HTTP? I have heard that HTTP use plain text communication. If it is so how can a hacker or someone tap it. From my little knowledge I know that if we sent a request to a web server it replies back to us using our IP address. So if an attacker wants to know what I am doing, how does he do it? Is it necessary to know my IP address or does he intercept it in between? Or is it like this: an attacker decides to attack someone and he picks some data and he finds that this belong to say X, which means does he attack randomly?

When you access a website, say Google, your request goes through multiple steps (nodes) until it reaches its final destination. The first node is your home router, then your ISP's routers, and then other big routers, and then Google's routers. At any of these nodes, your request is momentarily stored in the devices' memory, which means it can be accessed by an attacker. Of course, that's not a very likely situation.

The bad news is that an attacker could somehow trick your computer into thinking that his computer is a real node in the path between you and a legitimate node. This attack is called a man-in-the-middle (MiTM) attack. MiTM come in many shapes and forms, the most famous ones are:

ARP Spoofing
DNS Cache Poisoning
DHCP Spoofing

I won't go through each type because it will make this answer too big, but please have a look at pages and learn more about these attacks.

As a solution to this problem, we have HTTPS. It works by layering HTTP over SSL/TLS to make sure that your request is going from your browser to the intended server and making sure that anyone snooping around won't be able to see what the request or response you get from the server contain.


Blocking a redirect link in an iframe on a chat site There is a shortened link being spread which contains an @ symbol. j.mp/s@mething, and it's used for phishing purposes.
When trying to block it, for some reason it doesn't like the @ character

I want to know the bit.ly protocol and what code I can use to block this.
http and https don't work for it.

See if using X-Frame-Options header helps, as you want to block it within an iframe. For more information, please refer below link:

https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet

You may also want to look at below link to understand how a URL Shortener works.
https://stackoverflow.com/questions/4572734/how-does-a-url-shortener-work


Drop privileges after startup or start as unprivileged user? Given a service that needs access to some secrets from a config file to start, I can imagine three approaches:

1) Keep the file readable only by root. Start the process as root, read the config and drop privileges.

2) Keep the file readable only by daemon user, start the process as the daemon user.

3) Keep the file readable only by root. Start the process as the daemon user with the CAP_DAC_READ_SEARCH capability and drop it after reading the config.

My initial analysis of the alternatives:

Option 1

+ If there's a vulnerability an attacker needs to read own process memory to get sensitive data (fairly hard?)

- More complex due to need for setuid/setgid

- If the software is compromised before dropping privileges it'll run as root

Option 2

+ simpler to program, drop privileges from init script

- If there's a vulnerability an attacker can read sensitive data from disk (easy)

Option 3

+ Never gives full root access to the process

+ If there's a bug an attacker would have to read process memory instead of just a file

- Plenty complex

- Still gives very broad access to reading files outside the config file (like /etc/shadow and similar)

Are there any other options that should be considered, or pros or cons I have missed? Are there any good reasons to handle privilege dropping yourself instead of letting the init process handle it?

Avoid giving the daemon privileges it doesn't need, even for startup. This rules out option 1 and 3. It doesn't mean you have to go for option 2 though.

First let me recall the basics, just in case:

Run the daemon as a dedicated user, that runs this service only.
Don't allow the daemon to modify its configuration files. This means that all configuration files must be owned by a different user. Support for ACL is ubiquitous these days, so have root or some other user own the configuration files, and use an ACL to allow the daemon's user or group to read them.

Whether there's significant benefit to preventing the daemon to read sensitive configuration files after startup depends on what it uses the sensitive data for and what else it does. If these are credentials that the daemon uses only once during startup and then wipes from memory, there's a benefit to making it impossible to read them again later. If the sensitive data remains in memory there isn't that much benefit, but it also depends which is the most likely: an exploit that allows memory disclosure but not arbitrary code execution (e.g. uninitialized memory or bad pointer — although those usually do allow arbitrary code execution), or an exploit that allows file disclosure but dot arbitrary code execution (e.g. bad path sanitization).

If you decide that the protection of not allowing the daemon to read the sensitive file after startup is beneficial, then let the init system manage the privilege dropping. Open the configuration file from the supervisor process, then drop the associated privilege (a supplementary group, presumably), and pass the file descriptor to the process (--sensitive-config-fd=3 or --sensitive-config-file=/dev/fd/3).


How does DNS over TLS prevent your ISP from seeing the websites you visit? For example, I'm using DNS over TLS in Android Pie. This happens:

I visit a website (google.com).
I send a DNS query to the DNS server, and the response is the IP address of google.com. The ISP knows I contacted the DNS server, but doesn't know the query or the response.
Next, I connect to the IP of google.com. The ISP knows I contacted google.com's IP now.

And yet, news articles (and some questions in this site) says that the ISP won't see the websites you visit if you use DNS over TLS. Am I missing something here?

It doesn't. DNS over TLS is not designed to keep your privacy from ISP. Like HTTP,  DNS is vulnerable to MITM. DNS over TLS provides the same level of security as HTTPS.

As DNS over TLS is encrypted, your ISP can't see the domains you query for but they don't have to. TLS uses Server Name Indication, a TLS extension which appears on the outside of HTTP host header. SNI field contains the domain name of the server you want to talk to. Once you visit that site, your ISP can see that unless you use a VPN.

Cloudfare has recently released support support for encrypted SNI(ESNI) for the websites that are hosted by Cloudfare. This actually prevents your ISP from seeing the site you visit provided you are also using DNS over TLS. But for ESNI to work browsers have to natively support it. Mozilla landed support for ESNI in Firefox Nightly, so you can now browse Cloudflare websites without leaking the plaintext SNI TLS extension to on-path observers ISPs, coffee-shop owners, firewalls.


Is there vulnerabilities that are inherent to the concept of an open source antivirus? I read that antivirus opensource software would be a good idea since the database could be informed and mainained by lots of capable people. However I have also read arguments to the contrary but none really explaining why.

Is an open source antivirus for windows a bad idea or a good idea?

I digress the notion that an open source antivirus database will necessarily be maintained by lots of capable people - this is not how open source works. The principles of open source would entice those that are not motivated by direct financial gain - whether these individuals are highly capable, or not - that is a question of chance or self motivation.

Also, there are two components at play - one is the antivirus engine itself, the second being the definitions database.

While I am certain that a couple of open source antivirus engines are adequate (e.g. ClamAV), maintaining an up-to-date database of virus signatures (and heuristics, for that matter), is a task that requires a vigorous vetting and testing process that would avoid false positives and risk making systems or software inoperable. Not that commercial antivirus vendors are immune to that problem - they are not, but I always look at efforts such as Wikipedia, where it works great to somewhat educate the general public, but it is questionable whether that model would work for an antivirus effort.

The Linux kernel, on the other side, is an open source effort that has had a great success in powering many critical systems. Whether that collaboration model can be used for an antivirus database, where the time from malware discovery to signature creation is critical, remains to be seen.

Overall, I am of the opinion that the idea of "people's" antivirus is good, but the implementation would be a major challenge - the signatures bit especially.


Securely displaying hidden integers with MD5 A system I'm studying uses the following mechanism: a 19-digit integer is hashed via the MD5 algorithm and the salt of the integer is shown in plain sight to the user before they take an irreversible action relevant to trying to guess the first 2 digits of said number.

My intuition is that this is not secure. With 10^19 possible results for each particular implementation and a 2-minute lifetime of a single entry, as well as capabilities of modern GPUs, I just don't feel giving the okay to rolling this out.

I tried to use a hashcat mask bruteforce with a somewhat high-end graphics card off my personal computer give very reassuring results of a time way exceeding two minutes, yet intuition seems to hint at something I'm missing.

Am I?

This very high end GPU cracker performs 200GH/s:

https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a270c40

That's 200 billion hashes per second (2e11 hashes/s).  With a search space of 1e19 possible numbers, that means it will take ~500,000 seconds (about 1.5 years) to exhaustively search parameter space.  Of course on average you'll find a match in half of that time.

In short, MD5 is a fast algorithm, which normally means brute force is easy.  However in this case the large size of your search space negates a lot of that.

Depending on what happens for a successful user though, MD5 still might not be the best choice.  A top end hashing rig is too slow by a factor of ~200,000.  That seems like a lot, but you're basically asking "How long until my hardware might be 200,000x faster?".  While the growth pace of computer hardware has slowed, it's not unrealistic to expect that gap to shrink substantially in just a few years.

Finally, you also have to be concerned about weaknesses in pre-image resistance.  I haven't "checked in" on MD5's status in a while, but last I heard MD5 was still pre-image resistant.  Other aspects of MD5's cryptographic security have been broken (aka it is no longer collision resistant, although that is not relevant here).  Therefore, while MD5 is still pre-image resistant, that could change any day.  Without pre-image resistance an attacker might come up with a technique to find a payload that gives the same hash as your number, without having to actually brute-force the number.

In short, you are safe at the moment.  The safety margin though is perhaps not that high.  Whether or not you need to take action depends on what you are securing on the other side of this.


UserName and Password information can be seen on https During scanning my https website via owasp zap , I found that username and password information is not encrypted. What could be the reason and how to fix. Please see below screenshot of ZAP.

OWASP ZAP is like a MITM proxy very similar to Burp suite.Ofcourse it can read the https because you must have installed a Root CA certificate while setting it up.There is nothing wrong with your website in regards to your question


How far a VPN service is legal? Does it makes my data vunerable for hackers? Today, in Brazil, the government suspended by judicial requirement the WhatsApp application for 48 hours. It is a messaging app that works only via Internet connection (3G, 4G, WiFi...) and not by carrier services.

This block can now be bypassed by configuring a VPN. People in the country are downloading free VPN apps that can liberate the access in a massive way, but don't even know what really a VPN does, or what it is.

Is this practice legal? And how this service could harm any data on the device? I am asking this because I've seen kids and people with no knowledge on network doing this like never before, even my entire family.

A VPN is a virtual private network. It can literally be understood by simply breaking down the words:

  Virtual - Because instead of being physical it's virtual or artificial
  (software only)

  Private - Because the communications between your computer and the VPN
  are protected through encryption, virtual tunneling protocols, or the use of dedicated (private) connections.

  Network - (obvious)

When you connect to a VPN, you're really making an encrypted (or otherwise private) connection to another device to be able to access a virtual network on that device as if you were physically connected to that network (just like a LAN). If the VPN acts as a "gateway" and is itself connected to the Internet, then it can share its Internet connection with any device connected to it. This means that when you're using the Internet on your VPN-connected device, it's really utilizing the Internet capabilities of the VPN itself (bypassing any Internet-based restrictions on the device that's connecting to the VPN, and replacing them with any possible restrictions set on the VPN itself).

Since you're relying on the VPN to give you Internet access, it will usually degrade not only your ping time, but also your bandwidth. Also you will have to trust that VPN not to perform Man-in-the-Middle type attacks on your Internet, and to not attempt to access your physical LAN or LAN-connected devices. So yes, there is a degree of risk involved in that aspect.

As for the legalities, it could very well be illegal and more than likely is illegal to bypass any kinds of restrictions that your government had set in place. However in order to find out for sure I would recommend doing your own research on that subject. My advice is, just don't do it. Wait 48 hours and see what happens.


Associate guest orders with account if email matches? A web shop allows orders from guests. When checking out, the guest has to provide an email address (in addition to shipping address and payment data). When this email address is already in use by a registered shop user, the guest order shall be associated with this user account.

Would it be secure to associate the guest order with the user account automatically, without requiring the guest to login beforehand (to prove that the guest is the one claiming to be)?

What could happen (in the worst case) when the guest has malicious intent?

Scenario: Alice is registered with her mail address. Bob knows this and orders something [providing shipping address and payment data of him|Alice|someone else] as a guest, entering Alice’s mail address.

Social engineering would be the only attack vector that occurs to me here. Which might be especially painful when the guest selected payment in advance (resp. per invoice) and the user is somehow tricked into paying for an order that gets shipped to the guest.

No, no no.   This is not a good idea under any circumstances.  Guest orders are guest orders, period.  They require contact information, shipping information, and payment information...Always.

Logging in provides the convenience of having none/some/all of this information pre-populated, and it's a requirement for having orders automatically associated to an account.   Without a login process, you'd be essentially authenticating a user based on email address alone, which could never be sufficient.

The only reasonable compromise I see if that if a guest user creates an order using the email address of a known user, add it to a queue and the next time that user logs into the site you might then ask them if it was their order and if perhaps they'd like to add it to their account for tracking/record keeping purposes, and give them the option to either confirm or deny that it was theirs.

Associating it to their account automatically would simply be a bad idea, not only for the reasons that you and GoD have already stated, but from a user experience perspective in any case that isn't on the happy (designed use) path.


Why is referer checking needed for Django to prevent CSRF Today I learned that Django's CSRF protection uses refer(r)er header checking in addition to checking a hidden form field against a cookie. It seems to be important, judging from docs and issue below.

It only checks this over HTTPS though. I've also noticed that almost no other website checks referer [since I turned off sending of said header and most forms still work].

So I have two questions:

How would the attack work that would be possible without this check? Doesn't https protect against man-in-the-middle attacks?
How do other websites protect against it? And does Django not project for http?

The info that I found:

https://docs.djangoproject.com/en/1.8/ref/csrf/#how-it-works

  In addition, for HTTPS requests, strict referer checking is done by CsrfViewMiddleware. This is necessary to address a Man-In-The-Middle attack that is possible under HTTPS when using a session independent nonce, due to the fact that HTTP ‘Set-Cookie’ headers are (unfortunately) accepted by clients that are talking to a site under HTTPS. (Referer checking is not done for HTTP requests because the presence of the Referer header is not reliable enough under HTTP.)

https://code.djangoproject.com/ticket/16870

  Unfortunately, this check is absolutely necessary for the security of Django's CSRF protection. Without it, we can't prevent man-in-the-middle attacks on SSL sites. We made the decision that preventing MITM was a more valuable tradeoff than breaking sites for the small minority of users who block the header in a fashion which does not improve privacy.

First of all, thanks for the interesting question. I did not know about the details of CSRF before and had to look up the answer to your question myself, but I think I know the correct explanation for Django's behavior now.

The Django developers are treating HTTP and HTTPS refers differently because users expect different things from insecure and secure web services. More specifically, if a web page is using transport layer security, users expect to be protected against man-in-the-middle attacks, meaning they trust in the principle that even if someone sat directly between them and the remote server and intercepted every single message, they couldn't make any use of that information. Note that this is not expected of plain HTTP connections.

Now consider the following scenario, quoted from a Django dev's post here :

  user browses to http://example.com/
  a MITM modifies the page that is returned, so that is has a POST
  form which targets https://example.com/detonate-bomb/ . The MITM has
  to include a CSRF token, but that's not a problem because
  he can invent one and send a CSRF cookie to match.
  the POST form is submitted by javascript from the user's browser
  and so includes the CSRF cookie, a matching CSRF token and the
  user's session cookie, and so will be accepted.

I did not instantly understand this attack myself, so I'm gonna try to explain the details. Note first that we are looking at a page that displays forms over plain connections but submits data via SSL/TLS. Part of the problem, as I understand it, is that the cookie and hidden form value (aka "the CSRF token") are only compared against each other, not against any value that is stored server-side. This makes it easy for the attacker to supply their victim with a cookie-token-combination that will be accepted by the server - remember, the page displaying the form is not secured, so Set-Cookie headers and the contents of the form itself can be spoofed. Once the manipulated form is submitted (via injected JS, for example), the server sees a perfectly valid request.

Adding strict Referer checking is the answer to this exact problem. Checking these headers, only requests originating from https://example.com will be accepted at another endpoint of https://example.com. Insecure pages from the same domain will be treated as completely untrusted, and rightly so.

Now to come back to the question why plain HTTP requests are treated differently, we just have to imagine a site that doesn't use encryption at all. In that case, a man in the middle could also spoof the Referer headers sent with the actual form data, so checking those does not provide any additional security. In other words: There is no protection against CSRF attacks by a man in the middle - but, as I mentioned earlier, users do not expect this kind of security from plain HTTP sites.

Regarding your question about how other web frameworks handle this attack vector, I honestly have to say I don't know.


Why does the PSD2 have an exception that requires two-factor authentication only every 90 days? PSD2 requires two-factor authentication, which they call strong customer authentication (SCA). However, there is a “delegated regulation” 2018/389, Article 10, which adds an exception that SCA is not required to view account information, specifically the account balance and transactions from the last 90 days.
That article also has an exception to the exception stating:

For the purpose of paragraph 1, payment service providers shall not be exempted from the application of strong customer authentication where either of the following condition is met:
[…]
(b) more than 90 days have elapsed since the last time the payment service user accessed online the information specified in paragraph 1(b) and strong customer authentication was applied.

I would like to know how requiring SCA every 90 days improves security over not requiring SCA at all, at least for viewing account information.

As an example, for my bank, this means that the login to their online banking requires the second factor every 90 days. They even show a notification before the 90 days have expired so I can re-start the 90-day period early, which means that my account is always “activated”. This does not seem to be very uncommon, at least in Germany.
In fact, I feel this lessens security because the ChipTAN device that is my second factor only shows a cryptic “start code”, so I'm not sure if the action I'm authenticating is in fact a renewal of the 90-day period or something else. For example, when accessing transactions older than 90 days, I get the same “start code” prompt.

TLDR:

If the bank is requiring 2FA every 90 days for login only, but requires it for every payment (see exceptions below, e.g. recurrent payments to the same receiver), then your bank seems to seek for balance between security and friendliness, and seems to be compliant with PSD2.
If the bank requires 2FA once every 90 days also for payments, then this very probably violates the PSD2 requirements and does not improve security.

Details:
The PSD2 defines what operations have higher risks and need a "strong customer authentication".

Where payment service  providers apply strong customer authentication
in  accordance with  Article  97(1)  of Directive (EU)  2015/2366, the
authentication shall  be  based on  two  or  more  elements which  are
categorised  as knowledge, possession and inherence and shall result
in the generation of an authentication code.

To put it simple, "strong customer authentication" is a multi-factor authentication, 2FA or stronger.
Mainly, this "strong customer authentication" is applicable to payments:

The  requirements of  strong customer  authentication apply  to
payments initiated  by  the  payer...

More security often means less friendliness and worse user experience. The PSD2 tries to find a balance.

... exemptions  to  the  principle of  strong customer authentication
have been defined based on the level of risk, amount, recurrence and
the payment channel used for the execution of the payment transaction.

Try to travel to Afghanistan or Marocco and login to your account. Very probably you will be asked for 2FA. Why? Because the rule above was applied: You are using other channel that has higher risk compared to access from your country.
The rule above defines basic principles. Briefly: risk estimation should take into account many different factors.
The PSD2 defines also exceptions. For instance:

Actions which imply access to the balance and the recent transactions
of a payment account without disclosure of  sensitive payment data,
recurring  payments to  the  same  payees  which  have  been
previously set  up  or confirmed by the payer through the use of
strong customer authentication, and payments to and from the same
natural or  legal  person with  accounts with  the  same  payment
service  provider,  pose  a  low  level  of  risk,  thus allowing
payment service  providers not  to  apply strong customer
authentication.

This means that if you only login to your account and don't do any payments, your bank is not required to apply "strong customer authentication". Some banks require 2FA also for login. Your bank uses this formal right not to do that.
One of factors for such decision may be recurrence. Try to login 1000 times a day, even without doing any payments. I would suppose that your bank will require 2FA not after 90 days, but very shortly, after you have reached some number of logins that your bunk considers as suspicious.
The requirement mentioned above allows to see the recent transactions without "strong customer authentication". When you want to see your history older than 90 days your bank considers this as not recent transactions and, according to this rule, requires "strong customer authentication", in your case it requires 2FA.
Requiring 2FA every 90 days is not a requirement of PSD2, but decision of your bank. The security benefits of doing that are very small. An attacker that knows your PIN will just use it between these dates, and let say will add 10 days before and 10  days after the date when the next 2FA may be requested, and use your PIN 70 days freely. The only security benefit I see is that when the bank is asking for 2FA they can be sure that the TAN device is not stolen and you still have it. The banks that want to have balance between security and user experience ask for a 2nd factor not in a regular interval, but at some unpredictable moments. Thus the attacker would not benefit from knowing that the bank asks for the 2nd factor only once every 90 days. I suppose your bank does not consider that as a risk.


Obtaining the public DNSSEC root key Is the public DNSKEY of the DNS root zone that I have to trust when validating a DNSSEC key chain usually bundled with an OS? If so where is it located under Ubuntu 15.04, Linux?

What is otherwise the method to obtain it, that is considered "safe"?

I am using dig +nocomments +nostats +nocmd +noquestion -t dnskey . > trusted-key.key at the moment but I'd be interested in what the theoretically preferred solution of obtaining it would be.

apt-get install dns-root-data works on Ubuntu, at least in 16.04 and up. It also works on recent Debian.


Explanation of modern PGP? wikipedia states that OpenPGP is currently defined with RFC 4880 which defines a very simple process that doesn't seem like it represents modern RSA + AES encrypted email:

  The sender creates a message.
  The sending OpenPGP generates a random number to be used as a
      session key for this message only.
  The session key is encrypted using each recipient's public key.
      These "encrypted session keys" start the message.
  The sending OpenPGP encrypts the message using the session key,
      which forms the remainder of the message.  Note that the message
      is also usually compressed.
  The receiving OpenPGP decrypts the session key using the
      recipient's private key.
  The receiving OpenPGP decrypts the message using the session key.
      If the message was compressed, it will be decompressed.

Where is the PKCS v1.5 or OAEP padding? Where is the hash/hmac integrity check? Where is the signature?

Can someone detail the actual modern PGP process or point me to a more complete explanation of the process?

Where is the PKCS v1.5 or OAEP padding?

For RSA, PKCS1v1.5 is in 5.1. The other kind of publickey encryption used by PGP and described in the same section, usually written El Gamal or abbreviated EG but here written Elgamal, is already randomized and doesn't need to pad the encrypted data, which is for either algorithm a slightly modified form of the 'session' key. (Since PGP is designed and used in a way that I don't consider to really be a session, I often substitute the more generic term DEK = Data Encryption Key.)

  Where is the hash/hmac integrity check?

That's a 'recent' (this century) addition.
See 5.13
and 5.14.

  Where is the signature?

2.1 is only confidentiality. The next section introduces Authentication via Digital Signature and the details are in 5.2
and 5.4
although it's a bit tedious to disentangle signing of data from signing of keys which is more complicated but a vital part of PGP.


How can I view images in forwarded packets on (current) Mac OS X? How can I view reassembled images on a Mac being used as a router? I'd like to do this as a demonstration of how HTTP doesn't provide privacy.

I've done some research, and on Linux there's a tool called Driftnet which does this. OS X once had EtherPeg but it's no longer maintained.

How can I reassemble images in forwarded HTTP traffic?

mitmproxy (http://mitmproxy.org) is a free tool for man-in-the-middling HTTP traffic and can accomplish this in a few ways.

The most straightforward and easy to demonstrate would be to use the web interface (mitmweb) which would allow you to click on individual image requests and see the image in your browser.

Since you're using your host as a router, you'll want to enable packet forwarding in OS X and enable transparent mode in mitmweb (-T) and do some pfctl magic to forward the HTTP traffic to the port mitmproxy is running on.

http://mitmproxy.org/doc/transparent/osx.html


What is the most secured UEFI publicly available? It is very scary to know that spywares were installed on some largely commerciallized laptops at the BIOS level. Example: Lenovo ThinkPad spyware

What UEFI would you recommand to have in order to track any possible spyware.

I would need full monitoring of every UEFI activity and if possible make it available at the OS level

The way you ask this shows you haven't understood the problem to its fullest extent:

  I would need full monitoring of every EUFI activity and if possible make it available at the OS level

The UEFI potentially runs at privilege levels higher than any software that you can execute on your system. Hence, it's untraceable, unless it wants to be traced.

You might want to watch this talk introducing the privilege levels that UEFI can enter..

And, also, that talk demonstrates how to gain these same privileges to mess with what would normally firmware protected from modification.

In other words: While there is free and open source UEFI firmware for a couple of notebooks (google: coreboot), there's no absolute security.


Is it safe to run a potentially malicious ISO in a VM using VirtualBox? I want to try out an OS called "Red Star OS". I want to make it a completely isolated VM, no network connectivity etc., just to explore and take a look at it. I found out where to get it from this article.

I was just curious if it's safe to run in a VM and what I should look out for when doing this.

You cannot be entirely sure it is safe to do so by the simple fact that when you download a potentially infected ISO, it may be enough for the malware to trigger and do whatever damage it's programmed to do on the host system.
There are backdoors that may be successfully deployed only by previewing an infected file in thumbnail mode on Windows Explorer.

Now assuming the malware is only in the OS contained in the ISO, I would say that unless it contains specific payloads which would target virtualization software hence escaping VM constraints, you should be fine if you do not enable networking, do not share drives, do not allocate excessive resources and do not give access to peripherals to the VM.


Difference between virus and trojan? To my current understanding:

A virus is a program that does not self replicate and relies on the host file being spread. It has malicious intent.
A trojan is a program that is run by deceiving the user into appearing to be something legitimate, but has malicious intent.

How are these different? To get a user to install a virus doesn't it always require appearing as something legitimate?

Or does a trojan program run as expected so for example if it was a game it would work fine but have done something malicious without the user knowing, whereas a virus wouldn't?

Can anybody clarify this for me?

Traditionally a virus is malware which uses the infected host to replicate itself to other systems, i.e. by infecting files which might get shared, copying itself to network drives or USB sticks. It gets usually not knowingly executed by the user but gets executed when the user opens an infected file, runs an infected program etc.

A trojan is a malware which claims to be something different, like some malware claiming to be a virus scanner. It counts on the user to execute it knowingly by believing what the software claims to be.

In common language often any kind of malware is simply called virus, i.e. real viruses, trojans, ransomware etc. For example a virus scanner also cares about all types of malware, not only viruses.


Is it bad to use DKIM DNS without signing mails? Does it provide any trust at all to have DKIM set up correctly in my DNS but not sign any emails? I could not find any information about that.

Now, if I send an email to a domain/server with DMARC set up, with policy=reject and adkim=strict, will all my mails be rejected?
If so, it would be better to just ignore DKIM, right?

Does it provide any trust at all to have DKIM set up correctly in my DNS but not sign any mails?

This does not make sense. You are essentially only adding junk to the DNS, i.e. information which are used nowhere.

  Now, if I send an email to a domain/server with DMARC set up, with policy=reject and adkim=strict, will all my mails be rejected? If so, it would be better to just ignore DKIM, right?

adkim only specifies how the sender alignment is done between the RFC822.From header in the mail and the domain specified in the DKIM signature. If the sender does not add any DKIM signature then the value of adkim is irrelevant.

If the  DMARC policy is reject and the sender adds no DKIM signature then SPF must match or the mail gets rejected. This means there must be a SPF record for the domain, the SPF lookup must pass and the SMTP.MAILFROM must be aligned with the RFC822.From.


How to detect the so-called "undetectable" Gameover Zeus? The media are currently (and have been) creating a huge ruckus surrounding the supposedly "undetectable" Gameover Zeus malware.

The Daily Mail
The Mirror
The Independant
PC World
The Telegraph
...And a number of others.

My question is... is there actually any increased risk to this particular malware, or are the media just running with it to run a scaremongering story?

Are a combination of Malware Bytes and Microsoft Security Essentials sufficient for most users to be safe?

The media are in a feeding frenzy over this. However, the malware in question is several years old. This started I think with the FBI blowing their own trumpet over taking over a botnet (that had been working for several years).

Then the UK's National Crime Agency decided to use it as a public awareness campaign to try and get people to improve the safety and security of their PC's.

Then the press got it and did their usual thing of totally twisting it out of recognition.

Indeed, the later variants of this malware are, at least to a degree, not even dependent on their command and control servers. They are capable of talking peer-to-peer.

So the risk is inflated by the press. However, that isn't to say that this type of malware doesn't present a real and present danger to anyone using the Internet - it does.

So the usual mitigations should be applied:

Good anti-malware software with rapid updates (the Microsoft AV seems to have fallen off the edge of acceptable recently) - Avast, etc.
Limits on running executables - this may well be the best protection all round. Unfortunately, it isn't easy to achieve outside the enterprise & even in the enterprise, it does annoy people! Only recognised and authorised executables should be able to run.
Outside the enterprise, sensible precautions are running Microsoft EMET and running as a standard user not a user with admin rights.

An occasional sweep with alternative anti-malware tools and rootkit detection tools may also be sensible though many of the vendors of what were just AV tools now include additional checks as well.

Oh, and inside an enterprise, there should also be additional checks at network boundaries by using threat management tools which can detect suspicious activity both coming into and going out of the network and blocking & reporting it.

Finally, the malware in question is most certainly detectable by the right tools. A quick search will reveal that.


Are backups of truecrypt volumes with different pass phrases a security risk? Lets say that I periodically change the pass-phrase on a truecrypt volume. The volume is regularly backed up, so my backup system has many copies of that volume, many of which have a different volume header due to having different pass phrases.

If an attacker gains access to my backup system, does having access to many copies of the volume header (for different pass-phrases) make it significantly easier for them to break the encryption on the volume?

Obviously I realise that you only need to guess one pass-phrase for all of the backups to be accessible (since you can back up the volume header from the volume who's pass-phrase you know and restore it onto any of the others) but does having multiple copies of the header make it easier than infinitesimally reducing the exhaustive search space required?

The only issue would be that the expected time to brute-force the password would be significantly reduced, by a factor equal to the number of volumes they're given.  So for example, if they are given 5 volumes, it would take 1/5th the time to brute-force the key, under the (highly dubious) assumption that testing the key on 5 volumes takes just as long as testing it on one.

This is probably not a major concern, however; even if you used "only" a 128-bit key, and the attacker had a million volumes to work with, your effective security would only be reduced by 30-bits, leaving a still-hefty 96-bits of security.

So, as long as you don't choose to encrypt with an algorithm that has a serious plaintext vulnerability (none of the algorithms used by TrueCrypt currently do), you should be fine.


Does having 2-factor authentication help with HeartBleed? I was talking with a friend about HeartBleed, and he mentioned that he had 2-factor authentication enabled on all the sites that supported it, so even with his username and passwords, nobody would be able to login without his phone too.

I told him to change his passwords anyway.

But I'm interested to know; was he right about 2-factor authentication protecting him from the worst of it?

Thanks!

evamvid

I disagree with Mark. A main goal of SSL/TLS is the protection of the long term key (i.e. the private certificate). If an attacker can obtain the key, the implementation must be considered broken.

It does not matter if you use two-factor authentication or not. If I know the server's secret key, I can decrypt your traffic either directly (without PFS) or via MITM (with PFS). I can steal your session cookies or whatever and do everything without your token. I can even steal your TCP sessions.