Security of natural Windows 7, 8.1 or 10 behind no firewall I've often been wondering today in 2016 how secure is truly an up-to-date natural Windows 7, Windows 8.1 or Windows 10 OS on internet behind no firewall other than its internal windows firewall.

Is this common practise to do or is it strongly recommended to buy an alternate software firewall on top of it or absolutely put it behind a hardware firewall ?

TL;TR: it is not safe and if local or hardware firewalls can help depends on how deep they can inspect.

It depends on your exact environment but the currently the major attacks against PC's are delivered via web and mail. This includes drive-by downloads, malvertising, malware inside phishing mails (like alleged invoices or delivery notices) and other social attacks (like scareware or "you need to install this flash update before viewing this video") etc.

An traditional packet filter firewall like employed in the normal SoHo routers or what is built into windows will not be able to detect these kind of attacks, because filtering is only done at the transport layer but one needs application layer inspection to detect these attacks. It does not matter if this is a "software" or "hardware" firewall, but it depends on the capabilities.

More protection provide endpoint security solutions which include antivirus to detect malware hopefully before it gets executed and blacklists either built into the browser (like Google Safe Browsing or Microsoft Smart Screen) or within a local web proxy. Similarly the better corporate firewalls (NGFW, UTM, IPS, Secure Gateway...) are able to do deeper inspection and claim to provide similar protection. Note that none of the solutions offers full protection and that the claims of the vendors about the protection they offer are often only loosely related to the reality (Often the claims or more detached from reality the cheaper the products are).

Apart from malware or phishing attempts to steal authorization credentials (typically for banks, Paypal or similar) you have attacks which use design problems of the current web. These includes CSRF attacks for example to reconfigure local routers or XSS attacks to steal authorization credentials. These need even deeper inspection of the content and chances are low that a corporate firewall at the perimeter will detect these attacks when directed against the local intranet, because in this case the attack is from inside the local network (clients browser) to another host in the local network, even if the attacker itself is outside.


Read only Data changed using developer tools I am using a third party website in which I observe the following behavior for Change Password.

The system has userA with mobileNumberA and userB with mobileNumberB
User B wants to change password. System shows mobileNumberB (non editable field) and asks to confirm so that change password link can be sent
User B changes the value in mobile field to mobileNumberA using developer tools and clicks ok
System sends change password corresponding to user A's account to mobileNumberA.

User A can ignore the SMS as he didn't request to change passwords. Tthe change password link is created using both user and mobile number, and in this case only user A can change his password. User B cannot change user A's password. All these are fine. But I would expect that server should ignore if any changes are sent for non editable fields. Can I raise this as security concern?

But I would expect that server should ignore if any changes are sent for non editable fields

In no way should the server-side blindly trust that the client input. This includes not trusting that the client will not modify read-only fields.

Instead data which should not be modified by the user might simply not be included at all when sending the form, i.e. the server can read the users phone number from database. Alternatively read-only data could be protected so that modification by the client will be detected. This can be done for example with a signature or HMAC over all read-only fields which is generated by the server and can be verified by the server.


Is it possible to let a fake certificate appear valid by sending fake OCSP responses? In a MITM-Attack I can exchange the server certificate by one I created on my own with tools like MITMProxy or SSLSplit. But this only works well when I have installed a fake CA cerrtificate in the victims browser otherwise it's identified as a fake certificate.

Would it be possible to create fake certicates that seems to be issued by the original CA and then fake the OCSP Response so the certificate seems valid?

OCSP is a way for the CA to INVALIDATE specific certificates. A browser will also check the signature of the supplied certificate against the CA's root certificate (possibly in a few steps, the certification chain), this is done completely locally.

So in short, no it is not possible to make a fake certificate look valid without replacing the CA's root certificate in the users browser. (Only a certificate in the chain should not be enough.)


MiTM not working --rejected by router? I have been attempting to run a MiTM on a very old XP SP3 computer. I have attempted it with 3 products, as listed below:

