Hundreds of legitimate IPs are hitting my website like bots I'm having a huge problem with my website due to a weird spike on hits.

Today, i'm getting several hundred hits. Normally, i get a lot less, and they are from me country.

Today's hits are from every country on the map. They are all direct hits (no referral) and they hit my main page. Most of them stay for 0 seconds and then leave. They are not bots and they seem to originate from legitimate IPs. But those users couldn't possibly know the address of my website (and type it on their browser).

This is giving me huge problems, since it causes high CPU usage on my web hosting. So, i have to find a solution fast.

Examples:

78.225.147.100 - - [04/Jul/2014:19:48:23 +0300] "GET / HTTP/1.1" 301 138 "-" "Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0)"
78.225.147.100 - - [04/Jul/2014:19:48:23 +0300] "GET / HTTP/1.1" 200 21192 "-" "Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0)"
181.196.13.128 - - [04/Jul/2014:19:50:50 +0300] "GET / HTTP/1.1" 301 138 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
181.196.13.128 - - [04/Jul/2014:19:50:51 +0300] "GET / HTTP/1.1" 200 21192 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
77.105.21.227 - - [04/Jul/2014:20:07:32 +0300] "GET / HTTP/1.1" 301 138 "-" "Mozilla/5.0 (compatible; MSIE 9.11; Windows NT 6.1; Trident/6.0)"
77.105.21.227 - - [04/Jul/2014:20:07:33 +0300] "GET / HTTP/1.1" 200 21192 "-" "Mozilla/5.0 (compatible; MSIE 9.11; Windows NT 6.1; Trident/6.0)"

I believe that it's some kind of malware that has infected thousands of computers and, for some reason, those computers are now hitting my website.

So, any help is appreciated!

A few hundred hits per day should not significantly affect your CPU usage.

Here are some things you can do to try to diagnose the problem:

Change your IP address or use a dynamic IP address.  This will tell you whether you are being targeted by domain name or by IP address (the latter being more likely to be an automated attack).
Take down your web server for a day or two and then bring it back up.  Does the traffic return immediately?
Pick some of the IP addresses and track them down.  See if you can contact a local sysadmin to ask about the traffic.


Secured Software Update from an unauthenticated entity Let's suppose we have a software update D, that is encrypted and signed and delivered to some component C. Further we suppose that the receiving entity C can validate the signature and decrypt the software successfully.
I asking myself whether the sending entity needs to authenticate itself to C, e.g. by means an authenticated Diffie-Hellman Key Exchange to create a secure Channel and to authenticate the sending entity against component C.
As the software update is already encrypted and its origin can be verified, I am asking myself whether the sending entity needs to authenticate themselves. Are there any security issues, when sending secured software over an insecure channel?

As the software update is already encrypted and its origin can be verified, I am asking myself whether the sending entity needs to authenticate themselves. Are there any security issues, when sending secured software over an insecure channel?

This is largely how Linux distributions such as OpenSUSE, Debian, Ubuntu and others distribute their software. Individual pieces of software is signed by a gpg key, which is trusted by the operating system.
The download is not authenticated or secured; any MiTM is generally free to modify data as they see fit. However, doing so breaks the signature - and the update will not be installed. On Debian, size, md5sum and sha256sum is verified. If all match, package will be installed.
One possible attack here is delaying updates. As previous content tables are signed, they are valid, so a MiTM attacker can reply that 'sorry, no updates for you', and the client will be none the wiser that there may actually be important updates.
A fix for this is to make the client give alarm is no new content appears for a set period. For projects such as Ubuntu, Debian or OpenSUSE, it's rare to go many days without updates, so this would be a solid hint that something is up.
So in short; as long as you use a suitable signature, this distribution model is secure. You don't need to trust the entity that sends you the update; at worst they can send you a broken update, which will not be trusted.


How secure is an archive file if the password is cryptographically random? I looked for an answer for this question over here, yet all I could find were about cracking the password. So let's say I'm using PHP to generate a cryptographically secure random password:

echo "Password: " . bin2hex(openssl_random_pseudo_bytes(32, true));

  Password: 7c81c0426b1b636c505420776e8c080032da122e6ec462d837a87dab3bded596