Wireshark: Traffic from the computer did not even show up. (I did see traffic from multiple IP's, so I think I have the right adapter)

ARP Spoof: (with and without SSL Strip): As soon as attack took place victim was kicked off my network and not allowed back on until attack stopped

Cain: Showed a "half-routing" symbol. When I put in the command "ping google.com" on the victim the 4 packets went out and registered in Cain, but no response came back.

It seems to me that my router is detecting that I am MiTMing my computer, and refusing to allow it to connect. Does anyone know how I can circumvent this?

You need to remember to tell the client about the gateway (which is you) and the gateway about the client (which is also you). It seems you have as the error says only spoofed one side of the network. You need to tell the router you're the PC and the PC you're the router and enable yourself to forward these packets along too. Forwarding will enable you to transmit the packets, and is achieved in linux by the following command:

echo 1 > /proc/sys/net/ipv4/ip_forward

You will have trouble if you only do the PC side or vice versa. Also remember to refresh your router and clients ARP cache or they will not be able to get out to the internet.


Proof of concepts for published exploits Do industry pros have VM's or various workstations setup to go through known exploits after they've been patched or is that less beneficial for learning than i'm imagining?

I'm thinking, how can you understand the buffer overflow attack, or another vulnerability, for such and such an application if you've never done it firsthand?

If this isn't the case how is knowledge effectively disseminated or learned?

Furthermore, are there repositories that detail exploits from point A to point B
or are we generally expected to fill in the blanks?

Yes, and no. Some developers will diff windows patches to find or discover vulnerabilities, or to corroborate public CVE information.

Most people I would imagine follow the "follow exploit tutorials/understand -> recreate exploit without help -> performing fuzzing/exploit dev on their own.

There are popular courses that teach exploit development using public exploits from the ground up.


General question on secure channels and implementations In the modern world of fast CPUs and large memory blocks should we use TLS encrypted channels outside of the browser/server paradigm ? One of the examples would be to establish TLS connection across internal micro services. For example two microservices inside the same AWS VPC subnet ? Or the general routing policies are enough to guarantee the security ?
Why TSL/SSL termination is required ? Is there any reason of its existence aside from supporting pure HTTP software, such as Varnish ?

Disclaimer: please note that I have absolutely zero knowledge in secure infrastructures and their protection, hence explanations in layman terms are appreciated.

The current practice assumes that general routing policies are sufficient.  This is mostly for ease of use for Ops (content-based traffic shaping, automated intrusion detection, etc, work easier on unencrypted traffic) more than anything else.  It isn't a BAD assumption - if someone owns a machine sufficient to have access to traffic sniffing, they probably could access the ssl certs for that machine.  It does mean that things are less contained than they could be.  It is a risk-management decision - do you add security and slow down your ops team?  Or go a little more open and make their life easier.
One advantage of SSL/TLS termination at the border and HTTP internally is easier access to content for intrusion detection purposes.  It is also a lot easier to have SSL dealt with in one place, rather than having to ensure trusts using wildcard certs (if using an external CA) or self-signed certs for the individual hosts (if using an internal self-signed CA).  It gets harder to do TLS internally with scaling - hosts are appearing and disappearing.  Clear is easier.  Again, this is a trade off - you need to make a decision for your environment, your content, your need for scaling and fast changes, your ops team.


Storing and reading user's credentials on their machine I am writing a (third-party) client for a game, and one feature that I would like this client to have is the ability to automatically log into the game using credentials previously entered. The credentials simply consist of an alphanumeric username and password.  One naïve way of implementing this is storing a file containing the username and password on the local machine. However, this is unsafe for a number of obvious reasons. One in particular is that this client supports plugins that other developers can write. This opens up the door for a malicious developer to read the contents of the file, effectively compromising the account.

I have also considered the idea of using some cipher to encrypt (and decrypt) the password, but I was not sure what was a safe way to seed the cipher. One idea that I had was creating a randomly generated file and using that to seed the cipher and then using that cipher to access the password. However, again, a malicious plugin could simply read that randomly generated file, seed their own cipher, and then decrypt the contents of the password file.

Is there a secure way to store and retrieve a user's password on the local machine? Assume that a malicious developer has full access to the source code of the application and knows exactly what algorithms and techniques are being used.

Edit: I have no access to the server that the client connects to. My application is basically a "wrapper" for the official game client that adds extra functionality.

No. Not without user input such as a passcode or passphrase used to encrypt and decrypt the credentials.

Even so, the malicious developer could sniff the credentials after decryption anyways.


Security of bcrypt/sha256 key used with AES to encrypt a file I'm looking to encrypt files using secure hashing and encryption algorithms in Python. Having used bcrypt in the past, I decided to use it for my passphrase calculator, then pass the output through SHA256 in order to get my 32 bytes of data, then use that with AES to encrypt/decrypt a file:

#!/usr/bin/env python

from argparse import ArgumentParser
from bcrypt import gensalt, hashpw
from Crypto.Cipher import AES
from hashlib import sha256

import os, struct, sys

def main():
    parser = ArgumentParser(description = "Encrypts or decrypts a file using " +
            "bcrypt for the password and triple AES for file encryption.")
    parser.add_argument('-p', '--passphrase', required = True,
            help = "The passphrase to use for encryption.")
    parser.add_argument('-i', '--input', required = True,
            help = "The input file for encryption / decryption.")
    parser.add_argument('-o', '--output', required = True,
            help = "The output file for encryption / decryption.")
    parser.add_argument('-r', '--rounds', default = 10,
            help = "The number of bcrypt rounds to use.")
    parser.add_argument('-s', '--salt', default = None,
            help = "The salt to use with bcrypt in decryption.")
    parser.add_argument('operation', choices = ('encrypt', 'decrypt'),
            help = "The operation to apply, whether to encrypt or decrypt data.")

    parameters = parser.parse_args()

    if parameters.operation == 'encrypt':
        encrypt(parameters.input, parameters.output, parameters.passphrase,
                parameters.rounds)
    elif parameters.operation == 'decrypt':
        decrypt(parameters.input, parameters.output, parameters.passphrase,
                parameters.salt)

def encrypt(input_file, output_file, passphrase, rounds):
    bcrypt_salt = gensalt(rounds)
    bcrypt_passphrase = hashpw(passphrase, bcrypt_salt)
    passphrase_hash = sha256(bcrypt_passphrase).digest()

    print "Salt: %s" % (bcrypt_salt, )

    iv = os.urandom(16)

    cipher = AES.new(passphrase_hash, AES.MODE_CBC, iv)

    with open(input_file, 'rb') as infile:
        infile.seek(0, 2)
        input_size = infile.tell()

        infile.seek(0)

        with open(output_file, 'wb') as outfile:
            outfile.write(struct.pack('<Q', input_size))
            outfile.write(iv)

            while True:
                chunk = infile.read(64 * 1024)
                if len(chunk) == 0:
                    break
                elif len(chunk) % 16 != 0:
                    chunk += ' ' * (16 - len(chunk) % 16)

                outfile.write(cipher.encrypt(chunk))

    return bcrypt_salt

def decrypt(input_file, output_file, passphrase, salt):
    print "Salt: %s" % (salt,)

    bcrypt_passphrase = hashpw(passphrase, salt)
    passphrase_hash = sha256(bcrypt_passphrase).digest()

    with open(input_file, 'rb') as infile:
        input_size = struct.unpack('<Q', infile.read(struct.calcsize('Q')))[0]
        iv = infile.read(16)

        cipher = AES.new(passphrase_hash, AES.MODE_CBC, iv)

        with open(output_file, 'wb') as outfile:
            while True:
                chunk = infile.read(64 * 1024)
                if len(chunk) == 0:
                    break

                outfile.write(cipher.decrypt(chunk))

            outfile.truncate(input_size)

if __name__ == "__main__":
    main()

What are the possible weak points of an implementation like this?

What I have determined is that it would be easy for an attacker to determine the original file size, however that doesn't reveal much about the file. SHA-256 isn't the best hashing algorithm in the world, but wrapping a bcrypt password would lead me to believe that all threats would be mitigated there. Due to bcrypt's ability to increase in security over time by adding more rounds to the algorithm, it seems like a pretty safe bet to use bcrypt for now.

Are there any gaping holes in this implementation? I'm not a cryptographer, but I do know the basics and purposes of each of the three algorithms being used here.

From looking at it for two minutes:

Using bcrypt is sound. SHA-256 is one of the best known hash functions (because it has been around for more than 10 years, widely deployed, and yet unscathed).
Since you generate a new salt for each encrypted file (and that's good !), it would make sense to store it in a file header. That way, you would not have to provide it as parameter to the decryption routine. A salt needs not be secret (that's a salt, not a key) but a new salt must be generated for each encryption, hence external handling could be cumbersome. You already have a custom header for the IV, you could do the same for the salt.

Alternative: store the salt as header, and generate both the
encryption key and the IV from bcrypt output (split the SHA-256
output into two 128-bit chunks; first one is the key, second one is
the IV). This would keep header size to 16 bytes. But a random IV
(from os.urandom(), like you do) is not bad either.
You use encryption but there is no MAC. There are not many attack models where the attacker can observe data (i.e. you need confidentiality) but not alter data (i.e. you do not need integrity). In practice, you would be better off adding a MAC. Ideally, replace CBC with a mode which handles both encryption and integrity (GCM, EAX).

If your support library does not provide such a mode, you will have to do it "old style" by combining encryption with HMAC. This is not totally trivial to do. Best practice would be to generate an extra MAC key from bcrypt output (if you produce the encryption key, the IV and the MAC key, you will need a larger hash function, e.g. SHA-512) and compute the MAC over the concatenation of the IV and the encrypted data (you could skip the IV only if you generate it from the passphrase too, but it is safer to include it in the MAC input). Upon decryption, verify the MAC first, then proceed to decryption only if the MAC matches.
You might want to include some provision for algorithm agility, i.e. adding in the header a byte value which identifies the combination of algorithms you use (bcrypt, SHA-256, AES+CBC, HMAC/SHA-256). This would allow you to switch later on to another set of algorithms without breaking code compatibility with existing files. In that case, don't forget to add this "algorithm identifier byte" to the input for the MAC.
Your padding is ambiguous: upon decryption, you will find some space characters at the end, but you will not know whether the extra spaces were part of the input file, or added by the encrypt function. And, indeed, upon decryption you leave the spaces. This might not be an issue for your specific usage scenario, but, as a general encryption/decryption tool, this is usually considered an issue if files do not survive an encryption/decryption trip without modification. PKCS#7 padding (also known as PKCS#5 padding) is commonly used: you add k bytes (at least 1, at most 16, so that the total length is a multiple of 16) and all the bytes have value k. Upon decryption, look at the last byte, which will tell you how many padding bytes were added.


Are there flaws in this simple key exchange? I'm reviewing for a computer security exam. Here is a simple scenario:

Suppose that someone suggests the following way to confirm that the two of you are both in possession of the same secret key.  You create a random bit stream the length of the key, XOR it with the key, and send it over the channel.  Your partner XORs the incoming block with the key, (which should be the same as your key) and sends it back.  You check and if what you receive is your original random string, you have verified that your partner has the same secret key, yet neither of you has ever transmitted the key.  Is there a flaw in this scheme?  Why or Why not?

-because of the XOR, I don't think it is possible to get the same hash from different keys (that would mean it is a bad function...)

Then there is this extension onto the scenario:

You forget about using a key and simply use a random bit stream to XOR with the message and your partner uses the same random bit stream (leveraging the fact that for a given seed, the output of a random number generator is exactly repeatable and completely deterministic.)  Is there any possible flaw with this scheme?

-I would say that this breaks one of the fundamental rules of a good hash: it isn't random. Right? I know that it isn't really possible to generate true random values...is that a viable flaw here?

You send K xor R. Your partner sends back R. The attacker sees both values; he can thus compute (K xor R) xor R (the XOR of the two values he saw), and the R cancel out: the result is K. So, weak. Terminally.

If you want something more robust, you'll need an extra tool, e.g. a cryptographic hash function like SHA-256. For instance, you still send K xor R and your partner sends back SHA-256(R). This one works provided that R was chosen randomly and uniformly. Think about it; the point of such exercises is to get some intuitive understanding of what is going on. Here, your partner is showing his knowledge of R by sending SHA-256(R), but without revealing anything about R (mostly because SHA-256 is resistant to preimages -- yeah, I know I am taking a bit of rhetoric shortcut here). Note, however, that this scheme is vulnerable to dictionary attacks in case the key K is a password (i.e. something from a set which is small enough to be exhaustively walked through).

Other variants with a hash function are possible; they will all be weak with regards to dictionary attacks, though (you need PAKE to fix that, and this means a lot more mathematics).

Your other scenario is what basically a stream cipher is. It can be strong, if done properly: use a robust algorithm, a large enough "seed" (which is, really, a key), and never ever reuse the same stream for two distinct messages.


Is it possible for web scanners to crawl and test pages simultaneously? I've searched and read some articles about web application security scanners. I've found that almost all scanners at first crawl the application to find all pages (or states). And then after crawling completed, the scanner starts to test the application (fuzz testing for instance).

Isn't it possible (for some reasons) crawl and test pages simultaneously? For example find page A then do fuzz testing on it, after that crawl again and find page B and so on. Is it theoretically possible? Is it practical? If not, please explain why?

It is possible. WebInspect has had this feature since 2007 -- it may have been the first. Burp Suite Professional was also released that year with Spider and Scanner supporting runs simultaneously.

Some tools like Netsparker do crawl first, but in this case I have found that you can install Netsparker, configure it, have it crawl, attack, and export results faster than any other equivalent tool. I contend Netsparker will finish most apps over lunch when most other commercial scanners invovle wrangling that often goes on for days.


How to obtain Service Tickets (TGS) for Service Accounts with no SPNs (ServicePrincipalName) set? The first step in a kerberoasting attack is to discover Service Accounts via AD enumeration. One way to do so is searching LDAP for any registered SPNs (Service Principal Names). However, from my understanding, service accounts may exist with no SPNs set. This seems to be confirmed here, specifically;

  While SPNs are very reliable and informative, they will not produce a
  comprehensive list of service accounts. Many accounts do not integrate
  with Kerberos through SPNs and will have no SPN values set.

And indeed, In my enumeration of LDAP I find service accounts, with names such as "svc_webapp1", "svc_program" etc (the description and DN also suggest these are service accounts).

The next step in the attack is to request tickets for said service accounts. However, the only way I'm finding online to request service tickets is via the KerberosRequestorSecurityToken class, i.e.;

System.IdentityModel.Tokens.KerberosRequestorSecurityToken –ArgumentList '[ServicePrincipalName_to_request_ticket_for_GOES_HERE]'

This requires/assumes the account(s) you want tickets for have SPN(s) set, but the service accounts I have found do not have SPNs registered/set. Is it possible to request tickets for these accounts anyways (possibly via some attribute other then SPN, or some other class)?

A service ticket is a very specific thing. Active Directory will only let you request service tickets to principals that have SPNs registered because otherwise it's not a service principal as far as Kerberos is concerned. This is for correctness and security reasons.

If services really need to use Kerberos to authenticate to a principal that doesn't have an SPN available to it, it will attempt User-to-User authentication which relies on shuffling the encrypted TGT between users and the KDC, and encrypting the service ticket to the service TGT's session key.


exploiting Heap Overflow in gdb segfaults I have been trying to exploit the heap overflow vulnerability for the program below, I am running Linux 14.04.

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

int n = 5;

int main(int argc, char **argv) {
    char *p, *q;

    p = malloc(1024);
    q = malloc(1024);
    if (argc >= 2)
            strcpy(p, argv[1]);
    free(q);
    printf("n = 0x%08x\n", n);
    free(p);
    return 0;
}

In this exploit i am trying to write a 32 bit random address of stack into variable "n" present in the program,using the unlink() technique.

However when the free() is called the program segfaults.

This is my input:

(gdb) p &n
$1 = (<data variable, no debug info> *) 0x804a02c <n>
(gdb) x/xw 0x804a02c-0xc  (address-12 bytes)
0x804a020 <__libc_start_main@got.plt>:  0xb7e27990
(gdb) x/2xw $ebp
0xbffff1c8: 0x00000000  0xb7e27a83
0xbffff1c8+4bytes=0xbffff1cc

(gdb) r `perl -e 'print "A"x1024 . "\xfc\xff\xff\xbf"x2 . "XXXX" . "\x20\xa0\x04\x08" . "\xcc\xff\xff\xbf"'`

The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/HIIII/heap_overflow/test/heap_1 `perl -e 'print "A"x1024 . "\xfc\xff\xff\xbf"x2 . "XXXX" . "\x20\xa0\x04\x08" . "\xcc\xff\xff\xbf"'`

Program received signal SIGSEGV, Segmentation fault.

=> 0xb7e857e0 <__GI___libc_free+64>:    mov    (%eax),%eax
   0xb7e857e2 <__GI___libc_free+66>:    movl   $0x0,0x20(%esp)
   0xb7e857ea <__GI___libc_free+74>:    add    $0x18,%esp
   0xb7e857ed <__GI___libc_free+77>:    pop    %ebx
   0xb7e857ee <__GI___libc_free+78>:    jmp    0xb7e82520 <_int_free>
   0xb7e857f3 <__GI___libc_free+83>:    nop

0xbffff180: 0xbffff1c8  0xb7ff2500  0x0804b412  0xb7e857a0

0xbffff190: 0x0804b410  0xb7e857a6  0xb7fb9000  0x08048500

0xbffff1a0: 0x0804b410  0xbffff3d6

***0xb7e857e0 in __GI___libc_free (mem=0x804b410) at malloc.c:2945
2945    malloc.c: No such file or directory.***

I have taken this attack vector from http://www.win.tue.nl/~aeb/linux/hh/hh-11.html (uses glibc-2.2.4)

Thanks in advance

There was some very carful algebra done on this site on the variables that manage a doubly linked list of addresses.  Have you investigated the source code in for malloc.c and unlink to see that the code has not changed in some way?  I believe you will find your problem in there.


How safe is to secure sensitive content by URL with MD5 hash and no other authorization? Suppose we have website that use MD5 hash in URL like this:

http://somewebsite.com/XXX/

where XXX is MD5 hash.

Content of this website may have sensitive information like transaction details with personal data.

There is no other authorization to this website, so if you have URL you can access it.

How safe is it? I mean, if no one will share URL with anyone, then can I assume no one will access it?

How much time could it take web crawler, to crawl through all combinations of such url?

I ask because I am using some web shop, that store transaction details with personal data in such manner, I am saying them that it's not secure and someone can view their clients sensitive data, but they are not convinced. To build web crawler it's simple to me, I know how to do this, but I don't know how much time it will crawl through all combinations, maybe at shop they are right? This is not about my website, I am end user of that shop, and I need to convince them they are wrong.

There are a couple of issues to consider with "secret" URLs.

First, they offer a different level of security against discovery when served over HTTP vs. HTTPS.  Over HTTPS, the path is protected.  Over HTTP, it is not.  This means that when using HTTP, anyone in the path of the traffic (people sniffing wireless traffic, proxy servers, caching servers) have access to the path and can therefore discover it.   Over HTTPS, only the hostname is exposed, the path is protected from eavesdroppers.

Second, they can be bookmarked or saved in any number of ways.  You have to consider whether the misuse of bookmarked URLs is a significant threat to your application.

Third, there's no way to expire access to a valid URL.  If you have an authentication system, you can enforce session timeouts of some form.  If you don't, as long as the URL is valid, anybody who has it can access it.

Fourth, and more specific to this specific application, is Izam's question in the comments.  What is being hashed to create the URLs?  If it's something like an incrementing integer-based transaction id, or something other source for which an algorithm can easily generate candidate inputs and hash, no, it would certainly not be safe because an attacker could generate a set of potentially valid hashes and try them all.  They may not all work, but if some of them do, the scheme is broken.  Particularly if it is something like an incrementing integer, because if they discover valid inputs, all valid URLs can be easily determined and exposed.

So, secret URLs can be a valid tool in some cases.   With personal information at stake, particularly financial information, I would not rely on this mechanism.  It's far too weak.


My Virgin Media account password is visible in plaintext to call center staff. What do I do? Whilst on the phone to support staff (about billing) to Virgin Media, perhaps the largest ISP and telecoms company in the UK, I was asked to confirm my password over the phone.

I asked the advisor if they could see my password in plain text, and they said they can!

I am currently wondering what the best course of action is for me to bring this issue to the attention of Virgin Media's management. The fact that any call center worker could go home and access my Facebook account is bad enough, but if the passwords are stored in plaintext, Virgin Media is sitting on an information security timebomb and all their customers are at risk.

How do I get Virgin Media to handle passwords securely?

Generally, reuse of passwords across different sites is a bad idea for this reason; you never know whether they are taking measures to secure your password from view of staff or hackers who might grab the database.    Of course, once one of these sites is compromised, hackers will try the same password combination for other common accounts like Facebook, PayPal, etc etc.

I recommend using LastPass, KeePass or another password manager to generate a new, random password for every site you login to and then save it.  Sure, having all your eggs in the LastPass basket might seem like a security risk, but at least they are more trustworthy to use best practices and secure your data.  This is evidenced by the recent hack of LastPass, which because they had been salting/hashing their passwords so well, I haven't bothered to change my master password because the risk of compromise is so small.

I think using random passwords and saving them in a manager like LastPass is a MUCH better practice than memorizing and reusing passwords on different sites.  It also has the advantage of being easier/quicker to login as well, and reduces risk when you create logins on sites that you don't trust.


Win Server 2008 RDP Attack On one of my machines I run Win 2008 R2 server. It has been recently updated. My RDP session is limited to my IP address only and firewall is UP. Even though the main RDP post 3389 is blocked by firewall ( IP restricted) I am getting 1000's of attempts to break in on range of different ports from 1012 to 63000. I attached the snapshot of the issue. I am getting 1000's of every day so my log file fills up pretty quick.

I am not an expert on win Servers and all I can do at this point is to ad the culprit's IP address to blocked IP's in my firewall. But the IP changes after 500 attempts regularly. My question is, how do I prevent this so I do not have to monitor this server every day? Any help appreciated.

Below is the copy of the event details one of many hack attempts:

EventData

  SubjectUserSid S-1-5-18
  SubjectUserName MyServer12$
  SubjectDomainName WORKGROUP
  SubjectLogonId 0x3e7
  TargetUserSid S-1-0-0
  TargetUserName administrator
  TargetDomainName MyServer12
  Status 0xc000006d
  FailureReason %%2313
  SubStatus 0xc000006a
  LogonType 10
  LogonProcessName User32
  AuthenticationPackageName Negotiate
  WorkstationName MyServer12
  TransmittedServices -
  LmPackageName -
  KeyLength 0
  ProcessId 0x3114
  ProcessName C:\Windows\System32\winlogon.exe
  IpAddress 27.151.120.145
  IpPort 1214

There are a few items in addition to what you've written that I would add.

Rename your admin account - Yes this might be a pain in the ass (especially if you've got services using the domain admin account) however this is a commonly attempted brute force username. Rename this account to something ambiguous that won't easily be guessed.
Don't use common names for accounts - If you audit the security logs you'll notice that a good chunk of the login names are common names (Administrator, admin, sql, sa, besadmin, guest, etc). Ensure that you are either not using these usernames, or if you need to use the username ensure it doesn't have the rights to logon to your remote desktop server
Enforce an Account Lockout Policy - With your administrator account renamed and your other service accounts renamed or not given access to the remote server, this will disable someone's attempt to login with that username. Make sure you set this as a local policy on the remote server and not a domain policy. Users will attempt the wrong password with your account for X amount of tries, get locked out and move on to the next IP address.
Investigate TS Gateway - TS Gateway allows for your RDP sessions to connect to your network via the standard SSL port of TCP 443. This will allow you to completely shut off port 3389 from the outside world. The one pitfall I've found with this technology is there is no free Mac RDP client that will allow you to utilize TS Gateway so if you have Macs you'll either need to pay for the client or disrergard TS Gateway.
Windows SSHD_Block - A talented SysAdmin by the name of Evan Anderson wrote a nice little VBScript that will block IPs attempting to Brute Force your Terminal server. Check it out HERE

Hope these little tips and tricks help you secure your network.


If malware was detected in browser local storage does computer need to be nuked from orbit I haven't used Windows partition since mid-June and I booted the system once again just a few days ago. My first action was as usual update all programs marked to be updated (including Windows updates). Today MSE detected TrojanDownloader:Win32/Tugspay.A in chrome directory, which I believe to be for persistent storage after Googling. Since only option was to remove or leave it - I removed the file.

I run a full MSE scan but nothing has been shown up. When I booted computer from AVG LiveUSB (created on different computer and inserted after shutdown) it did not detect anything except cookies and adware in recycle bin (after checking - some time ago 'Download Manager' tried to be downloaded on my computer and I deleted it without running).

Should I believe that malware was put into persistent storage but has not been run, perform any extra security steps to check it or reinstall the Windows (the last step is relatively expensive for me in terms of time/hassle - it's a private computer so there isn't anything like remote deploy system etc.).

It is a backdoor, so it hard to tell what damages it brought to your system. For example, it might be used to log keystroke or download other malicious files to your system

It is good to know how it infected your machine in the first place. Now, since you said your anti-virus MSE, which I personally do not trust very much, theoretically you should be fine. However, it is good to do some manual checking:

Open Registry Window by typing “regedit” in Run window.
Once it opens search the registry files related to TrojanDownloader:win32/Tugspay.A and delete all of them.

Finally, I personally recommend you re-install windows. Why? because this Trojan in particular can download other malware files. It is possible that it download other malware and MSE fails to detect them. Do you see my point?

Look at the TrojanDownloader:Win32/Tugspay.A See they call it the Trojan Downloader


Impact of sharing my device MAC to access wifi? I shared my phone's MAC id to connect to my office wifi. Will the system administrator be able to see my whatsapp messages or internet activities in my phone ?

The Media Access Control address is simply used to allow the wireless router to find your device across the radio frequency, and to identify your phone when you want to speak to the router's radio antenna. It is not used, or visible, outside the wireless network, so is not used as part of any secure connections to services outside that network.

Secure services like WhatsApp are not vulnerable to inspection by simply capturing the traffic, as they use end-to-end encryption. Websites and apps that do not use encryption can be inspected by the network operator.

The unique risk versus an open wireless network is that the network operator can now use that MAC address to correlate network traffic with your device. If they notice unwanted traffic, they can see the MAC address participating in that traffic and know that you are the owner/operator and probably responsible for that traffic.


truncated hash for message authentication? I am using hash for authenticating the signature of the message. since the hash will be part of a url that is used for QR code, I would like to keep the hash as short as possible in order to generate a less complicated qr code which is easy to scan.

Now I am using md5 hmac to compute the hash which already generates a shorter one(32) than SHA256. But it isn't short enough and I am thinking of truncating the hash to get a even shorter one. say length of 16.

I would like to get your opinion on how is this method, does it make the hash easily cracked practically? or if there is better method?

thanks!

Truncating a well designed cryptographic hash digest  should not result any security weaknesses other than a reduction in the collision space. As these hash algorithms have a key design requirement of being uniformly distributed across the hash space.

All other things equal, using a more modern hash algorithm (SHA) and truncating it is safer than using an older one (MD5).


some questions about DOM based XSS Is it possible to do a DOM based xss attack with window.location.protocol?
How can we use dom based xss with document.title?
How can we bypass the escape javascript function if it is used?

thank you

No
I'm not sure what you mean? You can't "break out" of document.title=AttackerString where AttackerString is a javascript variable with data (the string value) controlled by you.
Again, you can't exploit escape(AttackerString) but you can exploit something like <? echo 'escape("' .$_GET['AttackerString']. '");' ?> by simply bypass the javascript function: &AttackerString="); alert("xss in the case the html output would be: escape(""); alert("xss");


Web speech API security Does the web speech API send the audio to a third-party web service in order to do the speech-to-text conversion, or is everything built into the browser?

I'm trying to work out how secure this API is, for example as implemented in Chrome 25.

The speech input API specification doesn't mention how it should be implemented. But in the requirements section there is a bullet point about encrypting communications with remote speech servers[1], it's a not a requirement for now.
As for Chrome, it seems to be using a remote speech to text server using a POST over https according to this article[2], note this it's about Chrome 11 and it might have changed in the recent release.

http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Feb/att-0020/api-draft.html#requirements_section
http://mikepultz.com/2011/03/accessing-google-speech-api-chrome-11/


sniffing/recording GSM 3G signals Is it possible to sniff or record and process GSM 3G signals (from some reciever) given that there is no other signals interrupting etc (the most comfortable conditions)

Update (with some supporting material )
http://events.ccc.de/congress/2010/Fahrplan/events/4208.en.html

Sniffing and recording the signal is certainly doable, since that's what both cell phones and base stations do all day long.

Now the tricky point is that communications are encrypted, and decrypting the data from the outside can prove tricky. "3G" is a wide term, but (normally) 3G communications use the block cipher KASUMI. The best known cryptanalytic attack on KASUMI is a related-key attack which is something quite important for academics (especially since the attack can be demonstrated with two hours of computation on a PC), but by essence not applicable to the way KASUMI is used in 3G computation (it might be applicable if someone wanted to use KASUMI as a building block in a hash function, but that's really another subject).

So we can say that right now (early 2012), there is no known way to effectively break KASUMI encryption, provided that the block cipher is used properly.

The GSM protocols are complex beasts and it is possible that some weaknesses lurk in there, which might allow for security breaches without having to fight KASUMI upfront. I am not aware of any serious weakness of that nature (but absence of proof is not proof of absence). Also, be aware that all this crypto is only between the phone and the base station. The base station will then communicate the data to the provider network using whatever crypto, or lack thereof, that it wishes. If I wanted to tap on GSM 3G signals, I would do a bit of roof climbing and plug myself directly on the base station.


Securing wifi with encryption So I have been hearing that using WPS Pin is not secure at all and that there are available downloads that can brute force attack the pin until it uncovers it depending on what encryption you use. I have done a little digging but I cant conclusively discover what is the most secure encryption to use. I was wondering if people could point out what would be the safest among the available options my router supports they are as following:

WEP (Wired Equivalent Privacy)
WPA-PSK (Wi-Fi Protected Access Pre-Shared Key)
WPA2-PSK (Wi-Fi Protected Access 2 with Pre-Shared Key)
Mixed WPA-PSK+WPA2-PSK
WPA-802.1x

I have set it to the WPA2-PSK (Third option) with a very long complex key. However I have read and maybe I have misunderstood but it seems that the length and complexity did not matter when it was brute force cracking the WPS and that ultimately it would uncover the pin. I have turned off the WPS pin feature in my router but I am still a bit fazed by what method of encryption is the best to use. Ideally I would like to turn the WiFi off but in this building its almost infeasible.

Thanks in advance for any help!

WPS is a quick-config system that allows you to connect to a router without doing any configuration on the client side. It works by exchanging a pin code that acts as a temporary key, in order to transmit configuration details to the client. Unfortunately, the key is short, and easily brute-forced. The solution is to turn off WPS on your router, which you have done.

As for which method of encryption to use, WPA2-PSK is fine. So far the only attacks against it revolve around brute-forcing weak passwords, so if you're using a strong password then you should be alright.

The older WPA (WPA1, if you will) has problems that could allow an attacker to break into your WiFi by sending special probes, leading to information disclosure that can be leveraged via a cryptanalytic attack. WEP suffers from similar issues, but is much worse - in general WEP is considered to be about the same as no password at all, in the face of an attacker that knows how to perform basic wireless attacks.

Mixed mode means that both WPA and WPA2 are available, and the client can choose which to use. I'm not sure of the specifics, but I'd guarantee that this is less secure than just running WPA. I think in order to attack it there must be at least one authenticated client attached via WPA, but don't quote me on that one. The reason this mode exists is to provide compatibility with older devices. For example, a stock firmware Sony PSP doesn't support WPA2.

WPA-802.1x is another name for WPA-Enterprise, which involves running a RADIUS server inside your network to federate login requests. This uses Extensible Authentication Protocol (EAP) for the authentication. The primary benefits of RADIUS-based wireless security are that you can choose different credential types for authentication (i.e. you don't just have one shared key), and that you can prevent brute-forcing of logins. This is a more complex setup, though, and isn't well-suited to home use.

The last thing to consider is the encryption scheme. The two standards are Temporal Key Integrity Protocol (TKIP) and Counter Cipher Mode Protocol (CCMP). The first is based on RC4, and is used by WPA. The second is based on AES, and is much stronger than TKIP, and is the default for WPA2.


Can a Malicious App with Storage permissions access a Secure App's data 1) Assuming I have an untrusted app, e.g. sideloaded from an untrusted source with permissions to access storage granted installed on a recent (v7 or 8.x) Android device.

2) Assume I also have Signal, Wire or Telegram etc. installed from the Google Play app store on the same device.

Could the untrusted app access either the stored messages, or the screen contents and keypresses when in the secure messaging app? Or is there some other method of compromising the supposedly secure messages?

As Google documentation (https://developer.android.com/guide/topics/data/data-storage) says:

  By default, files saved to the internal storage are private to your
  app, and other apps cannot access them (nor can the user, unless they
  have root access). This makes internal storage a good place for
  internal app data that the user doesn't need to directly access. The
  system provides a private directory on the file system for each app
  where you can organize any files your app needs.

  When the user uninstalls your app, the files saved on the internal
  storage are removed. Because of this behavior, you should not use
  internal storage to save anything the user expects to persist
  independenly of your app. For example, if your app allows users to
  capture photos, the user would expect that they can access those
  photos even after they uninstall your app. So you should instead save
  those types of files to the public external storage.


What information can my network admin see when I visit a website? This question is similar to this but for my network admin.

  For example, when I enter this URL:
  https://www.google.com/search?q=example or ... I can see the word example that
  I was searching on Google.

Can my network admin see this URL and see what I searched? Can he see the decrypted traffic even if the web site uses SSL?

Whether he can see the traffic depends on the encryption. If you visit webpages delivered by http, he is able to monitor everything. If you use https, the traffic is encrypted. In a company it's still possible to decrypt the traffic if the admin installed a fake CA whose private key he owns. There are various tools that implement such a proxy functionality like Squid or MITMproxy if you just want to try it on your own. You can detect this by comparing the OS/Browser CA list with the one delivered by the OS/Browser vendor.

Even if you use https and the admin isn't able to decrypt the traffic, he is still able to find out which domains you connected to because you are using the company owned DNS server.

You can use TOR to hide both but there are some downsides. The usage of TOR can be detected by the network administrator and this makes you or at least your PC suspicious because TOR is often used by malware.

You can use a VPN which is also detectable but not as suspicious as using TOR.

The best solution for your problem might be using your personal PC/Laptop at home.


Is it safe to publish public PGP authentication subkeys? Suppose I have a PGP key set up as follows:

I have an offline master public/private keypair, which is set to only Certify, aka create subkeys and sign other people's keys.

Then I create three subkeys which I put on a Yubikey (with offline backups):

Signing key
Encryption key
Authentication key

The signing key will be used to sign messages and git commits.

The encryption key will be used for people to send me encrypted messages.

The authentication key will be used with gpg-agent --enable-ssh-support to use as ssh authentication to log into servers.

My question is:

Are there any negative (or positive?) security implications to publishing the authentication subkey (or all three public subkeys) to a keyserver?

My logic is that I'd only really need to publish the signing public subkey, so people can confirm my signatures, and my encryption public subkey, so people can send me encrypted messages.

No one from "the public" needs to know that I even have an authentication key because it will only be used in the authorized_keys file of my servers to allow me to log in without a password.

If someone were to break into a server and query the public keys in the authorized_keys file, they could look that up in the keyserver and find out that I, specifically, am using that server. Is this problematic or am I overthinking things?

By providing more keys to potential attackers than necessary, you are violating the principle of least privilege (why should anyone else have the privilege to view your public key?). If they don't have to know, there is no point in helping them deduct further information, e.g. the key type (RSA, ECDSA, ...) and size (e.g. 2048 bit) of your SSH key to find attack vectors. From this they could make more informed guesses about how you generally secure your systems, how fast you switch to new technologies and how paranoid you generally are (hmm, still using 1024 bit RSA? Oh, 512 bit ECDSA, interesting...).

Imagine at the moment of key generation you were not aware that a 512 bit RSA key can be cracked on a normal laptop nowadays. Attackers actively searching for such keys online would mark you as an easy target immediately.
Or imagine you forget to ever replace that key and/or forgot about your server (or you're simply not alive anymore to make changes). In X years, the private part of your 2048 bit RSA key can be calculated on a more advanced computation system and the data you have on your server will be at risk. It may not affect you anymore, but maybe you store someone else's data who will still care about keeping it secret.

Of course those scenarios are very unlikely (except for using weak keys, that happens regularly to people; even a 4096 bit RSA key is worthless if the state of the entropy pool was bad, see how lacking the world is at generating good keys in this paper), and probably a bug in SSH will allow exploitation of your server before that key of yours will be cracked, but their probability is not zero, and you should at least consider them before publishing more data than you need to. If you've considered these scenarios, you should be fine, but we all know that nobody can predict all attack scenarios or implications, so it's easier not having to think about them at all.

If you need to upload your SSH auth key to look it up, e.g. for configuring a new server's authorized_keys file, better host it on a URL that is hard to guess, e.g. www.mydomain.com/download/myAwesomePublicSSHkey.pub


Received email from friend but with inago.jp domain Domain is not his usual email address.  Has his correct name and my correct address of course, has a link that loads a fake forbes website with a smart pill advertisement.  I let him know via facebook that I doubt he has this additional email address.  Does this mean his account is hacked since my correct email address has been used?  He isn't in Japan, but in the UK.  Gmail put it in my spam folder.

His account might have been hacked, but not necessarily. The email is likely spoofed, and account access is not required to create a spoofed email.

Plausible ways this can happen:

An email is CC'd to a large number of recipients, which includes both you and your friend. Out of that list, one recipient's account is compromised. The attacker (or an automated bot written by the attacker) sees the recipient list of that message and spoofs a message from one person (your friend) to the rest.
Someone who has both you and your friend as contacts is victim of an account compromise. The attacker (or automated bot) sees both you and your friend in the contacts and decides to spoof a message from your friend to you.

So there's a good chance someone's account was compromised, but it may not have been your friend's. That someone might only be distantly linked to both of you.

Tell your friend to change his password and security questions anyway, but it's not reason to panic unless there's evidence that his account specifically was compromised.


Windows certificate store suddenly changed security level of one of my certificates I use Windows 8.1 Pro 64 bit and IE11. I have two personal certificates (with private key) of mine in the system certificate store. They are both set to require a password before they can be used.

This worked until a few days ago. Then I noticed that one of them is accessible without a password. How could that happen?

What I normally do is:

I open a HTTPS website that requires certificate auth
the dialog pops up to select a certificate (only one is offered, based on the CA, each of my certs are from different CAs)
after I select it, another system dialog appears, asking to grant or deny access to the certificate and for granting, I must enter the password
after entering the correct password, the website loads

This worked like this for both of the certificates (each used on a different website).
But recently, one certificate does not require the password any more. I can just select it and use it to access the website. The other still requires the password.

To check my memory is not playing tricks with me, I restored a system image backup a few month old. It has Windows 8 Pro and IE10. There both certificates ask for a password.
(I upgraded that system to Windows 8.1 via the Windows Store).

I don't see a way to change the security level of certificates after they are imported, so I did not do it myself and the forget about it.

I can re-import the certificate and set a password for it, but the question is, how did this happen? I checked the PC for malware (booting from a USB key: HBCD and Ubuntu) and found nothing.

Security levels on private keys in Windows are a rather complex subject; in particular, there are options for activating or deactivating the password, and for caching the password in memory. See this blog post for an introduction. Notably, the protection level for a given key is not intrinsically immutable; it may be changed. Possibly, Windows 8.1 changed some default behaviour; or maybe some action on your part, that you do not remember (that's not a blame; there are way too many popups in Windows to realistically expect to remember them all and miss none), changed the protection level at a time which fortuitously happened to be after your last pre-8.1 backup. In any case, you could go inspect the current status of your private keys and change it according to your wishes.


Password Storage - Self Encryption vs Hashing? Self Encryption: Encrypting a password using the password itself (as a symmetric key). Basically, by doing this, I'll get random data as an output. Now, in order to retrieve the password from this encrypted data, I must know the key. That is, I must know the password itself. Doesn't this property make it kind of one-way function?

I know that Hashing is the recommended and preferred way for storing passwords in a database (since it is one way). I also know that we should NEVER come up with our own crypto. However, I'm just curious to know how effective (in terms of security) will this Self Encryption be (if used instead of hashing) for storing passwords in a database?

By the way, I was not able to find much detail regarding this on the internet. I came up with concept while brainstorming and while searching about it, I came across with this answer by Tom Leek (where he called this technique as Self Encryption).

Very interesting thought.

But we have one problem here, regular hashes have always the same size, your hash will have different sizes depending on the input.

So it can be considered less secure that a regular hash.

Hash function definition:

  A hash function is any function that can be used to map digital data
  of arbitrary size to digital data of fixed size (...)


What are the risks of allowing business users direct production database access? I work for a small-ish company that currently allows almost everyone to access production databases and run SQL queries (it's a "culture" thing). I need to sell the C-Suite on why this is a bad idea but I am having trouble coming up with all of the reasons why they should disallow that access. Any help here is appreciated.

Just about any one piece of data from this document should be sufficient:

http://pages.clearswift.com/rs/591-QHZ-135/images/Clearswift_Insider_Threat_Index_2015_US.pdf

The kicker for me: roughly 75% of all data breaches start internally, with a large chunk of those being accidental breaches as a result of employee mistakes.

The more employees who have access to your data, the more space there is for accidents to happen.  Not just the "accidentally drop database" type of accidents (which baldPrussian discusses on in his answer), but the "took a picture at work, posted it on facebook, and didn't notice that my monitor in the background was display the production database password" kind of mistake.

I once had an employee post a video to facebook from his office, and in it his camera panned nice and slow across his monitor, showing all the code he had been actively working on at that moment.  Fortunately it was just front-end javascript and had no access credentials in it, but I nearly had a heart-attack.

Mistakes like that happen.  If it hasn't happened yet, consider yourself lucky.  But it will happen, because we are all human.  The only question is how much it will cost your company.  Accidentally drop your database?  If you have a current backup you may only lose a few hours of work: relatively cheap.  Disgruntled employee with full access to your production database?  Who knows how much that one will cost.

You can talk to Uber about the cost of these things. Their recent data breach was effectively caused by giving too many people access to their production systems.  The direct cost in dollars will likely be very large, and many years before they are done paying for it.  The legal ramifications will also take years to work out, and no one will be able to measure the loss of reputation from all of this.

Audit Trails!

h/t to baldPrussian
Another big downside of giving everyone direct database access is the complete lack of accountability it creates.  Above, I focus on the fact that accidental data breaches from employees are a thing.  Unfortunately, intentional data breaches from employees are also a thing.  They are less common than accidental breaches, but they do happen.  The problem with everyone getting full database access is that if data gets leaked, stolen, or maliciously modified, your chances of properly identifying the problem employee are substantially decreased.

Summary

Having worked predominantly for and with small businesses, I know that there is very much an attitude of trust.  When everyone knows everyone (and knows their kids by name), everything starts from the perspective of "This is a good person.  I don't have to worry about them.  Let's let them have access so they can do their job easier".  I'm sure this is how your company approaches the problem.  They are operating from a position of implicit trust.  As a result, I think your best bet is to focus on the potential damage done by accidental mistakes.  The issue is not that they can't trust their employees, but their employees are people and make mistakes just like the rest of it.  The more people you have who have direct access to the center of your business, the more likely it is that someday someone will do something that will accidentally nuke your business.  Again, this stuff happens.  If you need another example, just ask Pixar:

https://thenextweb.com/media/2012/05/21/how-pixars-toy-story-2-was-deleted-twice-once-by-technology-and-again-for-its-own-good/


How can RFID/NFC tags not be cloned when they are passive technology? Everywhere a question like this is asked, I see people responding that (in a scenario where a card is used) the card does some processing with the data it receives/generates some data when it receives a signal. How is this possible without power?

And even if that's the case, why can't every NFC tag in, let's say, credit cards just be cloned because there are no variables in them and only static data? You'd think those RFID tags could be copied and used for transactions.

Because the cards contain a chip which are powered by a coil.
The coil is not really a antenna, but half of a transformer.

Think your regular mobile charger. This contains a transformer, that will transform the voltage from 230V or 120V AC to 5V DC. This is done by having a coil magnetize some iron, and this iron magnetizes the "receiving coil". If you draw current from the receiving coil, the primary coil will also draw more current.

Now, let's go to the "passive" card again.

The reader is one half of a transformer, and the card is one half of a transformer, but this transformer does create a magnetic field in the air instead of magnetizing iron.
When you put the card close to the reader, the reader and card becomes a full transformer, and thus the card can be powered, like it was connected to a battery.

For the reader to transmit information to the card, the reader only needs to vary the frequency or amplitude of the AC voltage that powers the primary coil. The card can sense this and act on this information.
For the card to send information back to the reader, the card simply short-circuits its own antenna via a transistor and a resistor. This will, like the mobile charger, cause the primary coil, i.e. the coil in the reader, to consume more current, and the reader can sense this (by having the primary reader coil via a resistor and then measure the voltage over the resistor) and read the data the chip sends to the reader.

This means that half-duplex bidirectional communication is possible with RFID, thus the chip can do anything, and work like a contact smart-card.
And as you know, a contact smart card with a security chip, that can securely store a key, and only perform operations with the key, is impossible to "clone" or "copy" as the key cannot be extracted. That's the security of smart cards, they cannot be cloned, and that's why they are preferred over magnetic strip cards.

Thus, the same applies to wireless/contactless RFID card.


Is it possible for someone to send messages from my phone and seem like if I send it to them? Ok so there's this guy who pays my iPhone6 and lately it's been sending messages to him as if I was the person who typed it but it wasn't me... Does anyone get me? Someone please help!!

Yes this is very possible it's called sms spoofing. I have done it once before using a company such as txtNation. Companies like txtNation allow you to send sms from pretty much any phone number or 5 letter name. I will also add that sending a sms from a phone number you don't own is illegal in most countries


Why are files that are not assigned to a user considered a security risk? From the Linux Bible, edition 9:

  Files that are not assigned to any username are considered to be a security risk.

How is this possible and how could this be exploited?

Edit:My question isn't a duplicate of the mentioned question because my question is focused on the user creation process instead of focusing on the least privilege principle.

On a Linux system you can easily delete a user without having to delete any files owned by that user. Such a file will stay in place and the file owner's user ID (which is stored as an attribute of the inode) remains unchanged. This way a file can become effectively ownerless.

If you then later create a user with the same ID, the user will automatically become the owner of the previously orphaned files. That's how a new user may unintentionally (or with malicious intent) become the owner of files they shouldn't own, which is obviously bad for security.

Note that userdel has an extra switch to remove users along with their files, but it will only remove the files from some fixed locations, such as the home directory:

 -r, --remove
       Files in the user's home directory will be removed along with
       the home directory itself and the user's mail spool. Files
       located in other file systems will have to be searched for
       and deleted manually.

You may want to use find with the -nouser switch to discover files with a non-existent owner:

 -nouser
    No user corresponds to file's numeric user ID.

Here is a quick demo on Arch Linux.

Let's add a user alice and make her the owner of a file foo.

[root@box /]# useradd alice
[root@box /]# touch foo
[root@box /]# chown alice foo
[root@box /]# ls -l foo
-rw-r--r-- 1 alice root 0 Jan  5 02:59 foo

Now let's delete alice.

[root@box /]# userdel alice
[root@box /]# ls -l foo
-rw-r--r-- 1 1001 root 0 Jan  5 02:59 foo

ls can't determine the owner name and just displays the numeric owner ID 1001. Now let's add a new user bob.

[root@box /]# useradd bob
[root@box /]# ls -l foo
-rw-r--r-- 1 bob root 0 Jan  5 02:59 foo

Since bob has been assigned the next free user ID, he's now automatically the owner of the file.


Good (manual) system to come up with passwords for a wide range of requirements Situation
Over time I am required to choose and use many passwords in different environments. Some on my computer where I could choose to use a password manager, but many on client systems where I may not even have online access and definitely can't plug in a storage device. Sometimes one cannot even bring in any auxiliary resources like a phone.
Question
Assuming that I don't want to use a password manager and have to select and use passwords manually, what would be a good system for this?
Ideally the system should meet the following constraints:
System constraints

It should give me a password for (nearly) any combination of password constraints (see below)
It be comparatively easy to remember/recreate if I know the setting (and the date?!) and its constraints
It should be secure against someone who knows the system (but not the input parameters)
It should be secure after I use the system in an insecure environment and the password used there may leak. I am not worried about someone knowing more than 1 leaked password.
Bonus: It would be nice if it was secure against someone knowing an old password.

Example password constraints
Typical constraints in choosing a password (of course they vary per system):

Between min and max characters
No symbols / at least n symbols from a limited set
At least some letters of each case
Password must be changed periodically and does not match anything from last M periods

I am not worried about only numeric passwords

What have I tried?
I tried to come up with systems, but have not found anything that meets all system constraints (Or is good enough in general).
Example 1: smallest first fit
Just to show what a system could be like, I will mention this ridiculous example.

Keep adding the letter a, until the minimum character count is satisfied, for example aaaaaa
Recursively change a character till the constraints are met, you could end up with aaaaA1

This system will generate a password that can always match the requirements. Of course its strength can be horrible if you don't start with a random string. So this system would either fail system constraint 2 or 3.
Example 2: start with the core
I feel like this is not a strong system, but I believe it does get used in practice.

Choose a (hopefully strong) core, for example: securitystackexchange
Tweak it to match the requirements, for example: Securitystackexchange01

If you have a long core, it can typically lead to weak passwords when the max chars is limited. For example Security01. Also this system does not meet system constraint 4.
Example 3: Choose random characters within the requirements

Choose random characters within the requirements

One cannot remember many of these, so this does not qualify as something I can use manually and I would say this fails system constraint 2.

Update regarding password managers
I am not worried about the quality of password managers, and understand that their use would make this question trivial. However I am looking for an answer that does not require them because you may not be able to conveniently use them everywhere. For instance when it is not allowed to access the internet, install programs, or bring your own device.

An option (not saying it is great) is to combine the idea of the strong core with the notebook option.

Say you have a core like: secu_ritYstAcke_xChang_e01

You change this depending the requirements (say change 0 -> a, 1 -> b if numbers aren't allowed), the _'s you fill in from the notebook.
The notebook contains entries like: (doesn't need to be 3 times 6 chars or have the same pattern each time)

CompanyX : abc123, xyz!*@, (#*987

So the resulting password for CompanyX would be:

secuabc123ritYstAckexyz!*@xChang(#*987e01

I believe it clearly can satisfy constraints 1, 2 & 3.
For constraint 4 as long as both your "core" and "notebook values" are strong enough having 1 password exposed shouldn't dramatically increase the risk to the rest of your passwords as any of those characters could be "core" or not. Though it definitely redures the strenght.
Assuming you change your "core" part often enough constraint 5 should be met as well. Sure the "notebook values" remain the same but given that the "core" changes completely it should keep a good amount of entropy.

The notebook will represent a physical risk of course but in and of itself it shouldn't be enough, one would need one active password for it to completely break the system.

I would however definitely argue to use this system for as few systems as possible (only those where you can't bring your phone AND can't access the internet) and use a password manager for the rest as such method is a lot safer.


CVSS 3.1 -- does a scope change imply at the very least a low confidentiality impact? So I'm looking at scoring a vulnerability, and I'm waffling on how to handle Scope and Confidentiality impact.
If scope is changed, isn't confidentiality-impact necessarily changed to at least Low? If I can get into a scope I shouldn't have access to, I can definitely get information I shouldn't have access to, correct?

Hmm, I'm trying to think up a counter-example. Say you have a blind SSRF -- I can cause the server to send a request of my choosing to a host of my choosing within its LAN, but I can't see the response. That's definitely a scope change because I'm jumping from the host I'm allowed to talk to to one that I'm not. But it's not a confidentiality issue because I can't get any information out.


Is storing information in RAM more secure than on Disk? I realize neither is foolproof, of course. I would just like to confirm my thought that it's harder for an attacker to get a memory dump than to copy from disk/flash-storage or that malware just tends to copy from disk more than it does from RAM. So that wherever possible, it's better to have the apps I write avoid getting sensitive material on disk, and better to keep it in memory until needed.

This is not about a specific scenario, it's the general rule that I'm interested in.

There's a lot of nuance. Each process should only be able to access the area of memory which is assigned to it by the kernel. With file/disk access each process may be able to read files owned by their calling user, files marked as readable for the calling user's group and world-readable files.

That said, in the case of virtual memory and suspend/hibernate actions there is the possibility that the sensitive data which an application is dealing with in memory is written to disk by the system. (EDIT: It's been pointed out that newly allocated process RAM will be zeroed by the kernel in most situations, so processes which are killed are not likely to leave much remanence in RAM. It is, however, possible for a process which freed a malloc'ed variable to have leftover data swimming around in it's address space if that same process later malloc's a new variable, but that's not as relevant here. The other points still apply) Lastly, if the process which is handling the sensitive data happens to have a buffer overread vulnerability then that would allow an attacker to provide that process with a crafted input which would allow that attacker to read the current memory space of the process. Including the sensitive data...

I'd recommend keeping any sensitive data encrypted until the time at which it is needed. Normally this means keeping it encrypted on disk and decrypting it at time of use, but it may also be feasible to keep it encrypted in memory and decrypt at time of use (assuming the decrypting keys are not also stored in memory).


Multi-Single-Factor vs. Multi-Factor Authentication I was told at university that there exists a difference between the terms Multi Single Factor and Multi-Factor:

Multiple single-factor-authenticator are presented to a verifier. Each of them will need to be a single authenticator (and therefore contain a secret).

Multi-factor authenticator are used to protect a single secret, that will be presented to the verifier during an authentication protocol. The additional factors are used to protect the authenticator (secret) and need not themselves be authenticators.

I'm having troubles understanding the differences and consequences security wise.

Do I understand it correctly, that under the definition above, the typical ebanking login process by using a password (shared secret 1) and a hardware crypto token (RSA token) (shared secret 2) would be a multiple single factor authentication. On the other hand, under Multi-Factor-Authentication, I can only imagine a hardware token that needs a fingerprint and a pin to generate a one time password. Is that correct?

Question: What is more secure and why? Is the fact, that Multiple Single Factors use multiple shared secrets better or worse than protecting a single shared secret with multiple factors?

This definition you share for multi-factor authentication does not meet the commonly accepted industry definition.  Multi-factor just means that two or more factors, typically from different categories of authenticators, are used to authenticate.  It isn't specific regarding whether these factors unlock access to a local 'secret' that is used for further authentication or sent directly to the authentication server.

Either scenario still involves multi-factor authentication.  What these factors unlock as far as secrets, session tokens, or the like shouldn't really affect their name.

I can't say I've ever heard the term "multiple single-factor-authenticator" before.  I'd interpret this to mean you have a system that uses two factors from the same category, e.g. a password and a PIN.

Multi-factor authentication is generally going to be more secure than single factor because it should be more difficult for an attacker to compromise multiple factors.  They might be able to guess your password, but it is more difficult to both guess it and obtain a valid OTP tokencode.


Any Alternative to Ngrok for constant Connection? Im trying to build RAT to test on my computer. I use ngrok for hacking on WAN. But ngrok has a problem of changing its subdomain once the connection is reset. So, I cant use ngrok for hacking over WAN. I tried using ngrok sub-domain, but now it has become a premium plan. Please suggest me some alternatives for ngrok which will provide me constant subdomain even if the connection is reset. Also, suggest if there are any other methods for hacking over WAN other than SSH Tunneling, Using VPN and port forwarding.

I run https://serveo.net/. It provides a stable subdomain as you require, and as an added benefit, it uses SSH port forwarding, so you probably don't even need to install anything—just use your SSH client.

Use it like this (where localhost:9000 is the address you want to forward to):

ssh -R 80:localhost:9000 serveo.net

Or, to make sure you get a particular subdomain:

ssh -R magis:80:localhost:9000 serveo.net

(Where magis is a subdomain you were previously assigned.)


Is OpenBSD's low number of exploits really that relevant? The number of OpenBSD's known vulnerabilities is tiny, but so it's the number of users. How significant is this scarceness of exploits found?

Yes, it's relevant, but you have to understand the context.

There are several ways a platform can achieve a low rate of exploitation such as code quality, a hardened configuration, a limited feature set, and obscurity. There's no doubt that OpenBSD benefits from obscurity to some degree - if it were as popular as Linux or Windows, many more people would be scrutinizing it. However, it's had so few exploitable flaws over time that you can't simply write off it's track record as obscurity alone. Other platforms of a similar size usually contain many more exploitable bugs.

OpenBSD has consistently emphasized code quality over features, and has always minimized the number of services listening by default, so there just isn't much attack surface. It's a minimalist OS compared to Linux and Windows, so it's really a different animal.


how to trace or get evidence you've been hacked my devices and my network have been compromised. I foolishly left my router unprotected
and they were able to gain access to all my apple devices and then install some sort of software that will take pictures and record audio and store them in their metadata so it remains hidden on my computer. This person has then set up a page and has leaked my personal pics & is spreading terrible rumors about me .......can anyone help me out...with the specifics on how this is done. So I can build a case against this person .....its gotten so bad that there saying I'm some sort of child predator and diseased pervert.

Your first priority: repression. Make sure that your security is tight and no more information is leaked.

Second priority: repair. Don't try to fight the criminal yourself. Go to the police and report a crime. Most police forces have a digital forensic team that can do the things needed. Let's just hope that they have the time/resources/priority to look into your case.


What type of cipher is RSA? Is RSA a stream cipher or a block cipher?

RSA is a block cipher and can use variable-length block sizes.  Simply because it is not symmetric does not mean it can not be a block or stream cipher.  Further, while it is not intended to be used as a block cipher, it is nonetheless a block cipher.  Confused yet?  :)

RSA is typically meant to only encrypt very small pieces of data, typically hashes and symmetric key that are then used to encrypt the majority of the data.  However, RSA encryption/decryption works on blocks of data, usually 64 or 128 bits at a time.  The size of the blocks is determined at run time.  Since the requisite data can often be en(de)crypted in a single use, it is often mistakenly assumed that it is not a block cipher because the data is a single block, rather than several.  This does not change the fact that it does indeed work in a block cipher manner.


What is the difference between APSA and APSB? What would be the difference between Adobe APSA and APSB security bulletins / advisories?

Adobe Product Security Bulletin (APSB): An announcement about a security vulnerability in an Adobe product. The vulnerability has been patched, and the solution is to update to a newer version of the product.
Adobe Product Security Advisory (APSA): Same as APSB, except that the vulnerability has not been patched yet, and a fix update isn't available yet. A solution is either to downgrade to a safe version, using other mitigation methods, or that there's no current solution.


What is the Digests section in cryptsetup If you run the command cryptsetup luksDump /dev/sda5 (change device to whatever LUKS encrypted device), you will get an output, and at the end there is a section "Digests" which contains something like this:

Digests:
  0: pbkdf2
    Hash:       sha256
    Iterations: 104492

What does this section represent? Why does it show sha256 here and argon2i in the Keyslots section?

The Keyslots section shows the password hash used as argon2i:

Keyslots:
  0: luks2
    Key:        512 bits
    Priority:   normal
    Cipher:     aes-xts-plain64
    Cipher key: 512 bits
    PBKDF:      argon2i

TLDR;
So, technically from this set of output, we can observe that :
" cryptsetup() is using LUKS2 and LUKS2 is using Argon2i as a Key Derivation Function.
Now, this Argon2i implementation might be using HMAC as PRF and that HMAC is using SHA256 as an underlying hashing function."
MORE ON IT -
A Key Derivation Function  (eg. PBKDF2, ARGON2, etc.) is generally a high-level function that needs to work with an underlying PRF (Pseudo-Random Function) and generally, it's HMAC (Hash-based Message Authentication Code).
It's not mandatory to use HMAC but generally, it is used with some Modern KDFs.
Now HMAC needs an underlying Hash Function to work and in this case, it's SHA256.
So it's like when they say "PBKDF2 with SHA256" they are saying "We use PBKDF2 which uses HMAC as Pseudo-Random Function and HMAC uses SHA256 as the underlying hashing function in it"
This theory works with most of the Modern KDFs.
Now when you look at the output again, see it as follows:
*Digests:
  0: pbkdf2
    Hash:       sha256
    Iterations: 104492*

The above output tells us the properties of the PBKDF2 function (or Argon2i in this case). notice 0:pbkdf2.
The next output,
Keyslots:
  0: luks2
    Key:        512 bits
    Priority:   normal
    Cipher:     aes-xts-plain64
    Cipher key: 512 bits
    PBKDF:      argon2i

This tells us properties of LUKS2 (Linux Unified Key Setup) notice 0:luks2, which means LUKS2 is using key derivation function - argon2i.
Also, Argon2 is a KDF.
Argon2i is optimized to resist side-channel attacks. It accesses the memory array in a password independent order.[wiki]
LUKS1 defaults to PBKDF2 while LUKS2 support Argon2i.
PBKDF2 for LUKS1 (LUKS1 header format is limiting)
Argon2i for LUKS2 (LUKS2 comes with a new header format)

*More Resources :*
PBKDF2 : https://en.wikipedia.org/wiki/PBKDF2 | https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf | https://www.ietf.org/rfc/rfc2898.txt
HMAC:  https://en.wikipedia.org/wiki/HMAC | https://www.ietf.org/rfc/rfc2104.txt
LUKS: https://guardianproject.info/archive/luks/ | https://access.redhat.com/solutions/100463
ARGON2: https://en.wikipedia.org/wiki/Argon2 | https://www.cryptolux.org/images/0/0d/Argon2.pdf
Somewhat HMAC Related Stack* Question :
https://crypto.stackexchange.com/questions/35275/whats-the-difference-between-pbkdf-and-sha-and-why-use-them-together
I hope this helps. Please comment below for clarification on any point if needed.


Should a user be able unlock his own account after being automatically locked out? Should a user be able to unlock his own account after being locked out?

Typically there are requirements that specify that users are to be automatically locked out:

The user's account should be locked after too many failed password attempts
The user's account should be locked out after 90 days of inactivity.

The question is, once an account has been automatically locked out, should the user be able to unlock their own account (via a password reset mechanism or security questions), or is it more secure to involve a system administrator to unlock the account?

As security practitioner (CISSP) we always have to fight with/work with/debate with the organization between the balance of confidentially and availability.

Therefore, in my environment we allow users to unlock their account if they provide sensitive information that an hacker should not know. It just created another step for hackers and to allow legitimate users to get back to work.

If you are looking for the most secure possibility, of course it would require a human to look at logs and manually unlock the account.

Depends on your environments needs, how many users, and how much overhead you can afford to invest in these tasks.

Best of luck, I'm available for additional questions.


What is "cardholder data" in PCI-DSS SAQ A context? The PCI-DSS SAQ-A questionnaire mentions on page iii that

  SAQ A merchants confirm that, for this payment channel:

  (...)

  Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically.

The PCI-DSS glossary defines "cardholder data" as

  Cardholder Data: At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN
  plus any of the following: cardholder name, expiration date and/or
  service code See Sensitive Authentication Data for additional data
  elements that may be transmitted or processed (but not stored) as part
  of a payment transaction.

I have a hard time connecting both in the context of the SAQ-A. Apparently we could have received paper receipts from the payment processor (to which payments are outsourced) and that would have been fine provided they are stored correctly (per the requirements of PCI-DSS SAQ-A).

How are these receipts different from the "feedback" we will receive electronically? This "feedback" will hold some data like a name, a payment amount, a date.

In other words: would a paper receipt contain the PAN? If no, how is that different from the electronic acknowledgement the merchant gets from the processor (right after a successful payment, or later in the form of a summary of transactions)

From the comments it appears that your question is essentially this: Why is paper documentation of a transaction treated differently than electronic replies or documentation from a transaction, at least in terms of those documents containing full, unencrypted PANs? (Meaning full, unmasked credit and debit card numbers.)

Well, my first response is simply this: ideally merchants shouldn't keep materials with full PANs on/in them, even in paper form . Although the PCI Requirements that apply to SAQ-A merchants do not prohibit having cleartext card numbers visible on paper documentation, they do impose requirements that you need to pay attention to in terms or the creation, storage, handling, use, and destruction of such paper documents. For more complete information on those requirements see "Can we print cardholder data under the PCI DSS Compliance framework and stay compliant?" But the bottom line is that creating, storing, or even just receiving printed materials with full PAN data in them at best creates more compliance and security headaches for you, and at worst, of course, increases the risk that card data will be compromised.  Thus, unless you really, really have a special, unavoidable need to receive and temporarily store card numbers on paper from your processor (and frankly my mind is blanking on thinking up any scenario where that would be true) the best way forward is simply not to receive or store them at all.  And frankly if you're dealing with a payment processor who is sending you paper material with full PANs in it without an exceptionally good reason I would firmly advise that you to take another good look at whether you want to stick with that processor.

Secondly, if we're pondering the question of why you might be allowed to store clear-text card numbers on paper at all when you are forbidden from doing so electronically, well the answer to that is straight-forward enough: the Internet is a dangerous place, and any machine connected to it is exposed to that danger. Any machine or network that psyically has an electronic connection is exposed, in (in theory) to electronic attack from any of the more that two billion people who now have some kind of access to it, from every corner of the world. Tireless automated scanning tools or human attackers checking the security of every merchant that they're aware of the existence of can check the router that ties your small network to the Internet for security configuration problems. Problems that can allow and attacker to access everything on your network as if he or she was physically in your building/s and plugging in with an Ethernet cable or connecting to your wifi.  Automated phishing campaigns bombard hundreds of thousands or millions of users with emails containing links that lead to websites serving malware or come with attached files that are infected with it.  In either case, an attacker again gains access to your internal network or, worse, is able to get a copy of any card numbers that are entered in to an infected machine or even any card numbers that ever come into its memory, even for a few seconds.

By contrast, paper documents are simply not as exposed to bad guys to the same degree and in the same way. Only people who know that you keep the data and where can deliberately try to steal it, a far different situation--though still a concerning one-- than a situation where PANs are kept as electronic information on a device that can interact with a network that two billion people. (And lots of electronic scans running on it from bad actors, hunting for weakly defended systems and improperly-secured financial data on them.) That being said, as discussed above the better practice, by far, is not to store any unencrypted card numbers anywhere in your operations, whether in electronic or paper form.


Is using X-Real-IP as a way to check for localhost access safe? I have an application listening on the port 5000 that can be accessed to the internet through nginx with this configuration:

upstream myapp {
    server 127.0.0.1:5000;
}
server {
    listen 80;
    location / {
        proxy_pass http://myapp;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
#...
}

Now, assuming the port 5000 can only be accessed directly from the localhost, I assume that all external communication is handled by nginx, I am assuming that all requests that the application receives which do not have the X-Real-IP header come from localhost.

Are these assumptions wrong? Could a person with no access to the machine still access the web application without auth? Am I missing something?

Edit: I think I may not be stating a clear question here. Probably a mix between my lack of knowledge and me thinking I am understanding something fundamentally wrong. So, I think you could sum up my doubts in answering this:

In this situation, can I assume that if a request to my web app does not have the "X-Real-IP" header then it's coming from localhost?

or the opposite:

Can I somehow forge a request that would make nginx not set the X-Real-IP header, given the configuration above?

Cheers!

You are already asuming that only localhost traffic can reach your web app on port 5000. Thus, checking any header you set in nginx is not the factor in deciding wether this is a request from localhost - all are, by definition.

If your question rather is

  can I assume that all that have the 'X-Real-IP' Header set come from 'nginx'"

the answer would be "no"; you can easily curl that on localhost.

Edit to reflect the edit in the question:

You can assume - with your presumptions - that every request on port 5000 comes from localhost, regardless of the headers.

As of now (i.e., to my knowledge, there is no exploit to allow that happening regardless of the configuration), if that configuration is all the configuration there is, there is no way to make nginx forward a request without setting the header.


Shellcode doesn't execute despite correct address on EIP I need to produce a presentation on buffer overflows for a college class. I managed to create a simple buffer overflow where i inject the address of a specific function on the EIP and the function gets executed as expected.

Then, i want to show the more interesting example where i inject shellcode that gets executed. That's when it stops working. I emulated the way people explained it on various websites, but it doesn't work.

Regardless of the shellcode i use (Shellcode), the issue is that the code i injected doesn't get executed. So the program jumps to the correct address, then stops without executing whatever is at the address.

So as you may see in central section of the picture, named "code", the program accesses my nop sled, at address 0xbffff2e0 (shellcode starts 4 bytes below), but nothing happens.

Then, the error output says that it tried to access 0xbffff2e0 but couldn't find anything (see bottom of the image : "0xbffff2e0 in ?? ()" ).

Do you have an idea on what's happening?

What am i missing?

Edit : i'm adding the code used in this exercise, as asked

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

void secret(){
        printf("This is a secret message : you are Awesome!\n");
}

void denied(){
        printf("You don't have the permission to see the secret.\n");
}

int main(int argc, char *argv[]){
        char buf[20];

        strcpy(buf, argv[1]);
        printf("%s\n",buf);

        if(strcmp(buf, "myPassword") == 0){
                secret();
        }
        else{
                denied();
        }

        return 0;
}

The stack is probably non-executable. Compile the vulnerable program like this to disable the protection:

gcc -z execstack -o program program.c


Impairment of security by introduction of ipv6 If you get a public IPv6 on your device, and someone gets hold of your momentary IPv6 (which changes every 24h by the privacy extensions), a possible attacker could start a lot of automated tools on your device directly to try to hack it.

So it seems like public IPv6 seems an impairment of security compared to NATted ipv4?

How large is this impairment of security?

This is not the intention of NAT, but through NAT the machines are somehow "protected". It is as if the NAT system was also, inherently, a firewall.

  To switch to IPv6 nicely, you have to couple its enabling with some solid, well-thought firewalling rules, which will prevent incoming connections which were not possible in a NAT world, but are now feasible thanks to the magic of IPv6.

Source: https://security.stackexchange.com/a/44068/13212


A new programming paradigm (e.g., Rust) to reduce or end all zero-day vulnerabilities/exploits? In view of the Hafnium and Solarwind hacks, where multiple zero-day vulnerabilities were used to ultimately stage the hack and data exfiltration, would the use of memory safe programming languages such as Rust to build software help to reduce or end all these zero-day vulnerabilities/exploits through a programming paradigm?
More to the point, is there anything (an architecture, a programming paradigm) we can do to reduce/stop zero-day vulnerabilities/exploits so data exfiltration can become a thing of the past?
There are so many security tools out there, so many sophisticated cybersecurity providers, but none seem to be able to stop these zero-day vulnerabilities/exploits -- perhaps the solution is something easier and within our grasp? Instead of a patchwork of tools, would something as fundamental as the language one uses to develop software be the key to ending all zero-day vulnerabilities/exploits?

0-days are gonna be a thing as long as humans are making software.
A single exec/eval is often enough for an exploit. Using memory-safe languages like Rust or high-level languages mostly remove memory issues but introduce entire categories of attack vectors, e.g. Code Injection for interpreted languages like Python. There's also logic errors, such as TOCTOU errors, off-by-1 errors, and forgetting to check certain parameters.
Putting malicious code in your software because you copy-pasted some code from a stranger on the internet without checking the code or accepting a pull request made by a malicious or newbie programmer is another way you can introduce bugs to your code without knowing.
Humans are prone to mistakes and will continue making dumb mistakes, whether you like it or not. 0-days aren't just memory issues, they're often logic bugs that can't be caught by software and need to be checked by people.