Having this password, it seems like it would be easier to guess the hash itself and decrypt the files manually (so the attacker wouldn't have to waste time on hashing the password everytime to check if it is correct).

How hard will it be to hack the rar/zip, without hacking the password itself?

From an information theory point of view, your password contains 32×8=256 bits of information. If your encryption key is also 256 bits long, you would need in average 2^255 tries to brute-force the key or the password: they would be of the same strength. If however your encryption key or the hash of your password is 128 bits long, it would need in average 2^127 tries to brute-force them: it would then be a waste of time to brute-force the password, guessing the encryption key would be astronomically faster, even with a less efficient algorithm.

In practice you would need the adapt the brute-forcing algorithm to check if the decryption of the archive succeeded or could succeed. This would use heuristics and possibly the checksums commonly found in archive formats.

Also, in practice, you don't event try to brute-force 2^128 combinations. You try the side door.


What common products use Public-key cryptography? I want know what common use products are there that use public key/private key cryptography?

Public/Private key crypto is used in a wide variety of protocols and data formats, which are implemented by a huge range of application and system software:

SSL (https) protocol
SSH (secure remote login, tunneling, etc) (public/private authn/authz is optional)
Digitally signed PDF files (including attachments within the PDF)
Signed Applets and jar archive files for Java
Digital signatures in the packaging infrastructure for Debian, Ubuntu and Red Hat Linux distributions, etc.
PGP/GPG for signed and/or encrypted files and email (perhaps the first widely used non-military public/private key crypto?)
S/MIME for signed and/or encrypted email
DNSSEC for securing the DNS
Internet Key Exchange (IKE) in IPsec for secure low-level TCP/UDP networking
RFC 3161 for authenticated timestamps
Most other encryption or signature schemes which don't require prior out-of-band secure communication between the parties.  Many are described at http://www.apps.ietf.org/rfc/seclist.html
A variety of other uses, like digital cash and secure transparent voting (see e.g. the trustee keys for Helios)


How can I create a hidden Administrator account in a public computer? After my journey for finding a way to create a truly private user account in a public computer (the setup I'm trying to do this on is detailed in this other question) ended in an epic fail I'm now taking a different approach to the subject: creating a regular admin account (I accept suggestions that require the super administrator account, but I'd like to avoid it) but make finding it extremely hard if you don't know what you're doing/looking after. Interactive logon is enabled on the college computer, so it helps I guess.

I need the account to not show up on the:

Users folder.
logon screen (we got interactive logon so this is easy).
net user command/any user listing.

These characteristics are the most necessary ones since without them it's possible to come across the account by accident. If you have a suggestion that only fits 1 or 2 of them please don't hesitate to comment, anything helps! Additional coverage/hiding and boring maneuvers like disabling/enabling the account every time I want to use it are welcome too.

I don't think you can hide a user from the net user command. I may be wrong on that point, but if I remember correctly net user use the SAM file that manage all users accounts.

But you can hide a user from the user folder and the logon screen with the cmd command :

reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\Userlist" /v <ACCOUNTNAME> /t REG_DWORD /d 1 /f

(Replace the <ACCOUNTNAME> with your account name)


Where can I practice web-security or network-security? Possible Duplicate:
  Servers for penetration testing

I'm in a process of learning security of networks and websites.
I already practised code reviewing but I want to perform exercise.

Is there any online resources to get our hands dirty instead of just looking at code and word for learning web security or network security?

I would recommend that you have a look at some of the wargames out there. For example one of my personal favourites is Over the Wire where they provide several games of varying difficulty. Certainly makes for a much more entertaining and thrilling learning experience.

Another one more specifically targeting web-hacking is Hack This Site split into varying levels of difficulty.


How to sniff traffic on my wireless network? For educational purposes, I want to see what packages are sent over my home wifi with VPN on and off. What program should I use for this?

Wireshark or tcpdump would both be useful if you want to dump packets going across the network all you need is to put an interface into promiscuous mode and you should be able to see packets flying across your network. There are lots of tutorials on using wireshark and tcpdump in the interweb.

UPDATE:

monitoring outgoing network traffic this question also appears to address what you are asking with regards to tools for examining network traffic.


Confused about the most relevant way to secure my APIs I own a Javascript application (Single Page Application) hitting some apis from my own RESTful backend.

What I expect for my authentication/(authorization) mechanism is three things:

Preventing all known malicious ways of stealing or acting on user's data: CSRF, XSS etc..
Allowing only my Javascript official client to reach secured API of my backend.
Encrypting all the messages exchanged.

I'm not expert in security but I read some good articles about a guideline to follow:

Avoid an authentication way based ONLY on cookie mechanism, as this article well explains.
HTTPS is not enough, yet it is really really advise to ensure at least messages encryption.
Consider Javascript client as totally unsecured as its code is visible to anyone.

Of course, I agree with those principles but...I'm confused about the number of similar ways to achieve a good authentication mechanism:

What is the difference between the article I put in link just above and the OAuth 2.0 Resource Owner Password Credentials Flow?
Indeed, both use those steps: exchanging username and password for an access token that is itself sent along the user's navigation using the HTTP Authorization Header.
What additional security aspect does this OAuth 2.0 workflow bring compared to the cookie-based token solution?
Does the solution of cookie-based token as presented in the article is really enough to secure my infrastructure? As the author claims..
I came across this another great solution, that I judge also similar to others, excepted that it doesn't really need https since based on shared secret key: HMAC mechanism.

What would a security expert advise me?
I don't exchange really sensitive data like money accounts etc.. but enough data to annoy users if something unexpected happens..

I would be happy to be more clear (in comments), but I hope I am.

I came across so many forums, articles, videos, etc... but I'm still confused about those different ways of achieving the thing.

Thanks

The difference is : OAuth 2.0 is a standardized protocol, and there is many implementations in differents langages (JAVA, Python, PHP, JavaScript...etc) for both client and server sides. So you don't need to follow this article to implement something which "seems" similar to the OAuth 2.0 protocol and probably not secured.

For the cookie-based token solution : an attacker maybe can still a cookie from a logged (an authorized) user.

So, I think the best solution is to use the OAuth 2.0 protocol which already used by many corporations(facebook,twitter) for thier APIs


How to deal with password schemes that can produce weak passwords? Introduction
Since the xkcd note on password strength, there has been a lot of attention for password entropy.
However, this raised the question: what if you used a strong scheme, but happened to get a weak password?
I can think of two main problems:

You choose a password via one strong scheme, but it is also possible to get this password via an existing used weaker scheme
You choose a password via one strong scheme, but it is also possible to get this password via a not yet used weaker scheme

Example 1
You pick a single number uniformly random from anywhere between 0 and 2^n for a large n. Ignoring practical inconveniences, there is a chance that you draw 0. Now you are stuck with a password that could be generated via so many weak schemes that you would really not be safe if you use it.
Example 2
You compile a nice large set of words, and draw four of them. You draw: 'correcthorsebatterystaple'. You are very satisfied as you are not aware of any weak scheme that would produce this. However, the next day some guy uses it in a comic, and it becomes immediately part of the scheme 'use a popular quote as your password' which is not nearly as strong as you would like.
Additional example
Suppose you have to pick a pin code for your bank. It is only four digits, but an attacker has limited tries available. Uniformly picking one of the codes gives an attacker who knows your 'scheme' least chance to crack the code in time. However, you know that some lazy people will choose things like 0000 1111 1234, and that attackers are more likely to try those. So your random draw ends in 0000 (not impossible), now what?
Question
I imagine that part of this problem can be prevented, and hopefully the other part can at least be monitored, but I don't know how one would approach this in practice, so therefore I ask:
How to practically deal with the fact that your properly generated password may actually be or become weak?

You don't get a weak password out of a strong scheme, because there is no such thing as password strength. Sometimes we say "this password is weak", but what we really mean (that is, if the "we" that is speaking knows what he is talking about) is that "this password generation method is weak".

The important point here is that password security, just like anything else in cryptography, is probabilistic in nature. For instance, when we generate a RSA key, we are just assuming that any attacker will not guess the private key right away through sheer luck. We can live with that assumption because we know that the probability of the attacker getting that lucky is sufficiently small to be neglected. The same applies to passwords: if the generation process produces passwords with "40 bits of entropy", then this means that on average, attackers will need 239 tries to find the right one. However, they may get lucky, or unlucky, on any specific password; this is an average.

Probabilities rule our whole lives. Every single decision we take is in fact probabilistic; we accept to, say, take a bus ride because we balance the convenience of taking the bus with the involved risks, risks being a combination of the consequences of an unfortunate event and the probability that such an event occurs. Namely, we take the bus because we rely on the bus not being struck by a falling asteroid, and also because sitting close to a smelly unhygienic fellow traveller is both non-lethal and still not frequent enough to warrant travelling on foot instead.

Passwords are no exception to this rule. We use passwords for authentication because we estimate that the involved risks are low enough. A sub-theme is that attackers are also humans who take probability-dependent decisions; an attacker will not try to guess the password if the password generation method is such that his chances of success are very low. Attackers who run PC farms must think in terms of average; namely, they must think in terms of costs and bills, which are good examples of everyday averages.

Another way to state it is that the probability that you draw "correcthorsebatterystaple" (2-44 in the conditions assumed in the comic) is equal to the probability of the attacker guessing your password in one try if you got any other of the 244 possibilities. If you deem that the latter probability is low enough to be tolerated, then so must be the former.

Thus, worrying specially about the occasional "weak" password is not rational -- this is only a subcase of the average password security. It is, in fact, the same problem. You can just consider that by generating your own password, you are "just" performing yourself the first attacker's try. If you consider it that way, then you see that you are not actually giving any advantage to the attacker regardless of the password you obtained.

(It may be argued that if you apply defensive procedures, e.g. generating a new password if you find that the one you got is "weak", then you are actually shrinking your password space, and that reduces security, not increases it.)


Can my smartphone apps that I am using be seen in the router? If I am using apps on my smartphone can the network admin. see the apps I am using on my smartphone?

Some apps will use insecure communication (HTTP) and then your data will be visible. If you have a Mobile Device Management solution such as Intune, it will also report the apps you have installed and might install an SSL certificate to strip your traffic.

Also, the destination of the traffic can disclose information on the apps being used. If you want to stay hidden from a network admin, you can best use a VPN tunnel or Tor (But TOR will be a big red flag in a decent company). VPN and Tor communication can be blocked in companies.


Possible to receive welcome emails without visiting website? I don't know if this is the right place to ask this question, but I would like to give it a try.

A couple of days ago I was looking for a product that I wanted to buy. Visited a couple of websites, webshops, used some keywords in Google. Didn't buy anything.

The day after, I received a welcome email from a website I've never visited (I am 100% sure I never did). It's a website that offers products on discount. Thought it was a bit weird, it even had my name in it, and I wondered: why am I subscribed to this list.

But when I opened it (just curious), it became scary: the product I was looking for the other day was mentioned in it! They gave me a coupon so that I could buy the product for almost nothing.

Usually I am not that paranoid and of course it is not a big problem, but I just don't understand how this works. Is this even possible? How does this kind of marketing (?) work? Like I said I am 100% sure I never visited the website.

Hope someone can help me out (and sorry if I am posting this on the wrong page).

There are a few ways this could be done.  Did you happen to be logged in to your google account while surfing these websites?  If so, the fact that you used Google to search anything could have been the cause.  Google uses your search criteria and even content of your emails to advertise to you, sometimes through 3rd pat affiliates that will send you emails .

Regardless, two things are for sure, this website is somehow affiliated with one of the sites you used and they've successfully acquired your information and search criteria to advertise to you.  This is the result of using free email services that nearly everyone uses these days.  Nothing is ever free online, you always pay for it somehow.


Are passwords stored in the cookie? encrypted? Whenever I connect to security.stack.exchange, I am automatically logged in. I haven't allowed the browser to store my password. When I delete all cookies stored by the security.stack.exchange, I have to login by myself by entering username and password. Therefore, I concluded stack.exchange must be storing either a unique identifier or passwords in cookies which enable the automatic login.

When I checked cookies stored by Stack Exchange, I found the content of cookie named "security user" containing t="something"&s="something". Is this my username and password? Are the passwords saved in the cookie encrypted?

Using chrome browser, I found there are 3 cookies stored by stackexchange.
i.   "gauthed"
ii. "security user" containing t=""&s=""
iii. "sgt" containing id

Deleting the cookie "sgt" which I believe stores my unique identifier, i am still logged in automatically. Therefore, I am suspicious about the cookie "security user".

Also, if I haven't allowed my browser to store my password then why should a website store the login information without my consent. Is this a right behaviour?

Usually, the password isn't stored in the cookie.  You login to example.com with your username and password, these are verified to belong to you (typically by hashing your password and checking the hash of your password matches with the hash for a user with that username), and the server issues you a long random number token as a secret identifier for you.

Say they choose 24 random characters from 62 characters (26 uppercase letters, 26 lowercase letters, 10 numbers).  They store this identifier in their database as being valid and associated with you.  Every time you make a request while logged in - you send the cookie to your website.  Every time there is a request sent in with this identifier, they look up if its associated with a valid logged-in user, and if it is they give the information about that user.

There are 6224 ~ 1043 ~ 2142 possibilities.  If your website has a billion (10^9) signed in users at any moment who were issued tokens, you'd have to try roughly 10^37 possibilities until you'd be lucky enough to randomly guess one.  (If each try takes 1 nanosecond, it would take you about 1011 billion years before you were lucky to guess a valid token).

Your session cookie is typically only valid for a certain amount of time, which will also be stored in the server side database.

There are other variations on this theme, e.g., using HMAC (hash message authentication codes) with a stored timestamp based on a server-side secret.  That is when you login the server gives you a timestamp as well as a strong hash of that timestamp and your username that is combined with a server side secret.   That is you the server calculates h=HMAC(secret + timestamp + username) when you login, gives you back the calculated h -- and then you send (h, username, and timestamp) as your login information.  (And the server takes your username and timestamp, recalculates h and compares it to the h you gave, and makes sure the timestamp is still valid and not very old).

Now I am not particularly familiar with the particulars of how stackexchange does it (e.g., what the t=...&s=.... part of the .security.stackexchange.com), but its probably a variation on this scheme.  That is it does not encrypt your username or password in a recoverable way -- it either is stored in a database or is based on one-way hash function that relies on a server-side secret.


Do Flash memory (SSD) architecture impacts encryption techniques? I'm working on encryption techniques on SSD's and my question is: does the erase before write architecture of SSD's has anything to do with the encryption technique?

What are the problems I might face on implementing hard drive encryption to SSD's?

The whole idea of encryption is that it is meant to bring you confidentiality regardless of how the physical media is managed. Details about how a bit is "erased" (or fails to be erased) is relevant to security; encryption is about getting said security without having to bother with those details.

It turns out that data on a SSD is a fickle thing and it is hard work to track out all the places where it goes; see this question for details. This just emphases that encryption is the only sure method to keep the data confidential.

Disk encryption on a SSD is not different to disk encryption on a "classical" magnetic disk. Their interface is identical: accesses by indexed 512-byte sectors. This does not make SSD encryption simple, only not harder. Disk encryption is by itself a complex problem: it must handle random access (both for reading and writing), be fast (disks have a huge bandwidth), be integrated in the operating system, and should resist active attackers who can shut down the machine, swap some sectors, and power it on again.


Is RSA useless when my app is fully decompiled? I've programmed an Android game with Unity Engine. As you know in Unity, scripts compiled into one file named "Assembly-CSharp.dll". I wrote my scripts in C#.

After I compiled whole game into .apk, I renamed it to .zip and dragged the Assembly-CSharp.dll into tools like ILSpy, while the whole program was fully decompiled with all of the details like my RSA public key or AES password, IV, salt ...
The logic of my app is client (Android) and server (Java).

When player finished a level, with this URL:   http://www.example.com:8080/MyApp/SaveScores.do?hash=labla....labla, we give him score.
The real parameters are username, score, timestamp. Our encryption algorithm is RSA 1024 bit.

When cheater/attacker sniffs HTTP traffic to use replay attack, we check the decrypted hash with RSA and with timestamp parameter we kick him out.

But when he decompiled code beautifully with tools (ILSpy) he simply find my public key and find out that I encrypt user score and timestamp with that publickey. Then, he will write a Unity or C# programm to simply encrypt his manipulated message with a new timestamp and he will be trusted in my server side app because anything is true.

He will increase his score with posting HTTP requests to server without playing the game. He can simply cheat.

What can I do?

I can't use SSL.
With obfuscating, only crack time will increase.
With giving public key at runtime from server to client, memory checkers or traffic sniffers can simply see public key.

Short answer is: Yes, RSA is useless in this case. If all the game logic happens on client side, you cannot prevent cheating.

If your game is reporting only the final score and nothing else, no encryption can help. The game must know how to submit the score and so the full information will always have to be stored in it. You can only make it harder for the cheater by adding obfuscation and other obstacles.

I would suggest two things:

Send more than just the final score. Send some information about how the game progressed. (What was the score at certain time, when the user lost life, what decisions he took...) Then verify on the server if it is plausible to achieve such score with such game progress.
Ban any user who submits either results that are not valid, or that were submitted before. Make sure your game always produces valid results and is random enough to not likely produce the same result twice. You don't even have to let the cheater know he is banned, just hide his score from any public lists.


How to prevent sharing SSH private keys by email Is it possible to prevent the sharing of SSH private keys over email (Outlook, in particular), both within and outside of the organisation?

TL;DR: use smart cards.

To prevent distributing the key to other persons you need to prevent that the user has read access to the key in the first place. The key is used in SSH for authentication. The authentication process involves cryptographic operations (signing) which need to have read access to the key. In order to protect the users key against reading by the user these cryptographic operations need to be separated from the user in a way that the user can solely initiate the operations and can get the result back. This separation can be done for example by using a user process running with different permissions or even a process which runs on a separate hardware.

A special case of separate hardware are smart cards which are essentially tiny computers running a minimal operating system with some protected storage of cryptographic keys. A user can authenticate against these smart cards by a PIN and then use the card for example to sign some data using the keys stored on the smart card. This is sufficient for authentication which essentially means to prove that the user is the one owning the private key to a specific public key.

Smart cards are designed to be tamper resistant and unclonable which means it should be practically impossible to extract the key or to create another smart card with the same key. This is true even when faced with design bugs like the recently detected one with Infinion chips where errors in the operating system on the card led to the generation of weak private keys (keys created outside the card and only stored on the card were not affected). But note that smart cards only protect against cloning and reading and not fully protect against sharing the key: several users might still share the same smart card and PIN, but they would all need to have physical access to this single card which makes sharing harder.

Several SSH implementations have support for authentication with smart cards. Details can be easily be found by using a search engine, e.g. search for openssh smartcard or similar.


Why is there a redirect to the native app in PKCE? Why even have a redirect or even use the browser? Wouldn't just a normal TLS/HTTPS request/response in the app protect the requests and token?

The one argument I have heard against solely relying on the TLS request is that there could be an app that acts as a proxy and presents it's own TLS cert on the phone. But if that is the case how would this be different from a normal desktop app?

To me it seems like PKCE is protecting against a compromised device. I would assume if native requires PKCE then desktop apps (non-browser) would also require PKCE.

Because it is still extension of OAuth2 Authorization Code Grant.
If the application is trusted with end user password then it can use Resource Owner Password Credentials Grant and as you say only have direct (TLS protected) call to authorization server.

In Authorization Code Grant application is not trusted with end user credentials so it have to force user to interact with authorization server directly (by performing redirect). The  authorization server confirms identity of resource owner and granting access to OAuth client and then have to return the access token to the Client. In Authorization Code Grant it is done by redirect using resource owner user agent, passing the authorization code. The OAuth client then calls authorization server directly and exchanges authorization code for access token.

The two redirects are simply the way how the OAuth2 Authorization Code Grant is defined.
Now if we do not want to trust the application with client credentials then the redirects are hard to avoid - as apart of the payload that is passed there is one more "thing" handed over - the person in front of device.

The application is saying to authorization server "Here is some person, who claims to have resources managed by you, please arrange access to those resources for me."

After some time authorization server "The person you sent me confirmed your access, here is a way to obtain it."

In no place in exchange the shared identity of the person is established.

So if we get rid of first redirect, we would get "Some person claims to have resources managed by you, please arrange access to those resources for me." - clearly request impossible to fulfill.

Now for second redirect the authorization server is the initiator so it would be very hard to call back specific mobile app instance, and even in server to server scenario there is still a problem with matching response with the request.


I'm getting a suspicious link that starts with account.youtube.com, can someone explain what this link does? A lot of bots are sending this link to me on twitter, and obviously it must be something malicious. Can someone explain in a detailed manner that what does this link do and what is the vulnerability here?

This is the link:

It sets up and sends some variables to youtube then logs me out and then sends me to a bitly shortened link:
hxxp://bitly.com/2vK4Fga#1007310965585731584

I unshortened it and it came back with this :

hxxps://www.baidu.com/link?url=rZncHEMCsf6lt8ulV0jdARLcZOqlmQgim4767m7Jgya&wd=&eqid=c152d8470000dc7c000000065b734ee3

The site is a Chinese search engine! When I clicked on this link on my VM, it went to this website: hxxp://www.twitob.com/ which is some sort of gaining twitter follower site.

What is this link doing? I get that its setting some variables like ilo or ils and stuff, but I don't know what are they and why set them to these specific values? What are these variables?

I also found a report on a similar thing to this :

hxxps://www.openbugbounty.org/reports/222365/

but not sure if they are the same vulnerability or not, and that report doesn't explain anything.

One more weird thing is that usually I can easily unshorten the twitter's t.co links, but when I unshorten the t.co link that twitter gave me for these links, it turned into this no matter which website i used :

hxxps://www.google.com/url?sa=D&q=https://bitly.com/2vK4Fga&ust=1535028318764694&usg=AFQjCNF2RgdA4d9RaMK6foDsWn51_W3yYA

But you can clearly see that the actual link is something way different, what is going on?

I'm not going to click on that URL but what it appears to do is:

You can only see the beginning, it looks OK and possibly important to you.
If you don't examine the remainder of the URL it seems safe to click on.
When you click on it you are redirected to Google and logout.
Next you are redirected to a BitLy URL shortener.
The BitLy redirects you to the Baidu search engine.
The Baidu URL has an "Associate ID" attached.
You could be directed to a previously saved search, and the associate gets credited.
IF any of the subsequent sites you see are malicious then since you are logged out of Google (and thus YouTube too) they probably will ask for your name and password, offering to log you back in. The chances of the page asking for your password being a fake Google login webpage are very good.

ALWAYS enable 2-Step Authentication !

Once you give your Google account away they can use it to upvote their favourites and make posts that seem to come from you. Even if you don't give out your password the Associate still gets a credit for your click-through.

So, it may or may not be "malicious" (lead to something "harmful") but it certainly gives someone credit for your click.

This (in its various forms) is explained here: "From Baidu to Google’s Open Redirects", here "How Malware Campaigns Employ Google Redirects and Analytics" or here, on a Google Support webpage: "Detect and get rid of unwanted sneaky mobile redirects".

If you don't have a good reason to click on something don't click on it - it's going to take you off of the page you are on.


With which algorithm I can prevent a brute force on a login? I want make my software more secure. I want prevent it from brute force attack. I know that a strong password is the best but I can not control it.

The algorithm must scale from a very small system with only some users to a very large system.
A captcha is not an option.
No real user should be blocked because there is an attack. I think it is fatal if the admin can not login anymore because there is an attack.

I have think about the follow solutions:

Only a hard coded count of failure per time are possible. After this the login will have a delay. But this will not scale. Also is it it very simple to prevent a valid login with an attack.
Only a count of failures per IP address is possible. After the limit the login will be delayed. But with a bot net this help not. Also can a bot net consume large resources if all the ip addresses and the count of attempts must be stored.
Only a count of failures per user is possible. Then it can be possible to prevent a valid login of the attacked user.

Are there a good algorithm to prevent brute force attack?

Time is your friend.

Think about what happens when you draw money from "ye average banking machine".

User inserts card (read: email/name/whatever),
Machine says "hi, please enter pincode" (read: password/whatever)
User can now enter correct pincode within 3 attempts. If that fails, the card is withdrawn and the user will have to wait for the next day to personally apply for a new card and pincode, explaining to his bank what happened.

Now, in your situation you most probably don't want people to come knocking at your door because they failed to enter the correct code. To avoid this, you'll simply have to strip the "come and apply for a new card" thing and what's left is "wait until tomorrow".

So, if you give a user 3 attempts to verify himself/herself and he/she fails... make her wait for an hour before he/she can try again.

If someone would still try to go for a brute force attack, it would enable him to try ("3 attempts per hour" maximum x "24 hours in a day" maximum = 3 x 24 =) 72 attempts a day.

Depending on what he/she is trying to brute-force, 72 attempts a day (which are 26280 attempts in a 365-day year) is wa-ay too slow.

This way - and as long as "reverse engineering" to find a backdoor isn't an option - your "software" should be safe from brute-forcing anything.

UPDATE

A little update, based on the comments to this answer...

Now, what about people getting locked out because one or more malicious people abuse the user name of a specific member and simply try to make sure such a user can't log in because they simply entered a wrong password 3 times?

Right, sounds like a "Denial Of Service"-alike attack. But that won't stop you from doing it this way, as such attacks can be circumvented easy. All you have to do is to make sure you don't forget about a second layer of security for such cases.

Remember that there are things like "security questions". Someone might be able to know or guess your username, but it'll take a truckload of time to get around a security question when locked... unless you know the answer. The security question could be limited to simply "unlock" the "locked" login area.

Think about how Google and Co. do it:

login with username/email and password,
fails several times gives a lockout,
answering security question correctly lifts lockout.

Use a captcha at (1) and (3) to slow down any brute-forcing attempts and you're all set.

If you explicitly do not want to use a captcha (which makes me wonder why), you will have to implement a "user-ip", "time-of-access" checking implementation and slow down access to the system for a random 1 to 2 seconds. This shouldn't be a problem as this would be a similar implementation as the lockout-procedure, only that you don't lockout but slow-down things at certain points so a brute-force attack takes time. A 1 second slowdown on 1 page will limit brute-forcing to 60 attempts per minute, while you're locking out the brute-forcer after 3 failed attempts. Same goes for the security question: slow it down. The brute-forcer will have to be smart enough to deal with both points and will have to brute-force both of them at the same time... stealing his valuable resources and time to cause havoc.

However you do it. If you do it like this, there's no need for the admin to even leave the coffee machine while all that's going on, and it solves any problems you think you might have discovered relating to "locking out legit users with a DOS-alike attack".

Let's look at the initial example I provided above in (3):

  If that fails, the card is withdrawn and the user will have to wait for the next day to personally apply for a new card and pincode, explaining to his bank what happened.

Well, the "security question" option to enable legit users from lifting the lockout is just like being forced to personally visit and talk to your bank. Just easier.

Also, this "unlocking" procedure can be useful for the admin/sysop as a simple log file showing the number of "attempts" can help the admin to track down attempts of a definitive attack. Any script kid could try to lock out users by entering the wrong password 3 times... but if someone fails answering the security question severaltimes, there's something bad going.

And last but not least: just like an onion, such security layers can even be wrapped into each other (if it makes sense, like in high-security environments).

The simple trick is to make it hard for people to mess with things, while keeping the regular user happy.

I can only repeat: time is your friend... (the rest is simple logic)


One GPG key with multiple user identities for my career? I am trying to work out what is the best approach for managing GPG keys over my career when I change jobs.

My understanding is that there are two ways this could be done:

Have one main/master GPG key with subkeys for signing and encryption.
Have multiple GPG keys.

I am more confident and leaning towards having one GPG key with subkeys and multiple user IDs.

Everytime I start a new job with an organisation, I would create a new User ID with the email address for that company. I would also revoke the previous User ID.

Does this seem ok? Or am I missing something?

I'd first check the organization for their policies. They may not even allow GPG.

I'd use multiple GPG keys, one per organization. An organization may require you to hand over your GPG keys to get to the data encrypted with it. If you change jobs or identities within an organization then you might want to use sub-keys.

And, as usual, always keep your private and company life separate - certainly when it comes to key material.


SSL communication between a C# Server and an Android Client App I'm using a C# server and a C# tcp client example I extracted from the MSDN and I have created a self signed certificate using makecert.exe. I have got this to communicate with one another and it seems to be working fine. Similarly I want to build an android tcp client that will communicate with the C# server. Do I need to create a certificates for the client or anything of that sort? If I do how do I import it in to android?

If you don't intend to perform client authentication via SASL or the like, a certificate is needed only for the server. Just embed the public key you generated in the app and use it for certificate pinning.

If get your certificate signed by a CA in Android trust store, you can use Android TLS utilities without any extra step, since the verification will be handled automatically for you. Anyway, pinning appears to be the safest option for an app distributed through the Play store, which will likely communicate with few, selected and known hosts. In fact, it makes MITM much more difficult: having a certificate valid for your domain is no more enough, they need to get your key.


Building software safely for malware-free distribution I wrote a program. I want to publish a compiled executable for downloading by the public.

How can I compile and distribute it without contact with my (presumably insecure and infected) operating system? How do software vendors ensure that their software packages are malware-free?

The absence of relevant information on the web is pretty disturbing. It’s as if nobody in the world except me cared about safe and responsible distribution of software. Why are there no clean compilation services on the web? I’m not going to buy a separate computer only to compile and upload one little application.

It's important to think about what kind of threat you are trying to protect against. Your questions could be taken to imply two different threat levels:

A general virus that just injects itself into any executables it happends to stumble over.
Malware designed specifically to infect your build process and embed itself in freashly compiled executables.

To protect yourself against the first category, schroeder has a good suggestion - just check the filesize. Your compiler probably already outputs that. Or have your compiler output a hash and use that, or sign the file in the build flow.

If you are up against a theat of the second type, the above is no good. If the attacker is sofisticated enought, nothing can help you at that point. As soon as your system is compromised, you are owned.

In the end, it comes down to how advanced threats you want to protect yourself against. Using a separate machine could help, and so could a VM (or a "trusted third party", even though I am not sure I would trust one). But a sufficiently advanced attacker could overcome those obstacles as well.


Security risk with using internal IP on public DNS A web server inside the office network which is accessed by staff internally and the internal DNS resolves web.company.com to the server's LAN IP.

Publicly, company.com nameservers belong to their party hosting company where the main company website is hosted and it does not have web.company.com record.

Now if the web.company.com should also be accessible from outside, it is okay to expose our LAN IP in the A record so that only staff with VPN can access; or should web.company.com resolve to the office network external address and use firewall to route to the LAN IP?

There is another risk using private / LAN IP addresses for public DNS records.

Suppose you have a laptop user in your LAN, who uses web.company.com (which resolves for example to 192.168.178.10).

If this user connects his laptop to another network (wifi!), and tries to use web.company.com, it will resolve to 192.168.178.1 using the public DNS entry. It may be possible that the IP address 192.168.178.10 corresponds to a machine on this foreign network. The laptop will then send information to this machine, which may even include plain text credentials, cookies or other data.

It may even be possible to setup a sort of honeypot using some detailed knowledge of the LAN.


How great is the risk in publicly sharing part of a private key? If two people want to check they have the same (say 256 bit) private key, how great is the risk in sharing the first say 8 chars over a potentially public channel?

Can an attacker recover any more information than just those characters, and/or how much faster could an attacker crack the key given those 8 chars?

Providing any part of the private key makes it less secure, at least marginally, simply because it provides an attacker with a smaller potential key space to explore.

I fail to understand what you want to achieve.  The only thing two people need to do to check if they hold the same information is exchange a hash.

If you are designing a protocol and are worried about replay attacks, you can protect against it by performing a challenge response using a HMAC.

Edit:

As suggested the comments and explained in D.W.'s insightful answer, I need to emphasis that the impact on the security of your private key will depends a LOT of exactly what algorithm you are using. In the worse case scenario, revealing only a small part of the private key will completely break the security of that key.


Access to foreign memory address Modern operating systems like Windows 10 isolate memory addresses for processes so how is it possible that Cheat Engine can get these addressed and change their values?

At this forum it has already been asked: "how to get pointers to foreign address " - and the answer is: it's not possible, because OS has isolated addresses for its programs.

char buffer[4096];
SIZE_T bytesRead;
HANDLE proc = OpenProcess(PROCESS_VM_READ, FALSE, <PID>);
ReadProcessMemory(proc, <address_in_other_program>, buffer, 4096, &bytesRead);

I'm leaving out a lot of stuff here - for example, error checking to determine whether you are actually able to open the target process with the VM_READ permission - but it really is that simple. Virtual memory doesn't mean one process cannot access another's memory, it just means that each process' address space is (by default) their own, and if you want to access somebody else's, you have to ask for it.

Windows, by default, allows all processes running as the same user and with the same integrity level to get read access to each others' memory (higher-integrity processes can also read lower-integrity ones, though not vice versa). A process can change its own ACL, or that of any other ACL running with the same or strictly lesser privileges; this can be used to grant a process running under a different user access, if for some reason you wanted to do that. Administrators (and anybody else with the SeDebugPrivilege) can also access the memory of any other process (except for a few that have special "don't debug me!" flags); this is why a debugger launched as Admin can debug (almost) anything.

Note that this code sample also elides two important steps: getting the other process' PID, and getting the address you want to read from. The PID is pretty easy (they're not especially secret, and processes running as the same user can be easily enumerated by anybody), but getting the base address is trickier. It can be done, using debug symbols or just XORing an expected base address with the OS' current ASLR mask (which is the same for all processes running on the machine, though it changes with each reboot), but you do have to put some effort into it. If you request an address that isn't mapped in the target process, the ReadProcessMemory call will just fail.

As a side note, the APIs are Windows-specific but the concept isn't. Every OS that supports debugging has a way to read the memory of another process. This very much includes Linux, MacOS, etc. Sometimes the default permissions on a inter-process memory access are different, but it's always possible for a sufficiently-privileged process.


Using Google Cloud Platform to store credit card data I have made an iPhone app for users to book hotel rooms. A third party provides the service for booking the hotel rooms and charging the credit cards. At the moment, my app makes no attempt to save credit card information. It simply sends the credit card info to the third party provider when the user wishes to book a room. But I would like to save the credit card info so that the user doesn't have to repeatedly type it in.

Google Cloud Platform recently achieved PCI-DSS compliance. So I'm wondering if it is prudent to store my users' credit card data there? Would I need to effect additional measures to secure the data? Also, is it prudent to authenticate the iPhone app user with OAuth rather than Basic Authentication?

Note that it's not because you are using a platform which has been cleared for being PCI-DSS compliant in a single or several instances that you are also automatically PCI compliant. You will also need to go through all checks like regular ASV scanning, etc...

Note that there are certain pieces of information which you are simply not allowed to store if you want to be PCI-DSS compliant.

PCI is all about discouraging the storage of cardholder information, so if you are just doing it for the sake of convenience, I'm not sure it's worth the trouble.


Effective wireless scanning to meet PCI DSS 11.1? PCI-DSS section 11.2 requires the business to "Test for the presence of wireless
access points and detect unauthorized wireless access points".  However, this is more easily said than done.  Simply scanning to detect wireless access points (as many suggested here) pulls up over 120 APs, both on adjoining floors of our building and in surrounding buildings - in one case, a department store half a dozen floors down and over a long block away!

The biggest problem with walkarounds is that signal strength is a poor tool for location, and as @AviD pointed out in the other thread, a wireless AP could easily be so small or hidden that detecting it on walkaround is highly unlikely.  Are there cheap, readily available antennas to provide good directional cues, a poor man's triangulation?

I know that Wireless IDS solutions like Aruba Networks can deploy sensors to perform triangulation.  I have seen very few such solutions actually deployed, and when deployed they require sensitive care and tuning.  I'm not eager to see what the false positive rate would look like given the number of APs on floors above and below us.  But maybe someone has experience with a product that they felt was worth it?

So, I guess my question is - what are people doing to meet 11.1 that provides some security benefit, as opposed to policy compliance?

(I also find it hard to bite into this problem because it's so pointless.  Most cell phones could provide a tethered connection between the corporate network and the outside world and be invisible to wireless scanning.  And if it was scanned, it would look just like all the worker bees using their phones, and it can't be jammed legally.  But that's not in PCI-DSS, so don't worry about it!)

So, I guess my question is - what are people doing to meet 11.1 that provides some security benefit, as opposed to policy compliance?

Check out section 11.1b as that's the integral part of the test:

  11.1.b Verify that the methodology is adequate to detect and
  identify any unauthorized wireless access points, including at least
  the following:

  WLAN cards inserted into system components
  Portable wireless devices connected to system components
  (for example, by USB, etc.)
  Wireless devices attached to a network port or network device

None of this relates to finding radio signals. What you should be focusing on is having a regular inventory of computer systems with effective detection of changes in installed hardware. Since almost anything in your PCI-DSS scope is likely to be a hardwired machine that the system/network administrators have administrative access to (and the users don't), this task shouldn't be too rough. If for some reason your machines do have wireless devices that need to be enabled, control and monitor their configuration to stay on your network.

Prevent hardware from being activated without administrative privileges
Inventory hardware
Prevent users from having rights to configure hardware that is there
Log hardware configuration changes (installation, driver parameters)

The second part is port control. Ideally, use 802.1X-2010. Log any hardware addresses not recognized and any transfer of an address between different switch ports.


Tracing Wireless Card Let's say that hypothetically someone had broken into a WiFi connection. We can't find any evidence of whom it is via sniffing the traffic or anything of the sort.

Is there any way to triangulate where the connection is coming from and find the general location of the wireless signal?

It is theoretically feasible, although normally used in the other direction by portable devices like the iPad: the device works out its own position with regards to WiFi access points which are in range. In your case, you would have to triangulate for the signals of all systems which emit packets on your WiFi, since you do not know which one is the culprit.

I don't know of any off-the-shelf software or tool which would work in your context (localization of a WiFi user, not of an access point) -- but that does not mean that such tools do not exist.

Of course, nothing can be done for a passive only attacker. To find someone based on the WiFi signal that person emits, well, a WiFi signal has to be emitted by that person.


Information on the specifics of how behavioral antiviruses work? I'm looking into security software and it seems like the Next Big Thing is behavioral antivirus. I'd like to try possibly making my own rinky-dink "next-gen behavioral AV" so I can gain a better understanding of its inner workings and so I can see just how close I can come to established products in terms of false negative and false positive rates. While I understand I'll probably never achieve the results the big players can due to a lack of access to the kind of data and workforce and expertise that they have, I'd like to at least see how close I can get.

I understand the gist of how behavioral AV works (AV monitors the operating system's API and installs a filter driver to monitor filesystem changes), but I'm interested in finding out what exactly are the types of things that these antiviruses look for. There are a few things that come to mind -- process injection, connections to servers with poor or nonexistent reputations, software setting itself up to run at startup, software that interacts with a bunch of files in the C:/System directory, etc -- but I'd like to see if anyone has any other ideas on what I should try looking for.

So far, I've found this:

https://pdfs.semanticscholar.org/8d9f/ed95412be6472c06f844029583862e4d4098.pdf

But it only looks into a few actions. Does anyone have any info on what else I should include in my kludgy, not-so-enterprise AV?

I will suggest you to look to https://www.clamav.net/, is an open source implementation, so you can check and see how works an AV in general. Of course, the commercial AVs will tell you how good they are, but basically all AVs found a similar approach, rules, syscall interception, behavior of open files and so on.


Is it possible to guess the length of a password by sniffing TLS packets? In this answer, the author states that it is possible to tell the length of your password, by sniffing your TLS packets. Is this true, and how would this be done in practice?

All ciphers are not made equal regarding this possibility. It greatly depends whether we are dealing with a stream cipher or a block cipher.

Stream ciphers (like RC4) take a flow of n plain-text characters as input and produce a flow of n encrypted characters as output.

With such ciphers, adding a single character to the password (which acts as the plaintext data here) will make the cipher text on character longer, thus allowing a really good guess on actual password length.

Block ciphers, on the opposite, will only operate on blocks of fixed size (128 bits for AES for instance, which means 16 bytes), the last block being completed with padding.

In such case, adding a single character to the password will never make the cipher text one character longer. If it happens that the password length is long enough to fill the last block (it may require from 1 to 16 characters) then a supplementary block of cipher text will be produced, but with no mean to know how much of this new block is actually used, and therefore without any precise information about the exact password length (a 16 characters approximation does not seems reliable as long as passwords are concerned...).

Fortunately, block ciphers are the most used ciphers for common TLS applications where the data is already handled by blocks of finite length. An HTTPS request for instance has a clear begin and end and do not suffer that much from the up-to 16 bytes padding overhead caused by block ciphers. Therefore, most web servers and browsers nowadays prefer to use block ciphers than stream ones (if stream ciphers, RC4 mainly, are not disabled altogether).

Stream ciphers, having more limited cryptography properties, see their usage being restricted to very specific use-cases, mainly situations where the data appears more as a flow than well defined blocks. Network level cryptography (WPA2, IPsec for instance) are good example, but this may also affect application-level cryptography as well (VoIP application for instance can use SRTP which relies by default on AES used in stream mode). In such cases it would neither be optimal to send a whole block to carry a single effective byte nor to try to hold-on the communication in the hope that more data will come to fill the cryptographic block. A stream cipher will just follow the communication flow as it goes on.

Under some conditions, a block cipher can be used in stream mode (when used in CTR mode for instance). Most applications show a list of the enabled cipher suites in their order of preference. This cipher suites indicates the encryption algorithm used, accompanied by the operation mode whenever applicable. Here are a few cipher suite examples to make things clearer:

ECDHE-ECDSA-AES128-GCM-SHA256: This uses AES in Galois/Counter Mode (GCM), this remains a pure block cipher,
ECDHE-ECDSA-AES256-SHA: This one does not clearly show an operation mode, it is an OpenSSL notation corresponding to  the standard notation TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA assuming Cipher Block Chaining (CBC) by default, this is also a pure block cipher,
TLS_RSA_WITH_AES_128_CCM: This is a standard cipher suite showing AES used in Counter with CBC-MAC  (CCM) mode, derived from CTR it is a way to use a block cipher as a stream one,
ECDH-RSA-RC4-SHA: This one does not use AES, it uses RC4 in place which is by definition a stream cipher (while block cipher can be used as stream ones, the opposite is not true: you cannot turn a stream cipher into a block one, so there is operation mode indication for stream ciphers).

This should allow to check the kind of encryption used by your software:

When using only stream cipher, the length of the encrypted message can be easily known (so if the password length is the only variable of an otherwise known message it becomes easy to deduce the actual password length, unless the password has been hashed before being sent as Mike Ounsworth rightly outlines in his answer),
Using only block cipher will reduce this to some approximation, possibly excluding any practical use for such a small information as a password,
If you cumulate the two (for instance accessing an HTTPS (assuming block cipher) website over a WPA (stream cipher) protected Wifi network) you keep the advantage of the block cipher making the guessing a large approximation.


Restricting user sign-in on Chrome for Business I'm currently evaluating the configuration of Chrome for Business in a corporate environment. There is a setting which prevents users from signing into Chrome with their personal accounts. My gut feeling is that this should be disabled but I am struggling to identify the risk of allowing this. Whilst this question refers to Chrome the discussion really is transferable across browsers.

As far as I am aware the user would be able to perform the following if we were to allow them to sign-in:

Sync bookmarks across multiple devices
Sync saved passwords across multiple devices

This is the biggest one for me. If corporate credentials are saved and stored locally on an uncontrolled device the chances of those credentials becoming compromised is increased. However, I'm currently unsure how Chrome stores passwords (although I have read multiple articles suggesting it is not secure!) i.e. are all saved passwords stored locally devices where the user is signed into Chrome irrespective if the site that the saved credentials is associated with has been accessed on a particular device.

Sync enabled extensions across multiple devices

This is mitigated by the fact we will block the installation of non-approved extensions using a whitelist approach.

I would be interested to know your thoughts on this or what you may have implemented within your orgs.

My org agreed chrome extensions and syncing were high risk. The main concern was extensions due to the fact they can control all web traffic in the browser thus need to be patched and whitelisted to run. We have syncing accounts disabled.


Change settings to scan a printer with openvas I have Openvas 5.1.1 (gui: Greenbone Security Assistant Version 7.0.2).

It misidentifies my linux server as a printer. Scan result includes

Solution

If you want to scan the remote host, uncheck the 'Exclude printers from scan' option within the 'Global variable settings' and re-scan it.

Using the web UI, I can see the settings:

but I can't find out how to change it. The configuration files doesn't include any such option:

root@kali:~# find / -name openvas*conf
/etc/openvas/openvasmd_log.conf
/etc/openvas/openvassd.conf
root@kali:~#
root@kali:~# cat /etc/openvas/openvassd.conf
kb_location=/var/run/redis/redis.sock

Actually the documentation doesn't include that option for the openvassd.conf file, at all: http://www.openvas.org/compendium/advanced-configuration-server.html

Any ideas?

The problem seems to me that you're trying to edit a pre-made and static configuration.
You're correct that you're not supposed to change it in the .conf file.
What I'd recommend doing is:

1 Cloning the scan you want (In this case "Full and Very Deep Ultimate") by clicking the sheep icon next to it in the "Scan Configs" page.

2 Going back to the "Scan Configs" page, from the page it will take you too and editing it by clicking the wrench button.

3 Scroll to the bottom and click on the folder icon next to "Network Vulnerability Test Preferences".

4 Scroll down until you reach "Global variable settings Exclude printers from scan", and click on the wrench icon to edit.

5 Look for "Exclude printers from scan", and disable it.

Hope this helps. :)


Client — CertificateVerify during handshake I am trying to understand how the client is authenticated to the server during mutual tls
So during the handshake, the client sends this message
Client — CertificateVerify
This message is used by the client to prove the server that it possesses the private key corresponding to its public key certificate. The message holds hashed information (hash of all the messages exchanged so far during the handshake process) which is digitally signed by the client. It is required if the server issued a CertificateRequest to the client, so that client has sent a certificate in response which needs to be verified in server-side.
My confusion is here "server that it possesses the private key corresponding to its public key certificate."
The certificate is issued from a certificate authority. So the ca is using its private key to sign the certificate. How the client has the private key of the certificate?

How the client has the private key of the certificate?

The central concept of certificate based authentication that the owner the certificate and only the owner has access to the private key. The proof of ownership of the certificate as then bound to signing something with the private key: everybody knowing the certificate (and the included public key) can validate the signature but only the owner of the private key can create it.

The certificate is issued from a certificate authority.

The certificate authority issues a certificate based on the certificate request from the client. This key pair consisting of private and public key is (ideally) created at the client side and the private key remains at the client. Only the public key is included in the certificate request (which is also signed by the private key).


Controlling variables used by an application One thing that I have seen commonly used by game cheating engines it to control variables that the game is using.  The idea is to edit the variables used by the game to say, give ones self unlimited ammunition.  One example of this type of tool is tsearch.

I have no idea how to replicate this attack on my own, nor what it is called.  I would like to learn about how it works, and how to mitigate it.

This is generally done by reverse engineering the game to find out where in running memory these variables live within the program.  There are two ways to modify those variables.

Program Patch
An attacker can patch the executable or DLL itself if there is no integrity protections on it.  Basically the actual bytes of the program are modified to be/do something different.  As long as the program does not check to ensure no data has been changed this is a very viable option.

This can be mitigated by performing some type of checksum over the entire executable.  A cryptographicly strong hash would do.  You wouldn't want to use something like CRC32 because with enough changes to the binary an attacker could make the checksums match.

You could also sign your program.  Before executing the program it verifies the signature of the program.  If this fails then the program doesn't execute.

In Memory Patch
This technique is generally a bit more annoying.  While the program is running an attacker either injects code into it, or finds where it's living in RAM and patches the program there.  Code injection is much harder to do, but the memory patching is almost the same as regular patching.  The attacker has to perform this every time that the program is run though since RAM will get cleared.  This is much harder to mitigate since you're program is already running.

There are techniques you can use to prevent reverse engineering in general.  During portions of the program you want to protect you can detect the presence of a debugger.  Reverse engineers will almost certainly need to use a debugger to figure out exactly what pirtions of memory effect what the program does during execution. Manipulating memory in a debugger to see how the program is affected.

You can also use code obfuscation to make the disassembly or decompiling of your code much harder.

Here is a fun link in that general direction.


How long would it take to brute force an 11 character single-case alphanumeric password? My previous home wifi router's WPA2 password was permanently fixed to FZ4HBCKHGC8.

How long would it take to crack via brute force?

Or more pragmatically:

How long would it take to exhaust all possible iterations of this 36 character set {A..Z}+{0..9}?

The speed of WPA2, and the speed of modern GPUs, are essential to this answer.

A reasonable prosumer-sized (~US$5K) GPU cracking rig with 6 GTX 1080s can try around 2 million hashes per second - but there are 36^11 candidates to try!

For demo purposes, this is an actual attack, using the example WPA2 hash from the hashcat website:

$ hashcat -a 3 -m 2500 -2 ?u?d hashcat-wpa2.hccapx ?2?2?2?2?2?2?2?2?2?2?2
hashcat (v4.1.0) starting...

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #2: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #3: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #4: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #5: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #6: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU

[...]

Session..........: hashcat
Status...........: Running
Hash.Type........: WPA/WPA2
Hash.Target......: 8381533406003807685881523 (AP:ae:f5:0f:22:80:1c STA:98:7b:dc:f9:f9:50)
Time.Started.....: Tue Apr 24 06:51:26 2018 (54 secs)
Time.Estimated...: Sun Oct 11 02:45:49 4105 (2087 years, 168 days)
Guess.Mask.......: ?2?2?2?2?2?2?2?2?2?2?2 [11]
Guess.Charset....: -1 Undefined, -2 ?u?d, -3 Undefined, -4 Undefined
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:   336.2 kH/s (6.89ms)
Speed.Dev.#2.....:   330.8 kH/s (7.03ms)
Speed.Dev.#3.....:   332.0 kH/s (6.96ms)
Speed.Dev.#4.....:   331.1 kH/s (6.97ms)
Speed.Dev.#5.....:   334.2 kH/s (6.90ms)
Speed.Dev.#6.....:   333.8 kH/s (6.90ms)
Speed.Dev.#*.....:  1998.0 kH/s
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 108544000/131621703842267136 (0.00%)
Rejected.........: 0/108544000 (0.00%)
Restore.Point....: 2539520/3656158440062976 (0.00%)
Candidates.#1....: 82TCFESS123 -> 8MXVZONANDA
Candidates.#2....: 9JGXQW12345 -> 9O3QWESS123
Candidates.#3....: 9BBZPANANDA -> 93M1YONANDA
Candidates.#4....: 96RCZONANDA -> 9WMXQW12345
Candidates.#5....: 5S3O3123456 -> 59QC6678999
Candidates.#6....: 40QC6678999 -> 4CUZPANANDA

But don't feel too reassured by the "2087 years" estimate. Fixed passwords often do not require brute force to be cracked. Many permanently fixed WPA2 passphrases are algorithmically generated, and many of those algorithms are either known, or discoverable by reverse-engineering the device's firmware.


If someone asks to borrow your phone to make a call, what could they do? A stranger walks up to you on the street. They say they lost their phone and need to make a phone call (has happened to me twice, and maybe to you). What's the worst a phone call could do?

Let's assume they don't run, don't plug any devices into the phone, they just dial a number and do whatever, and hang up.

A few scams I've seen making the rounds:

Use it to dial a premium rate number owned by the group. In the UK, 09xx numbers can cost up to £1.50 per minute, and most 09xx providers charge around 33%, so a five minute call syphons £5 into the group's hands. If you're a good social engineer, you might only have a 10 minute gap between calls as you wander around a busy high-street, so that's £15 an hour (tax free!) - almost triple minimum wage.
Use it to send premium rate texts. The regulations on there are tighter, but if you can get a premium rate SMS number set up, you can charge up to £10 per text. A scammer would typically see between £5 and £7 of that, after the provider takes a cut. It's also possible to set up a recurring cost, where the provider sends you messages every day and charges you up to £2.50 for each one. By law the service provider must automatically cancel it if they send a text sayin STOP, but every extra message you send gains you money.
Set up an app in the app store, then buy it on peoples' phones. This can be very expensive for the victim, since apps can be priced very high - some up to £80. In-app purchases also work. This is precisely why you should be prompted for your password on every app purchase and in-app purchase, but not all phones do so!
Install a malicious app, such as the mobile Zeus trojan. This can then be used to steal banking credentials and email accounts. This seems to be gaining popularity on Android phones.


Secure mount options + partitioning on Ubuntu What is the best solution for mount options/partitioning when having e.g.: an Ubuntu minimal install (11.04) for Desktop use? e.g.: put /tmp on different partition to give it mount options like: nodev,nosuid,noexec - it could increase security. I just want to gather tips, how to do this

noatime could give more performance! so it's a must have for every mount point.

Thank you!

p.s.: also, what size would I give to the partitions? - everyday desktop use PC

The National Security Agency actually publish operating system configuration recommendations. They specifically publish information for hardening Red Hat 5 but this could be adapted to any Linux distribution.

This setup is simply too detailed to quote in its entirity, but the hardening guide gives you a set of services which you can safely remove setuid permissions from. Note that modern linux distributions use capabilities and you should also understand and be able to review these (Red Hat 5 is somewhat old). Specifically and of interest they recommend separate partitions for /var/log and /var/audit. I assume this is because these partitions are somehow securely mirrored such that one cannot remove information from them once it has been written.

I would be careful with your nosuid and noexec options; you might disable legitimate execution and nosuid may not apply to capabilities. I personally think the utmost best defence for any kind of application-level security is mandatory access control, but this is not fully prevalent and available / compatible with all software yet, since many software authors do not take this into account (the old NT assume I'm an admin problem).


Authentication without saving password Are there any security problems with following authentication protocol?

when user creates hers account, she provides her username and password. I store the username and blowfishEncrypt(toEncrypt = username, key = password) (lets call it token)

and then when user wants to login, i simply create token again (she needs to provide username and password) and compare the two.

The idea is to not have passwords stored in the database. But i guess i'm relying on the fact that if i know original and encrypted value, i'm not able to obtain the password.

Is there something obviously wrong with this approach?

The problem is that the encryption operation is rather efficient and thus passwords can be efficiently bruteforced. Its better to use existing standards which do exactly what you're describing but in a safe (and often already implemented) way, like in http://en.wikipedia.org/wiki/PBKDF2


PoisonTap + SSL Stripping a good combo? One of the remediation suggestions to go with PoisonTap is enforce the use of SSL on applications to dissuade sniffing/modification of data. What if the attacker also employed SSL stripping? From Samy Kamkar's post on PoisonTap -

  ...allows attacker to remotely force the user to make HTTP requests and proxy back responses (GET & POSTs) with the user’s cookies on any backdoored domain

So the attacker forces SSL communication to flow through their proxy and carries out SSL stripping. Agreed that a careful user might notice the difference in URL and go no further, but chances are the average user may not notice that.

My question in a nutshell - is there a mitigating factor to counter this scenario?

PoisonTap works on the same level as ARP or DHCP spoofing or a rogue access point. This means that the same restrictions apply (i.e. HTTPS can not be decrypted and thus the plain text not sniffed or modified) and the same possibilities (HTTP can be sniffed and modified).

This also means that enforcing the use of HTTP instead of HTTPS using SSL stripping will work with PoisonTap the same as it does with the other attack vectors, i.e. it works as long the connection does not start as HTTPS but there is an initial HTTP request which can be hijacked and modified to remove any HTTPS and HSTS headers from the response. But there is actually nothing specific to PoisonTap here compared to the other usages of SSL stripping.


Could the FBI dump the drive contents of an iOS device, and then somehow run Virtual CPU's with different keys? This seems like the most logical answer that would prevent wiping the data.

Dump Contents of Drive.
SetUp Virtual CPU with different keys.
Use existing firmware and hardware for ios x

Profit

Is this not possible?

PS. Although not part of the original question. I don't understand why they can't just use microscopy?

If the filesystem is encrypted, then no, they couldn't, as far as I understand the arrangement on newer iPhones (models with fingerprint readers).

Or rather, they could copy the contents of the phone's storage and mount it on a computer of their choosing, but they wouldn't be able to read it because it is encrypted with a 256-bit AES key which is (presumed to be) beyond their ability to brute-force.

The original phone holds a copy of that key, of course, but it is stored in the "Trusted Enclave", a separate system-on-a-chip which keeps the key in its internal EEPROM and won't reveal it until it sees a correct user passcode.  The Trusted Enclave itself implements a timeout after repeated wrong entries, so even transplanting it into a custom-made circuit wouldn't help you to brute-force the (weak, four-digit) passcode.

Whether the Trusted Enclave chip could be breached physically, I don't know, and I doubt that could be answered without public-domain information.  It would be a formidable task, though, even if the chip's casing isn't tamper-proofed in any way.  The components you'd need to connect to are made from a small number of molecules, and even if you had the time and money and equipment to do it there'd be a strong risk of damaging the chip and losing any possibility of recovering the data.

If this is related to the San Bernardino case currently in the news, the situation is a little different because that relates to an iPhone 5C, which does not have the Trusted Enclave.  Presumably you could open the phone and read the whole system image from the flash memory into a virtual machine (which ignores any code-signing protection), and then hack the OS to allow the passcode to be brute-forced.  That's still a pretty big job, but it's not unthinkable that the FBI could do it in exceptional cases.  It would be much easier for Apple, but there is also a political dimension to (a) the FBI requesting that and (b) Apple resisting.


Should I log users in if they enter valid login info in registration form? Recently, we've had users complain that they forget that they have an account, try registering, and get error message that the user with such email already exists. There is a proposal to just log them in such cases. So, if the user inputs valid login info into registration form, they are just logged in instead. Obviously, if the password isn't correct, user will not be logged in.
What are the security implications of such approach? If the attacker already knows login and password, they will be able to log in normally anyway. Most sites don't have this behaviour, and my gut reaction is that this is not a good practice, but I can't articulate any specific objections.

Unless other authentication methods are involved (for example 2FA, etc.), if a correct email and the corresponding password are sufficient and necessary to log you in, then I see no security issues. The reason is simple: the authentication and authorization process doesn't change. However, if for example 2FA has been enabled for an account and the second factor is necessary in order to log in, if you allow users to login from a registration form that only accepts email and password, you will introduce a weakness (because it will be possible to bypass the second factor from the registration form), unless of course you also check the second factor right after the registration of an existing user with 2FA enabled. This might make your app more complicate.
That said, I believe what you proposed is generally a bad choice for UX (User Experience) anyway. What happens if there are other fields in the registration form, and the new data is different from what is already saved in the account? Think of a phone number, for example. Are you going to update it in the profile automatically without a warning? Are you updating it with a notice? Or will you discard it? This problem will introduce steps and choices that will make everything more complicated, both for you (and your code) and for the final user. Also you will have to distinguish between users that already have an account but entered a wrong password, and users that already have an account and entered the correct original password. You can't just log them in without a notice, because their experience is going to be different (a new account will not behave in the same way as an established account, and will have different data and settings). Unless the users understand what you are doing, some of them might even wonder if there's a bug in your software and think: "Did it just let me log in because I used the right password, or would anybody be able to log in to my account with this registration process?".
So, as I said, I believe that this is going to complicate things both for you (and your code) and for the user. If you have huge registration forms and you want to avoid that users waste a lot of time when registering if they already have an account, then make sure you check their email address right away, in the first steps of the registration process, or in the background via AJAX, so the user will discover they already have an account before they start filling in all the fields.


Why is ICMP timestamping disabled on OS X? It would seem like ICMP timestamping is quite a useful feature for troubleshooting networks with asymmetric paths.

Replies to icmp(4) timestamp requests are generated by the kernel:

On OpenBSD, the feature is controlled by sysctl net.inet.icmp.tstamprepl, which is enabled by default.
FreeBSD even has no option to disable only the timestamp feature of ICMP (see case ICMP_TSTAMP in icmp_input())

On OS X, the respective setting is net.inet.icmp.timestamp, which is specifically disabled by default.  Why?

The ICMP timestamp response contains the remote host's date and time. This information could theoretically be used against some systems to exploit weak time-based random number generators in other services


Is OpenSSL AES GCM standardized? I have been reading about the perils of not going the pages of my own encrypt-then-mac implementation, because there so many things can go awry. So decided to use EVP_aes_256_gcm.

But some questions came to my mind,
Is EVP_aes_256_gcm following some standard that would make it interoperable between different crypt toolkits ?

That is, if I use another crypt SDK with "aes256gcm" and use same key and IV, will I get same results ?

Can my encrypted text using openssl aes gcm be decrypted in other environments c#, java ?

I dont even know the details of how openssl does aes gcm, so if in another development environment the 'aec gcm' was missing I would not even know how to implement my own that matches openssl one.

There is a standard for GCM. Hopefully, OpenSSL follows the standard correctly. Since:

there is a standard for using GCM in SSL/TLS;
OpenSSL supports GCM in TLS since version 1.0.1 (see the ChangeLog);
GnuTLS also supports GCM in TLS;
OpenSSL and GnuTLS appear to be able to talk to each other;

then chances are that both OpenSSL and GnuTLS implemented GCM properly, i.e. conform to the standard.

If unsure, check with the test vectors published by NIST (search "GCM" in that page).


Some vulnerable projects in C or C++ for a lecture? I'm looking for some real projects which have stack overflow vulnerabilities. The important thing is, I am going to teach finding the vulnerabilities and the way of fixing them by these examples. So, the vulnerabilities should be simple to find and simple to patch. Do you know any source code for this?

Open Security Training has some great resources to teach developers about secure code practices including a virtual machine with compilers and vulnerable code samples

Also look at NIST's SAMATE TEST Suite for C and C++ vulnerable code, For e.g. C test suite contains good examples of Format String, Buffer overflow vulnerabilities in C.

You can find vulnerable versions of open source software like Wireshark on SAMATE as well. You might also want to look at exploit-db.com once your students are comfortable with simple vulnerabilities.

Finding security issues in Wireshark, VLC or any media libraries can be a great exercise for students and also improves security of open source projects.


What manufacturers create OATH HOTP cards now that InCard Technologies is no longer in business? I purchased the following OAUTH HOTP card from Verisign.  I'm intrigued by the security possibilities that this form factor provides and what customizations to the circuit logic are possible.

On the reverse of the card is a copyright of 2007, and a co-branding from "InCard Technologies".  I used Google, LinkedIn, and a variety of other sites to locate the manufacturer.

Given that the most recent stock price is zero, emails are rejected, and the website is offline I can only assume that they are out of business.

Question

What other manufacturers (if any) allow for HOTP or other custom circuit logic to be embedded into the card?

I don't explicitly know the answer to your sourcing problem, but I do know a bit about the cards and their internals. That being said, I'm pretty sure GIS manufactures them.

There are two classes of card internals:

Discrete small pitch surface-mount components embedded inside the plastic.
Custom chip-on-board encased in epoxy, again embedded in the plastic.

The first one can be seen by cutting the card's layers apart with a very sharp scalpel. It's tedious work, but you can often find all sorts of interesting internals. You can also "image" the internal layout with a high resolution baggage scanner or similar equipment.

The second one is more difficult to work with. You can cut the card up, but you'll just find a black blob. You can use corrosives to dissolve the epoxy and reverse engineer it, but that's annoying and often damages the internal die.

If you want to build your own, it's actually not hard. Just buy a bunch of tiny SMD components that do the job (they're often significantly thinner than a card), wire them together using thin patch wire, use a dremel to drill down into the guts of an existing card, solder your wires to the card contacts, then use epoxy to fill it. You can use fine sandpaper to flatten it down nicely. It doesn't look very professional, but the card works.


How is it possible that a  tag was injected, but not executed? I've recently tested a web application and found out that it was vulnerable to Stored XSS attacks. However, a peculiar behavior left me a bit puzzled. When I inserted John <script>alert(1)</script>Doe, my browser showed that the script tag was indeed injected correctly, but the alert did not pop up.
When inserting John <img src=x onerror=alert(1)>Doe, the alert popped up immediately upon load.
What I ruled out so far

Escaping: I thought perhaps the <script> tags were escaped, and yet for some reason not rendered, but my proxy confirmed that the tags were not escaped.
CSP: It occurred to me that a CSP might be in place, but there was none, and also if it had blocked an injected <script> tag, it would also have blocked an injected <img> tag as well.

A few possible explanations:

CSP: Check headers and meta tags. I agree that the onerror executing makes it unlikely, but I am not sure it would be impossible.

Browser XSS filter: Only an issue if you are doing reflected XSS. Turn them off, or use a browser without an XSS filter.

Malformed HTML: Are you sure the script tag is actually being interpreted as a tag? Encoding issues, escaping or malformed HTML somewhere else in the document can stop this from happening. To check if this is the case, use the developer tool to see if there actually is a script tag in the DOM.

innerHTML: How does the script tag end up in your DOM? Is it done on the client using JavaScript and the innerHTML, insertAdjacentHTML or similar? If so, the following note on MDN explains the problem:

HTML5 specifies that a <script> tag inserted with innerHTML should not execute.

Note that there may be a framework between you and setting the innerHTML. To execute the script, you have to create the script element via createElement and append it to the DOM explicitly.


Decrypting gpg2-symmetrically-encrypted files using non-gpg2 tools If I encrypt a file using gpg2 and specifying AES256 as my encryption algorithm, can I decrypt it with tools other than gpg2?

More generally, does the fact that one tool used AES256 for encrypting a file imply that any other tool that also supports AES256 can decrypt the file?

AES256 is a standard algorithm. Any tool that correctly implements a standard is interchangeable.

That said, a given tool may append decorators before and after that might need to be stripped out or altered for another tool, but the core encryption is the same.


What are the security implications of enabling UPnP in my home router? I found port forwarding entries in home router that I haven't manually configured. Is that because of UPnP?

Are applications simply able to tell the router to forward ports on their own? Are there any security implications with enabling UPnP?

Many modern home routers usually come with a feature called Universal Plug and Play (UPnP) to allow NAT traversal using the IGD Protocol. What that means is that an application can ask the router "Hey, could you please let external computers speak to me on port xxxx", then the router creates a port map for the requested port.

UPnP has a variety of security problems, the main of which is that it doesn't have any built-in authentication. One example is PoC by Petko D. Petkov where he demonstrated how Flash can be used to send UPnP commands to a local router when visiting a malicious page. UPnP also makes it much easier for malware on your computer to open ports and listen for commands from a C&C Sever.

Despite not being around for a long time, UPnP has a long list of security issues mainly due to poor implementation. Researchers at Rapid7 have shown that nearly 81-million IP addresses have responded to their UPnP requests (mind you, those requests are coming from external networks), and many of these devices had vulnerabilities that can lead to complete takeover.

So my advice is this: If you want port-forwarding, you probably want it for a reason for a specific program, so disable UPnP and map the ports yourself. It's not something you'll be doing everyday.


Hardening/reducing attack surface for a Docker container I'd like to set up a hardened Docker instance, mostly for running micro-services such as statically compiled golang applications. What I'm looking for is to protect the host OS from a rogue container and containers from one another. I tried to summarize the situation with the following scenario.

Scenario:

We have a server running a minimal OS such as alpine linux (busybox-based OS), with SElinux and grsec installed, activated and correctly configured.

On this server runs a Docker instance with 2 running containers, A and B and a volume V.

The container A contains a statically compiled application with no dependencies, networked to the public Internet (web app or public API). This application contains a HUGE bug something like arbitrary code execution/upload/full reverse shell the worse you can think of. This container is also networked to the volume V as upload destination, database, etc.

The host OS contains a flag that can only be read when root (enforced by SElinux).

The container B also contains a flag and an application but no connection to the outside world.

Attacker:

Human, knows about the huge bug in the application.
He wants to get the flags. The data in V isn't important.
He's not a spy agency but still a high-grade security specialist.
May have access to some zero-days we aren't aware of.

Assumptions:

The linux kernel has bugs but grsec is enough to cover that. Can't be an attack vector unless grsec is deactivated
Grsec and SElinux don't have bugs and aren't mis-configured.
A user root in the container is root outside the container (maybe some day this won't be true anymore...)
Docker is a real-world Docker. No known-bugs but has been affected by bugs in the past and it could happen again.
A log system for future investigation is already properly set up.

Goal:

Protect the flags. Probably not possible since we assume that Docker has bugs.
Reducing the attack surface.
Make the attacker's life difficult.
Set an alarm that trigger if the attacker tries to get the flags. Preferably way before he managed to get them.

Questions:

How realistic are my assumptions?
How would you achieve those goals?
How goods are my following suggestions?
Any general security advice for Docker?

My suggestions:

Configure SElinux such as no user can write on A, and no user can execute files on V.
Use an extremely minimal Docker image, without any userland. Something like:

FROM scratch
COPY app /
ENTRYPOINT ["/app"]

De-escalate privilege before running the app. (Not sure what is the proper way to do that...)
A fake busybox user-land? Something that would trigger an alarm if we try to call /bin/sh, /bin/ls or anything like that.

I'd refer you to the CIS Benchmarks for hardening guidelines. The current CIS Benchmark for Docker can be found here. These are an accepted industry standard for baseline hardening. They also offer guidelines for Linux et al, Web servers, DBs, etc.


Is it possible to detect a Telegram user by sniffing traffic? Here's the article from the Belarusian website http://dev.by, it is an interview with a former member of dictator Lukashenko band (so-called Chief Organized Crime and Corruption Fighting Directorate). And he told how they used to detect Telegram administrators:

For example, someone dropped a picture into the chat, it has a certain weight in bytes. It is checked who at this particular time in
the country transmitted a message with such a number of bytes to the
telegram server, up to a second. So they find it.

To me, it sounds like a joke. All Telegram traffic should be encrypted, I doubt it is possible to get the exact size of the message body in bytes. Also, even if is possible, which information can be retrieved using that approach? Or the point is in sniffing the traffic in general and detecting users by IP?

Telegram is not a peer-to-peer network like Tor, but has central servers. Indeed, if you have full control over the network you can do all sorts of evil.
Once you get a list of known Telegram servers, you can monitor them and get a detailed record of who connected to the network at what time. You have both source and destination IPs.
Now, I assume the following may happen:

A phone is seized from an activits, giving the cops access to the subject's Telegram groups

Cops already gathered a timestamp archive of connections, now they have access to the contents of the chat. If they find content of interest, they may compare the timestamp of the picture, and the approximate byte size to the connections made that time. Eventually, they will get a short-list of people to investigate

Cops enter the chats

Pure and simple social engineering. Like Europol often does to hunt down child abusers in encrypted chats. Once they are in, they can get live information about who may be posting on certain chats.
The points is that this approach does not directly identifies an individual, but provides authorities a list of suspects short enough to proceed with more human ("classic" police) approaches


Why are the domains https.lk , ftp.lk and http.lk restricted on the Sri Lanka domain registry I found http://nic.lk which is the domain registry for .lk domains (I am in Sri Lanka).I typed in https.lk and it said

  'https.lk' Domain name you searched is restricted.

Why is this done. Is it to prevent phishing from someone doing something like https.lk/facebook.com. But there seems to be a domain called https.com which is already taken.

Why doesn't Sri Lanka allow the domain https.lk

Also the same for http.lk and ftp.lk

TLDs (top level domains) are allowed to have certain restrictions based on location, the type of content, and the domain names.

It is not surprising that they'd block it to avoid confusion on the domain name's owner which would appear to many as being the same as .lk.