Logging new network connections without TCP Wrappers My current job involves auditing systems for compliance with various policies. One of these policies is that all network connections must be logged, so that the origin of the connection (IP address and port) is available to trace any unauthorized or malicious access. Currently we use TCP Wrappers (either the libwrap library or the tcpd executable) for this purpose.

However, Red Hat Enterprise Linux 8 no longer provides tcpd and libwrap in the standard distribution, and it appears other Linux distributions are going to follow suit. Red Hat suggests using firewalld or iptables to enforce rules restricting connections, but it seems like there isn't a good replacement for simply logging new connections, without requiring enforcement and without logging every single packet (which would be a nightmare performance-wise).

Any suggestions on a replacement for TCP Wrappers just for logging purposes?

As noted in Steffen Ullrich's comment, it is possible to use iptables to do this sort of logging.

One of the techniques that come up in the search parameters Steffen provided is to log the second packet of the TCP three-way handshake in order to capture the IP addresses and ports of each accepted connection. The technique is described over on Server Fault: https://serverfault.com/questions/669488/iptables-log-established-connections.


Firewall audit log management tools is there any free or open source tools that is able to collect audit logs from firewall in syslog format for monitoring purposes? There is 2 firewall in my organization and I would like to track changes done in the firewall by the administrator for compliance purposes.

Unfortunately there is budget constraints and we cannot afford to purchase SIEM solutions for this purpose.

Any tools or combination of tools that can achieve this objective is greatly welcomed.

Fred,

Spunk would be perfect for this situation, it is free (if less that 500 mb of logs a day) and is easy to use.

download it here http://www.splunk.com/download

I hope this helps,

dc


Security on passwords stored by Firefox, against add-ons I am wondering how safe are my passwords stored in the passwords manager built into Mozilla Firefox. Currently I am using Firefox Quantum 59.0.2 64-bit under Ubuntu 16.04 in one machine.
I guess reasons to be concerned about may be various, e.g.:

Add-ons.
Other software having access to the filesystem.
Others?

My focus is now on item 1, and I guess here it is irrelevant which OS I am using, but only the version of FF (is this correct?).

As regards add-ons, this old answer sort of brings a red-alert.
Things may have changed since then (even though it seems to me they didn't, as for that answer).
This is also worrisome.

My questions are:

What are the possible mechanisms an add-on can have to: a) read, b) exfiltrate my passwords?
What are the easiest ways to make sure (or against the lack of that, arbitrarily trusting somewhat) that is not happening, in each case? I emphasize easiest since, I guess, an extreme answer like "become a specialist in security and code development, and read the add-on code" is always valid... I mean to apply solutions as easy as possible.
Why wouldn't it be possible to have the same security level with FF as with Keepass (e.g.), if the same encryption algorithm were used? (in Security on passwords stored by Firefox vs password manager I ask about a comparison of algorithms, which is a separate issue).

Related info, which I didn't find it answers the question:

Do Firefox add-ons have full access to passwords etc?

It can not read them directly from the manager. It may however obtain it indirectly, for example modify the websites you log into, if it has permission to modify websites. This allow it to for example modify the form to send the password tp them instead of sending it to the legitimate site.
Not to have add-ons you don't need. Use widely used add-ons. Check that permussions of add-ons make sense. Use open source if possible.
If you disable sync, it kind of is possible, though kee pass has additional abilities like allow/deny autofill on case-by-case basis, which FF probably won't ever have. But this is a bit of a moot point as FF is not focused on security to the extent to make it equivalent with KeePass

PS: point 1 is assumeing FF's sandboxing works and has no vulnurabilities, which is most likely not true.


Clearing password field after an invalid login attempt From my experience, 99%[citation needed] of the time, when you try to log on to a website, and you mistype your password, you get some indication that the login could not proceed due to incorrect information and the password field is cleared out. Usually the username field remains filled in, so you simply have to retype your password.

In a small fraction of instances, I've found that some websites do not clear out the password field after an incorrect login attempt. Is this a security issue? I can't think of how or why it may be, but I find it odd behavior since the overwhelming practice seems to be to clear the password field. Can this practice be exploited in some way by someone?

As an addendum, is there some sort of standard that says the password field should be cleared out after an unsuccessful login attempt or is this practice something that most websites have converged on without formalizing anywhere?

As a general rule, the server should not provide information about a submitted password, regardless of if that password was correct or not, back to the client.

After all, humans tend to reuse passwords, so even if the password isn't correct for that user on that site, it may be correct on a different site, such as their bank.

I'm not aware of any ways to intercept a password that applies only to receiving the password, that wouldn't apply to sending it as well.  However, the fewer number of times a password crosses a network, the better1.

If the application submitting the password does a full page refresh, then the attempted password most definitely should not appear in the password field, because it requires the server to send that information back.

If, instead, the application submits the password through an AJAX request or some other means that does not update the page (or the login form), then it is safe for the password to remain in the field, as opposed to being re-filled in for you by any action from the server.

The only ways that I can think of that it might not be safe, is in cases where (potentially) malicious scripts are loaded after an authentication attempt. However, I consider such a vector to be unlikely and contrived, and the possibility indicates that the site itself is untrustworthy, regardless of when it loads the scripts.  (Related tangent: Don't reuse passwords. Use a password manager and generate random passwords for every site; you never know when a site may be compromised (whether intentionally or not).)

The closest that the NIST standards on passwords come to making a judgement on this specific case, in section 5.1.1.2, says (emphasis mine):

  In order to assist the claimant in successfully entering a memorized
  secret, the verifier SHOULD offer an option to display the secret —
  rather than a series of dots or asterisks — until it is entered. This
  allows the claimant to verify their entry if they are in a location
  where their screen is unlikely to be observed. The verifier MAY also
  permit the user’s device to display individual entered characters for
  a short time after each character is typed to verify correct entry.
  This is particularly applicable on mobile devices.

A strict reading of this could be interpreted as clearing the password field every time it is submitted, whether using a full page refresh or using an AJAX request.  However, it is part of a "SHOULD" statement, rather than "SHALL" statement. Regardless of how strict one interprets this, the entire standard seems to assume that submitted passwords are never repeated by the server.

1Quick side note: I see a lot of people suggest to send a hash of the password, rather than the password itself, to prevent it from going across the network.  This doesn't improve security because when doing that, the hash becomes the password.


Is Diffie-Hellman key exchange the best way to securely exchange SSH keys? I'm designing the communication mechanism for end user devices that will communicate with a row of servers. My current plan is

on first run, a device will generate its own SSH key pair (RSA and 4096 bits)
the device will transfer its ID and public key via HTTPS (utilizing a valid certificate) to one of the registration servers
once confirmed, the device opens a SSH connection to a reg-server and receives the servers public key

Is this a valid approach, or would usage of "Server Authentication with Certificates" (DH key exchange) be the better == more secure way?

Looks good to me. Note that, depending on the cipher list you enable, HTTPS will do a DH key exchange. As long as you trust the SSL implementation on the device and the server, and that you audit the certificate trust list on the device, the connection between the device can be considered secure.

The only thing I'm concerned about is that the device can open an SSH access to the server. Securing SSH is very difficult because you are giving people a shell access (which includes, among other things, the ability to transfer and store files and to execute almost arbitrary programs). If you don't fully trust all the people that might have access to the device, this could be very risky to your server.

Unless you truly need to give people the ability to run arbitrary programs, it would usually be a better to expose a certain predetermined list of resources through a service wrapper, like HTTPS. This gives you more control over the execution of commands on your server.


Comparing penetration testing suites I've been using Backtrack for a while now.  I was wondering if there is anything better, or on par with, that is worth looking into.  Thoughts?

First thought - what is it you need?

If it is a wide set of general purpose tools then yes, Backtrack does come with a wide set of tools, but it doesn't do everything. Other options:

Darknet have a top ten LiveCD distros from 2008 - some of which have since died, but is a good place to start.
The russix LiveCD was ideal for Wireless Penetration Testing - but I think it has been discontinued for a while.
Helix is a forensics and incident response toolkit. Some penetration testing functionality, but the core focus is forensics.

I use all 3 of the above plus other tools - depends on what is needed, and to be honest, having each one on a USB stick or a CD/DVD is pretty easy to carry about.

If you want really lightweight distros, look at @atdre's answers to this question.


Extract a key from an AES black-box? I'm trying to figure out how a given executable works. I know it's using AES-128 to encrypt and decrypt, but the specifics of the code are unknown. I can get the executable to encrypt and decrypt any data, as many times as I want. How can I go about determining the key and method used by this executable?

For example, I've noticed that hashing the same data repeatedly only differs in the very last 16 bytes of the 64 bytes of output. What else can I try that will help me obtain the key used?

You can't feasibly obtain an AES key just by being able to encrypt and decrypt data of your choice. To broaden it a bit, no secure cipher lets you feasibly obtain the key, even if you can encrypt and decrypt as much data as you'd like. That's a combination of what's known as a chosen-plaintext attack and a chosen-ciphertext attack, and every modern cipher is designed to be secure against those. The only way to realistically obtain the key is through reverse-engineering; I'd focus all your efforts on that, not on trying attacks AES is designed to resist.


OpenID Connect with Authorization code flow and PKCE - How shoud we get a new access token in a SPA application? As answered in this question, Single Page Applications shouldn't be given a refresh token with the OIDC Authorization Code Flow.

Can you indicate some way of getting a new access token when it expires (without interrupting the SPA UX state (no redirects...)?

If the use refresh tokens were the only solutions, what are the ways we can minimize the risk of leakeage? E.g: is storing it in the browser's session storage safe enough? Do IdPs provide a some form of refresh_token expiration, etc.

Once the access_token has expired you need to re-authenticate against the openid provider to get a new access token. The openid provider should take care of remembering who is logged in (e.g. through a persistent cookie), and immediately redirect back to the application without re-authenticating the user. If you want this to happen with no redirects visible to the use then you can complete this in an iframe.

If the openid provider requires that the user re-authenticates then you are out of luck - if you perform the re-authentication in an iframe then you will want to have some sort of detection for this case as it won't be visible to the user.


Hydra HTTP Form Post with parameters containing a colon ":" I'm trying to brute force login on my domain using THC Hydra v9.1-dev. It is using an ASP.net form and some of the required post body parameters contain a colon : in them which is the separator used by Hydra. An example parameter: _ctl0:PlaceHolder:LoginName:txtLoginUsername=^USER^.

This makes hydra think that I have _ctl0 as the first part and Placeholder as the error message.

I tried:

URL encoding them, e.g this becomes: _ctl0%3APlaceHolder%3ALoginName%3AtxtLoginUsername=^USER^
placing the parameter in quotation marks ""

but none of them worked and I can't seem to find a way to change the separator.

Any help is much appreciated!

According to the documentation: colons should be escaped with backslashes \


Chrome vs Explorer - how to explain in plain words that open-source is better? Why open-source is better in plain words?

Yesterday I had a talk at a DIY bicycle workshop. There is a PC (running XP) that main application is checking emails (nothing really serious).

I found it excetpionally hard to explain why open-source security standards are better, that security-thru-obscurity is not the right approach, that you cannot rely on algorithm being secret...

Any other ideas coming across - how to explain in plain words why open-source is more secure?

(or maybe not, maybe bicycle fixers were right - I should use IE)

Open source software is not necessarily better or more secure.

Where open source has an advantage is the potential for independant security minded individuals to examine the source code and hopefully the conceptual model for a given software project. This advantage is contingent on:

review by qualified individuals
feedback from the reviewer to the project about potential weaknesses or vulnerabilities in the source code, algorithms, and procedures
the project fixing the reported weaknesses and vulnerabilities
the project becoming better educated as to what makes software more secure

Given enough itterations of the above, any software, not just open source becomes more secure than the average.  Many closed source companies perform software security reviews. Some even bring in third parties to ensure indepent and objective reports. A project providing open source allows a wide audience to review any part of the software bringing transparancy to the review process and the software implementation. The difference with most closed source programs is that the process and implementation is inaccessible to the users. A user can not determine whether a piece of closed source software has been security reviewed. And in most cases a user can not determine whether a piece of open source software has been security reviewed. The only difference is that, given a capable enough user, that user can check on the status of the open source process, but they can not check on the status of the closed source process.


Xbox 360 Security - Why must you be the data owner to move content? Xbox 360 does not allow you to move content (such as to a usb), unless you are the owner of the content (Same gamertag as save file). This seems pointless considering, I can simply sign into any account on my Xbox anyway, so the only thing this security seems to do is slow me down when I'm trying to move a mass amount of files from one Xbox to another.

Is there an actual security reason for implementing such security practice?

This is to prevent you moving content belonging to another profile that has been password protected.

As you mention, this does not provide much security if the profiles are not so protected, because you can just switch between them: but having the XBox behave differently depending on whether the password is set or not adds complexity, which costs money and risks adding bugs. Remember too that some of content has DRM attached to it, adding to the complexity and requirements.

And it's not necessarily about security. Won't most XBox users only have a single profile? Won't most people moving content in multiple profiles be replacing the hardware in a shared XBox, and so can use Microsoft´s migration tool? So won't most users never encounter the scenario you have?

As an advanced user, of course, you have perfectly good reasons for having multiple profiles, and even better ones for not using Microsoft's tool, but it's hard for Microsoft engineers to justify features that only advanced users need in such a low margin product.


I found that I could delete the state parameter in an OAuth request and the response was validated and e-mail was still verified I was fiddling around with an OAuth2.0 request on burpsuite and I found that it validated the account even after I deleted the state parameter completely and forwarded the request through burpsuite. I would like to report this as a bug so I want to know if this has any attack vectors.

I think it is not enough for the poc. Just make another account and see if you can validate it from the original account.


Impact of the System Information Leak Our application stored **e.printstacktrace()** in a log file, which is accessible to a specific user group. We need such detailed information for debugging purposes.
As per the security team, they are requesting us to remove such detailed system information from the log file, so here my question is about how it will affect the security of the application.

Logging stack traces to a log file is in itself usually not a security issue, but the exposure of information in the log file can be, depending on your threat model, the information contained in the backtraces and the specific user group in question.
One example of a case where stack traces might contain sensitive information is if they could cause user credentials or other PII to be logged for your developers to see, who should not otherwise have access to this information. Another problem might be if the stack traces are exposed to a potential attacker, who may use the leaked information (e.g. pointer values) to circumvent mitigations such as ASLR.
If your security team is asking you to remove that information, I'd suggest you work with them to figure out what information exposure they are concerned about, which threat model applies, and how you can keep the same level of insight without compromising on your security.


Can username/passwords be intercepted on an App using public wifi? I use the ADVFN finance app for stock prices every morning on the public wifi on my train to work. This requires me to login with my username and password on the app(which are saved).

Do apps provide an extra layer of protection against potential hackers or could this data be intercepted?

Depends on the app. Some perform certificate checks, ensuring that you're connecting to a specific server with a specific secure method using a verified certificate, in which case, you're probably safe. Others simply make a HTTP call or don't bother verifying that the https certificate is legit, in which case, you're worse off than a website using HTTPS.

No general case, I'm afraid.


Safety in Access Control Matrix and Take-Grant Model I'm learning about the Take-Grant Model and Access Control Matrix, and I have a couple of questions regarding leaking and the safety question.

Definitions

These are the definitions I am using (see for example here [pdf]:)

Leaking: Adding a generic right r where there was not one
Safe: If a system S cannot leak right r, it is safe with respect to right r
Safety Question: Does an algorithm exist to determine whether a protection system S is safe with respect to generic right r?

Access Control Matrix

Lets say we have an access control matrix:

    S1      S2      O1
S1  o               r
S2  r,w,x   o

Could you say that in this matrix, the right r of S1 over O1 is leaked to S2 (because S2 can use S1 to access O1)?
or would you need a sort of copy right, which allows actual copying of a right from one field to another? And if so, wouldn't most systems that have a copy right automatically be unsafe (see also my question regarding the take-grant model)?

Take-Grant Model

In the take-grant model, can a system only ever be safe if for every subject S1 that has right t over another subject S2 it also has all the rights S2 has over any objects and subjects?
and if not, why not? Am I misunderstanding what leaking means?

So for example this:

would not be safe, because S1 could get right r over O1 from S2, and thus there would be a right r where there was not one before?

In this case, a safe system would need to be designed like this?:

This would seem a little odd to me, because if that was the case, the take right (or the grant right) would not make that much sense (at least if one wants to create a safe system).

I'm gonna try to answer you separately:

Access Control Matrix

Q: "Could you say that in this matrix, the right r of S1 over O1 is leaked to S2 (because S2 can use S1 to access O1)?"

A: No. If you consider the execution right to behave like a take right, then yes, S1's reading rights over O1 have leaked to S2, because originally S2 had no rights over O1. But the papers i could find only showed that behavior when S2 had own rights over S1. Therefore, your example S1 rights would not leak to S2 because S2 did not have own rights over S1.

Take-Grant Model

Q: "In the take-grant model, can a system only ever be safe if for every subject S1 that has right t over another subject S2 it also has all the rights S2 has over any objects and subjects?"

A: That is correct. Remember that, according to definitions 3-1 and 3-2 in the document you linked, the security of your system is calculated on a right-by-right basis. If you convert it to a Turing Machine, your system is considered safe when, given all the possible operations, starting from an initial state s0, it is not possible to achieve a state sN where a Subject has any right that it did not have originally.
To put it clearer:

  Is there an arbitrary sequence of commands that adds a generic right into a cell of the access matrix where it has not been in the initial configuration?

I think that the graph you created was not very didactic. If you're willing, the second link i post here gives a better notion of the available operations and the possible resulting graphs.

The third link references the original paper that described the Take-Grant model. In this paper, they use the name "call" in one of the described commands. You should note that this operation is related to the right of creating new nodes in a graph, it is not the concept of execution right we used above, ok?

References:

https://www.cs.columbia.edu/~smb/classes/f05/l03.pdf
http://www.volkerroth.com/ss09-itsec/03.pdf
https://cs.nmt.edu/~doshin/t/s06/cs589/pub/2.JLS-TG.pdf


What are the security risks of letting the users upload content to my site? As a web designer (not a security expert) I wonder: If I allow users to upload content to my website (videos, images and text files), what are the real risks involved?

There's a couple of risks from allowing content to be uploaded onto your site, but how important they are to you will likely depend on exactly how the site you're designing will work.

First up is malware upload.  If an attacker can upload malware onto your site and that malware is downloaded and executed by your users then that's likely to be a problem.  Preventing this usually relies on a combination of restricting the types of file that can be uploaded (one point to note is that you shouldn't just rely on file extension here), and using malware scanning on uploaded content. Of course the scanning side of things will only stop known signatures, and can be bypassed fairly easily.

Second potential problem is if they can upload active content and have that executed by your application.  So for example if your site uses php, then if they can upload a php script and then get it to run as part of your application then they are likely to be able to take control of the server, or at least access other information that exists in the app.

One approach I've seen to addressing this is to ensure that the uploaded files are not placed in the web root and ensuring that the web server will not execute files from that location.

A third risk, is users uploaded "illegal" material. This can be a tricky legal question to sort, but if you allow user generated content you're likely to have to deal with it sooner or later.  The fix for this seems to be primarily procedural.  Have a good relationship with your hosting company and ISP and ensure that you can respond to requests to have content removed quickly, if you're hosting in a jurisdiction that requires content to be taken down if a request comes in (eg, a DMCA request).


House owner can see who's connected to WiFi; what more can he see? I live in a rental house, and use the house-owner's wireless network to connect to the internet. The owner can see who is connected to his wireless network and I had a few questions regarding this matter:

Can he see which websites I visited?
Can he crack my email password and see my email contents?
Can I know if he is hacking into my computer?
How can I protect myself against this?

1) Yes, atleast the certificate which contains the TLD even if you use SSL, the full contents if you don't.

2) If you are not using TLS or SSL to access your e-mail server, he doesn't need to "crack" anything, he can just read the password being sent on the wire and can see all your e-mail.  Use of TLS or SSL when connecting to your mail server will prevent this.

3) If he was any good, you wouldn't be able to, but keeping it patched and running a firewall should provide reasonable protection.

4) See each individual answer for countermeasures.  Additionally, you could use an encrypted VPN.  He'd know you were using the VPN, but the VPN would prevent him from knowing anything you were doing.  This, however, requires a VPN provider and the VPN provider would still be able to tell the same info you are worried about the owner doing.


How do I find a target on the wired network, from an attack system on Wi-Fi? I'm trying to practice penetration testing on my home network. The target system is my desktop computer, which is connected to the network via ethernet cable. The attack system is my laptop, which is connected via Wi-Fi. My laptop is running Ubuntu Linux 12.10.

I'm simulating an attack by someone who has gained access to the wireless network, but is interested in data that resides on a particular computer which happens to be on the wired portion of the network - my desktop. In this scenario (foregoing any further knowledge I have about my network or the target system) I'm having a hard time finding the IP address of my desktop.

Tools such as ipscan or nmap only appear to find devices on the wireless side of the network. I know I could go to the router, and pull up the list of connected devices, but that would require foreknowledge (or cracking) of the router's password - something I'm pretending to not have at this point.

In this scenario, how can I use my laptop to find my desktop on the network and establish a connection? Again, I'm simulating the role of an outside attacker who's just gotten access to the Wi-Fi - all I know is the Wi-Fi SSID, Wi-Fi PSK, Wi-Fi AP's MAC address, and the network's gateway address.

Simply so it shows as having an answer:

nmap -sn <your IP address>

...will perform a ping scan across all the connected hosts, quickly showing what IP's are responding to pings on your network.

Note that this is case-sensitive.


Untrusted signature on java app for downloading youtube, harmful? If you visit most of the "online youtube download" pages, you will get this message:

Why all these sites come up with this message? Is it a worm, or just an unharmfull app?

Well, there's no way to know that for sure without looking into the application...
Although, it does seem incredibly suspect.

This message lets you know that your browser is trying to launch an applet in trusted mode, which means that the Java code will have full control over your system.
You probably shouldn't accept, unless you know (and trust) the publisher.

...Which is exactly what the warning says.


DNS settings compromised from WAN on Edimax ADSL router My home network Edimax AR-7084gB ADSL modem/router with firmware verison 2.9.5.0(RUE0.C2A)3.5.18.0 was exploited from WAN few days ago. The attacker changed DNS server settings - primary server to 192.99.14.108 and secondary to 8.8.8.8. The first DNS server served a trojan virus (detected as Crypt3.NRM by AVG) via a fake Adobe Flash update page. My location is Czech Republic and media reported about the modem exploit with similar DNS settings so this was quite now common in my region.

I swapped the modem for a different one in the meantime (Siemens CL-040-I) which hopefully will not be compromised anytime soon. My question is what should I do in long term to prevent similar attack on the modem side? Sure I could set manual DNS server on all PCs but I dont want this because of administrative inconvenience. Will a common inexpensive brand new SOHO modem have a secure enough firmware to prevent most of the usual exploits? Are there any modem WAN security rankings that I could use then looking for new modem brand and model?

I updated firmware on the Edimax to version 2.11.38.0 (dated 2010-12-08, original version dated probably to 2007/2008) but I am not sure if that will be enough to prevent the exploits. Before the attack the modem had a custom weak password and with WAN administration disabled.

Edit: I realized that my WAN administration was enabled, because it is enabled in the factory settings (probably of all historical and current devices with Trendchip Front End since this Front End still ships with TP-Link or Edimax !!!) Such a factory settings is unbelievable... One has to explicitly forbid that in a custom Access Management setting. I guess most users won't do this after purchase anyways and thus reveal their login page into the public internet...

I also found the chipset type of the modem here (see "Specifikace"):

CPU: Trendchip TC3162P2
Front End: Trendchip TC3085 (web admin)

In security practices we try to patch the vulnerabilities. But if the patches are not available, we try to make attackers life hard by things like isolation.

There are huge problems with WAN Management in routers these days,
you should disable it, if you really do not use it. Unlike modern OSes,
patches for router OSes comes very hardly.
Many ADSL routers provide built-in firewalls in these days. Make sure Incoming Default Policy = Deny.
Limit WAN access IP if possible in your router and go to some
different port for accessing console, if supports.
If your router supports you can try Open WRT like firmware/OS which
has relatively good patching cycle.


Closed Internet Explorer inprivate trace Suppose that a user uses inprivate mode in Internet Explorer and browsed something.

Now, an administrator wants to search the user's activity in Internet Explorer using the user's PC without having to search network log file.

How can I recover the history from the user's PC?

Edit: I would like to know the window he closed at the last moment.

The whole point of the private modes that modern browsers have is to make this difficult, by removing temporary cached files, leaving no history and not storing cookies.

As @drjimbob says, your best bet is probably going to be to dump RAM if you don't have access to any of the network logs.


Wordpress: a Virus detection plugin is necessary? Is a Virus detection plugin is necessary for WordPress nowadays?

EDIT: I mean to prevent attacks and violations... for example i'm using this plugin: https://sucuri.net/wordpress-security/wordpress-security-monitoring and i recive daily emails about some "Login Failures" using "admin" as Username and some differents passwords from a lot of different IP address.

Yes.

Hosting a Content Management System (like Wordpress, Joomla, Drupal, and moslty all other CMS) means permitting users* to upload arbitrary files.

(* As users I mean: your authorized - but not necessarily experienced - users. Thanks to Jan Doggen for this precision)

So even if

your server doesn't try to execute this files,
your server is up to date and doesn't hold any known vulnerabilities

Uploaded files could be downloaded by other users and website visitors, who could use vulnerable systems.

In order to prevent this, if you hold arbitrary shared files, you have to check new uploaded files... And recheck them everytime your virus database will be upgraded (thanks to Steffen Ullrich for warning me about this)

But no.

If you

are the only authorized user on the box (or you really trust each other users)
don't care about what's happen outside your box,
keep your box up to date finely

Wordpress work fine without anti-virus


Why would an attacker use eval as part of a payload? Now don't get me wrong, there are already other questions like this. But I'm looking into more of how an attack could actually be done.

Instance A: A hacker gains access to a web server / hosting. They make changes to files so that instead of the original code, malicious code will run.

Ok, so I think scenario has many obvious problems. Even if a hacker somehow managed to get into a server, why would they use eval() of all things when they have the entire code at their disposal, it would probably make more sense just to run malicious code on the server and modify the existing code anyway.

Instance B: A hacker gains access to an consumer's device, uses a saved password to log into the victim's account and proceeds to execute malicious code.

In this instance, eval() wouldn't make much sense, because they have the account already. Either use the interface (say transferring money from the victim to the hacker), or just execute code in the DevTools?

Instance C: A hacker uploads malicious code to a public forum site (like SQL Injection). When a user opens this site, the tags <script></script> are inserted into the DOM rather than plain text.

Well as a general security measure, shouldn't all code be validated both on the client and on the server to  make sure that code isn't being entered? Additionally, it's already a good practice to pass in data as plain text on client pages. This is just to raise the point that validation is important, not that eval() would be used. Because validation before any eval() is always important, so even if they used code as a string passed into eval() instead of inserting the code into the DOM using script tags, the code shouldn't even reach the database because the server should have validation anyway.

So in conclusion, I can't think of a scenario where eval() would be the best play for a hacker, as if they had access to that, I would assume that they would take better methods at their disposal (like modifying source and DevTools) rather than using eval().

The way I understand it, eval is often used because it allows flexibility, to run whatever code the attacker wants. It's part of their "web shell", their way to interact with infected servers. I guess eval is just one of the quickest and most flexible ways to interact with an infected machine and make it execute the attacker's code.

// very simple example: in practice often you will also find
// obfuscation, base64 encoding, compression, POST instead of GET, etc.
$command = $_GET['foobar123'];
eval($command);

// request that will likely execute any PHP code on any server
https://www.example.com/index.php?foobar123=code_to_execute_here

Other access methods are probably not that flexible. For example, suppose the attacker has admin accounts in several infected CMS's. Only using their admin account, to run their malicious code they would have to install a malicious extension, and each extension should be coded specifically for each CMS type (WordPress, Joomla, Drupal, etc.). So it looks like it's hard to find a quicker and more flexible method than eval (or similar functions like exec, etc.).


What security concerns are there regarding website users inputting personal financial data without putting in personally identifying data? I am a web developer, but I have only a rudimentary grasp of security, e.g., be careful to sanitize inputs, store as little user data as possible, encrypt passwords, keep up with security issues of libraries and packages, etc.
Today, I was approached by a client who does financial planning about replacing a spreadsheet he gives clients with a web-based form. The spreadsheet asks users to input certain financial data - e.g., current value of various investment accounts, business interests, etc. These numbers are put into a formula and a value is generated which is supposed to help the user decide whether the consulting could be useful to them.
The phone call was very short, and my questions focused on more mundane matters about user experience, desired UI elements, etc. No commitments have been made, and I'm analyzing the project to see if it's something I can do. I began to think about potential security issues, and I realized I really don't know where to start. So far it seems that client wants the form to be accessed via a magic link, and that the user would not enter any personally-identifying information. I do not know yet whether my potential client wants to store the value generated, a simple dollar amount which is the 'benefit' the user could get by using the service. The impression I got is that my potential client simply wants to use this value as a motivator for clients to inquire further about his services.
In this scenario, what security-related matters should I consider?

It's the details that are confidential, but the outcome as the amount of dollars alone doesn't tell much to anyone. Before rushing to details like UX and UI one should define the desired use cases and functionality first. I see two possibilities, and both are good from your perspective:

The tool is intented for personal use of the user alone, and the profit your client gets is bound to the impression it leaves to the user i.e. the user desides to use the services based on the results. In this case the user experience of the form is highlighted, as it's purely for advertisement. However, it also makes it possible to do everything client-side and the application doesn't need to save any of the information on the server. Regarding PII this is the easiest solution.

If the application saves any possible PII, it's your client's responsibility to deside what information is collected and how it's stored and used. Depending on the jurisdiction there might be special requirements for that, e.g. EU GDPR, national privacy acts or even PCI DSS. You should have them to define their needs, and while you can give some advice, after you have finished with the project it's their data on their responsibility.


Is using desktop 2FA clients like Authy Desktop a good practice? Basically 2FA relies on the idea that instead of just something you know, using a service also requires something you own.

I am quite confident, especially when used on iOS (which has a better system level app segregation), that this gives a pretty good security. Though I am not sure about adding a desktop 2FA utility.

In my understanding, an attacker would need to intercept my password (likely through a keylogger on my desktop machine were I log most) and an access to my phone, or to the key stored on my phone. But I can likely picture that someone able to setup a keylogger could steal enough information to reuse any 2FA system available on my desktop computer.

Writing this I am understanding that this is based on the perception that:

Computer integrity < Phone integrity < iOS integrity

Computer are more likely to be corrupted through the pile of junk I am installing on it and their more important "openness" to system changes.

Smartphones have a more restrictive ecosystem and a shorter livespan, thus a lighter probability to be infected.

iOS, is comparatively the most closed ecosystem where unlike on Android most access are not opened in API and the app checking is more thorough.

You made an assumption that affects your outcome, and you cannot forget that you are making this assumption: that one "likely" gets your password via the desktop computer (i.e. keylogger). If that is your threat analysis, that's perfectly fine, just don't forget that you have made this differentiation.

Since your threat analysis is desktop-based, then yes, your conclusion is correct that adding a security function to the already-assumed-to-be-compromised desktop does not add a layer of security. If one can get your password, then one can get your 2FA code.

But, a desktop 2FA option is not useless if we change our assumptions. If we assume that one is more likely to get our passwords from the services we use (instead of our desktops), or even that one can get passwords from our mobile devices, then the desktop security measure legitimately adds a useful security function.

The ultimate question becomes: what is the most likely vector of password compromise? And that question changes constantly. And that's why being mindful of our threat assessments and reviewing them from time to time is very important.

So, the desktop 2FA option is a valid one, depending on your threat analysis.


How secure is an IP whitelist compared to other web service security mechanisms like a passphrase? When securing a web server/web application/website, you often have the choice between choosing something like using a password for authentication/securing a service and creating an IP whitelist or whitelisting a whole subnet.
Or e.g. using/hosting the service in a subdirectory (may be faked/configured by the web server) that is not guessable, like /my_private_service_CiMMQf4aTU6sTdmkFFRuDyv5f.

So I have three common mechanisms.

Things that should be clear

Obviously, some first thoughts:

IP blacklists are obviously not that secure – you can't just blacklist all "bad attackers".
The password/passphrase/string authentication of course is only secure, if it is chosen properly, e.g. totally randomly string for the URL. (like shown in the example above)
Of course, you may be tempted to say "just combine them all", but let's say that for usability/convenience reasons, this is not what I want (at least not combine them all), so as I'd need to create a "best-of" trade-off I would be in the need of a ranking of what is the best?

(This is a hypothetical/general question. I deliberately did not choose a specific web service/example, to make this useful for the general public.)

Within a network segment (e.g. an Ethernet network in an office) IP spoofing is fairly easy with tools like Ettercap, so a passphrase is much more secure.

On the wider Internet, IP spoofing a TCP connection is definitely not trivial. It's possible with BGP poisoning and maybe some other techniques, but not something your average pen tester can do. Still, I'd say a passphrase is more secure.

IP whitelisting is difficult to deploy, as a typical user will use different IP addresses - home, work, mobile - and most of these are dynamic IPs. You can often use it to whitelist whole organisations, as a company will typically have a single or a small number of outgoing IP addresses, and this can cover mobile users who connect to the office with a VPN. The main limitation with this is that you normally want to control access to individual users, not whole organisations.

Where IP whitelisting can be really useful is as an additional control mechanism to a passphrase. Quite a lot of business SaaS platforms offer this as an option. If you configure it, it means employees can only log in from work (or via VPN), not from home. This keeps business data on business workstations. And when someone leaves the company, they lose access to cloud services, even if the admin forgets to disable their account on that service.


Looking for a race condition example that we can use internally in training I'm making a small CTF for my digital team to teach them about different exploits. I'm hoping to include a race condition example but everything I've found manipulates a local file or SQL database (so multiple users can't follow along at the same time).

Does anybody have a sample race condition I can use in a CTF with multiple people at once? Unfortunately because of our internal process I can't use online sources for this and need to host something local.

Back in 2011, Taylor Hornby wrote a TOCTTOU vulnerable PHP web application that is often found in banks and such that can cause Race Condition bugs, its a cool application.

The application is well explained in https://defuse.ca/race-conditions-in-web-applications.htm and I think can become a useful resource. (it explains a lot of issues and responses to each)


Authentication SSO token security - SAML, OpenID Connect I am trying to understand how works various SSO technologies like SAML 2.0, OpenID Connect 1.0.

In general, they work in a similar way providing tokens (XML, JSON) through Identity Provider to Service Provider.

What I don't fully understand is how are these tokens secured so nobody can steal it and use it from different device in order to get authenticated session and impersonate.

Also, how are these tokens stored? Are they stored as a cookie in a browser? If so, would it be possible to steal a token cookie and use it to impersonate somebody?

How can I detect that the token is used in an unauthorised manner?

I am looking for a practical view how are tokens secured and represented when authentication is established or when using as SSO, so authentication is not required by Identity Provider.

The tokens are secured at multiple level

Transport - Most of the specs recommend SSL (and some mandate it)
Use once - These token are just meant to transfer identity once and then the asserted identity can be attached with local session for further processing. Most of the specs contain safeguards to allow IdP & SP to track the generation and use of token only once.
IdP Trust - The IdP & SP trust mechanism is built in to ensure that only trusted Identity Provider can set an identity at service provider through the protocol.

The checks for MIM and other attacks are built in to each protocol and you can read the RFC/Specs for each of the protocol to see how they stop those attacks.


Is opening image from the web in google chrome safe I want to know is it safe to click on an image on facebook to be displayed in my browser, ( in case it's a real image and not a link to external URL).
I'm asking about facebook especially and all websites generally.

Is there is any risks in this or it's safe?

David has a valid point about image-based exploits (we did see a few) - but those are the kind of threats where ordinary folk can't keep losing sleep on.

Mainstream browsers are mostly safe if you only open the image. Do make sure -

that you're not opening the image in an untrusted site's html page. You did mention this - direct image link, not an external html page. Be wary of being redirected from what looks like an image link though.
to protect against script attacks after redirection, use a script-blocker (like NoScript) or ad-blocker (like uBlock Origin and/or uMatrix).


Safety while ciphering data Say I wanted to encrypt some sensitive information with a symmetric algorithm using a program on a computer. Is it possible that a hacker could retrieve the data,salt, iteration, cipher, keysize while the program is generating ciphered data and after? If possible, how can I prevent this?

Yes, it is possible for an attacker to gain access to your private and sensitive data during encryption or decryption.

This attack is known as memory sniffing attack. In my opinion this is very sophisticated attack. The attacker dump the machine memory (e.g. RAM, swap files, etc) and then analyze this data to retrieve sensitive data (e.g., password, cryptographic keys, etc)

When an attacker is executing this attack on your machine it simply means your machine is already compromised.

How to reduce the risk of this attack?
In my opinion, it is all about secure coding practices. In short, make sure when you are implementing your encryption/decryption algorithm that you apply secure coding standard.

The following link contains a post that explain the memory sniffing attack and explain how to prevent/reduce this attack

  You should read more about memory dump attack and secure coding. Several programming languages provide some guidelines and sometimes APIs to reduce the risk of memory dump attack. Here is another article.


Why host third party libs instead of relying on CDN, Nuget, GitHub? I'm struggling with some enterprise security guidelines requiring 3rd party libs to be hosted internally. The immediate concern is over our build server connecting to GitHub for package resolution, but we've been hitting NuGet for years and were blissfully pursuing CDN hosts for our in-flight production apps.

What security does self-hosting provide if I already trust the package author & contents?

What security does self-hosting provide if I already trust the package author & contents?

Including content from a third party system outside of your control does not only mean that you need to trust the authors of the content to not willingly add malicious content but that you also need to trust them to keep their systems available and secure. In other words: including content from a third party host makes your vulnerable against DOS attacks to this hosts (i.e. harm availability) and also compromise of the third party system which can impact your own security.


Is Linux kernel  RCE vulnerability - CVE-2017-1000251 (BlueBorne vulnerability) practical? In BlueBorne Technical White Paper, the authors mention

  It should be mentioned that testing and triggering this
  vulnerability was not an easy task, and required direct use
  of the ACL layer to send malformed L2CAP packets. Since no
  Bluetooth stack provides this to the user ...

As an end user, such a vulnerability appears to be more of a theoretical concern. Is my understanding correct?

The part from the paper you cite essentially says that you need a special client to create the exploit. This is roughly similar to saying that you cannot exploit a specific bug in a web application with the standard browser but that you need enough knowledge of the HTTP layer to write a customized program for it. While this might be too hard for the average user it is no real obstacle for a person with that specific knowledge. And it might even get easy for the average script kiddie once an exploit is released as proof or test of the vulnerability.

The part of the paper which actually answers your question is the sentence above the one you cite:

  This makes the stack overflow presented above easy to exploit - as we demonstrate in the demo video.

And, as for the knowledge needed to exploit the attack also important information are included after the part you've cited:

  We will be releasing the testing framework we developed, alongside an
  exploit code of this specific vulnerability in a future blog post. This testing framework could assist
  researchers in further exploration and pentesting of Bluetooth stacks.


How to obtain body from RSA signed document without verifying signature? According to my understanding of computational cryptology, the body of a signed document can be retrieved disregarding whether or not the signature is authentic. However, I cannot apply this practically:

Given a pair of RSA keys private.pem and public.pem, I have signed some data:

openssl rsautl -inkey private.pem -sign -out signed.dat -in clear.txt

I believe that signed.data now has the contents of clear.txt, a hash of those contents and the actual signature, which is basically a cyphertext of the hash using the provided key. Thus, one can verify the signature and recover the body of data. Concretely:

openssl rsautl -verify -inkey public.pem -in signed.dat -pubin

To which the contents of clear.txt are output to stdout, and the file signed.dat can be considered to have an authentic signature. It is clear that to verify the signature, public.pem must be used to reverse the cyphering of the hashing of the contents and compare this result with the clear version of the hash. However, the contents themselves should also be available to anyone without the public key. They should be somewhere in cleartext or some other uncyphered format in signed.dat.

How can one obtain the content of clear.txt from signed.dat without any keys?

If I am wrong in my concepts of cryptology, I would also appreciate some clarification.

I had to remove my answer because it was flat out wrong: the PKCS#1 v1.5 scheme for signatures used by OpenSSL is only used partially (thanks Dave for yet another insightful comment). That also means that is doesn't hash the input - but that means that it doesn't fully respect the security claims of PKCS#1 v1.5 and upwards either for that scheme. So it should really not be used that way, as it is now used as a scheme giving message recovery rather than a scheme giving signatures with appendix.

The input text is padded according to OpenSSL, and then modular exponentiation is performed using the exponent of the private key (or, more usually, the same calculation using the Chinese Remainder Theorem, but that's beside the point). If you perform modular exponentiation with the exponent of the public key they you would get back the padding and the text. However, to do that you would need the public exponent (usually set to 65537, so that's not a problem) and the modulus (which is a problem, although not as big a problem as the RSA problem itself).

So the text is indeed within the output, but you can only retrieve it if you somehow recover the public key. Earlier versions of PKCS#1 would say it is encrypted with the private key (newer versions go out of their way to explain that modular exponentiation with the private key is not encryption, even if it is the same mathematical operation that is performed). So you can then decrypt with the public key and restore the data.

Note that the RSA padding scheme used is that for signature schemes, not encryption schemes; it will always create the same result for the same message, and therefore it leaks information. So even if the public key can remain secret, RSA signature generation is not the same thing as encryption with an actual cipher (this is why AES encryption generally requires an IV).

So openssl -sign generates both a broken signature as well as broken encryption for a given message.

The solution offered was correct, kind of: if you want to have both message and signature in the same container format then you can use the openssl cms -sign options. That way you don't have to verify the signature to retrieve the plaintext.

That said, I don't see any option to output it without verification, and you need a certificate to perform the signing. Including the data (rather than creating a so called detached signature) is optional. CMS is a much higher level protocol than just RSA, so you may consider it cheating.


How to verify crypto engine? If I understand this correctly, when I use a cryptographic (hardware) engine, I have to trust it. Are there any cryptographic algorithms with properties that allow me to verify the correctness of an engine in a computationally cheaper way than to do the same work myself?

EDIT:
In my paranoid reality I assume the engine was specially built to return correct results except for plaintexts with certain keywords for which it would build in a backdoor. What I am looking for is a general way to verify the correctness of the output for arbitrary input without knowing the correct output (although I am not sure this is mathematically possible).

If you want to check the basic functionality of a cryptography engine, throw a good selection of inputs at it, and check that it returns correct results on these inputs. If your sample is well-chosen, you can have confidence that the engine is functionally correct.

Many cryptographic algorithms based on mathematical structure (typically, public-key algorithms such as RSA) have methods to get some confidence that the result is correct without doing all the work. For example, if you run a computation that is based on operations modulo a large integer, you can perform the computation modulo a small integer and check that the result is correct modulo that small integer¹ — a generalization of casting out nines. This technique is known as wooping. Such checks can work against malicious bignum libraries if you test with enough random small numbers. However, you can't always do this; for example, if there was a way to check a cryptographic digest that was cheaper than computing it the long way, the digest algorithm would be seriously broken. I don't know of anything comparable for symmetric encryption algorithms.

If you want to know whether the cryptographic engine is secure, that's a completely different matter. The engine might be leaking data through side channels, and you cannot notice this by testing. You can only notice this by very careful study, preferably open-box. Similarly, the generation of random numbers cannot be tested, and is hard to get right; you can gain some measure of confidence with statistical tests, but not all statically sound random number generators are good enough for cryptography, which requires unpredictable random numbers. Here are some examples of vulnerabilities which can be very difficult to detect, and are practically impossible to detect if they are deliberate backdoors:

The random generator has a low entropy: it returns random numbers that are predictable with an unreasonably high probability. Example (accidental): the Debian OpenSSL vulnerability.
The engine leaks confidential information such as RNG output or key material through its response time. (This is an example of a side channel, there are side channels other than time: power consumption, radio emissions, etc.)
The engine leaks confidential information through normal channels in an undetectable way, thanks to a subliminal channel. For example, every time the engine generates a random nonce (an IV for block encryption modes, RSA padding, the signing parameter k in DSA, etc.), the n-bit random value is in fact an (n-1)-bit random value plus a bit of the key encrypted with a secret key.

Cryptographic engines can be certified to conform with security standards such as Common Criteria and FIPS 140. Excluding “trivial” certifications such as FIPS 140-2 level 1 which don't really say anything about security, a certification takes several man-months and is performed by experts. Even if your crypto engine is certified, read the certification carefully: most certifications only vouch for the engine if it's used under very precise conditions, and only against attackers with limited means. And of course in fine the certification is only one professional's opinion; certified products can and have been broken.

¹  I'm simplifying quite a bit. Read about it in Sami Vaarala's lecture notes or in Bruce Schneier et al's Cryptography Engineering or in Jurjen Bos's thesis.


Am I at risk for giving my email, name and phone number to a scammer? I signed up in UFX using my email, name and mobile phone number. I immediately received a call from an unknown number, which was from an employee who tried to take my bank account information so he would supposedly help me to input my debit card on the site. Also during the call, using some communication tricks he managed to quickly acquire a few information such as If I have ever done a trade with my account before and approximately where I live. Of course, I didn't give him my bank account info at I immediately closed the phone, after realizing where this is going.

My questions:

Is my bank account at risk?
Can they use my voice as verification for other trades? (the "Yes scam" that I read about)
What more personal information is at risk?

Is my bank account at risk?

Not directly. But the scammer can/will work to get a "foothold" using the information they have on you. You are also now clearly on the radar of a scammer and I would consider yourself at high risk.

  Can they use my voice as verification for other trades? (the "Yes scam" that I read about)

I sincerely hope not. If a company allows for verification of a trade with no account information or verification code or any sort of "multi-factor", It would be very concerning. You should check with the company and see what is required for a verbal verification. Also, "Yes scam" is a bit of a misnomer. Not a lot of "voice signature" based verification out there. If an attacker has your account numbers and calls into an automated hotline, it won't matter that it's a female voice saying "Yes" if you're actually a man. That's not checked for as far as I know in the vast majority of those systems.

  What more personal information is at risk?

They will try to leverage the information they have to get into your accounts. If they can get into any account, they will get more information and continue. They will also probably launch a Phishing scheme (don't click email links without putting them in virus total's URL check https://www.virustotal.com/#/home/url, at the very least. Ideally just don't click email links).

  What to do

Change your passwords. Do you have a password in the format of [Name][Date][symbol]? If so you don't have to be a hacker, someone can guess it in 100 guesses probably. Create a strong password (4, 4 letter words with a cap and 1 symbol or number is easy to remember and far more secure than 8 characters).

While you're changing your passwords, check for strange log in activity on your accounts. Notify UFX.


VeraCrypt: Is it possible to change the password after an encrypted container has been created? I would like to know whether it is possible to change the password after an encrypted container has been created? The password I chose was a bit weak, and I would like to be able to modify it without having to extract all the data, delete the container, recreate it with the new password, and then shift the data back to the container (plus, in this way some evidence of the files would remain on the hard disk due to the way NTFS undelete can be exploited).

So, can I change the password after creating the container?

You don't change the random key with what everything is encrypted but just the encryption of this key. So yes, it is perfectly possible and therefore you have a menu entry under "System" for doing exactly this.

How this works in detail is basically answered here.

Implement in VeraCrypt desktop version 1.24-Update4: Menu bar > Volumes > Change Volume Password…


Vulnerabilities Database by OpenVAS Does OpenVAS make use of a Vulnerability Database to detect vulnerabilities?
 Which one does it use if it does?

You can view the Network Vulnerability Tests (NVTs) here or here, the majority of these will be downloaded as .nasl files (Nessus Attack Scripting Language).

To see exactly what they test against or to edit them the simplest way to install OpenVAS and update it, then look at the code for each of the .nasl files in the filesystem.

By default these can be found at /var/lib/openvas/plugins


How many overwrites make a drive undesirable? I wanted to wipe free disk space of my PC, as I had accidentally deleted confidential data permanently without securely deleting them. So wiping the entire free disk seems to be the only option now.
I know that generally 1 overwrite is enough and no better than the 35 overwrites proposed by Peter Gutman. However, because I am a bit paranoid, and CCleaner names the 35 pass method as a very complex overwrite, I personally want to go for that. I understand it might be useless, but still, I hope you understand the paranoia.
So I was wondering whether 35 overwrites of the entire free space will cause any damage to the free disk space? How many overwrites generally make a hard drive unusable or inefficient or undesirable/problematic?
PS: Sorry, was unable to find a relevant tag. Help is appreciated.

As A. Hersean said, if it's an HDD, as in spinning magnetic rust, multiple overwrites are not an issue.
"... 35 overwrites proposed by Peter Gutman {sic}. ..."
This is a holdover from the MFM drives used decades ago. Even Peter Gutmann has said that this is no longer useful.
"... because I am a bit paranoid ..."
I can appreciate that but you are putting your concern in the wrong place. I'm guessing you are probably using Windows as people who aren't generally specify. The more significant concern lies in a different place than pointless multiple overwrites.
In Windows, small files (up to 1.4KB but typically less than 900 bytes) are not written to their own file block on the HDD. Instead they are written directly to the Master File Table (MFT). Normally the MFT points to where a file resides on the file system, however each MFT entry has enough space to handle small file content directly, so it's written there instead of to a separate disk file block. When the small file is deleted, the MFT entry is marked as available but the actual MFT is never deallocated to become free space.
The other big concern with Windows is Shadow Volumes. This consists of back versions of your files. This is how Windows provides the capability to rollback. Deleting a file does not necessarily delete the older versions of the file in Shadow Volumes.
The most effective thing you can do is encrypt your drive. Bitlocker can encrypt a currently in use drive, so too can Veracrypt for Windows.


Linux tool for monitoring network activity by application My laptop have been hacked a few months ago and my data is being to uploaded to some remote server without my knowledge.

Is there a way I can find it out and prevent it from happening?

I have changed my hard disk and installed a new distribution but its not helping. I have installed some applications like wireshark but I am not able to pin point the applications and prevent it from uploading my data to server.

Is there any application which would pin point the application which is uploading my data.

I think your friends on this case are wireshark + lsof + netstat, by mastering these tools i'm sure you can identify the application that is uploading your data.


Preventing access to file for process running as root I have a client with a legacy application running on RH 3 (=the latest version supported by app).  There is a process that has to run as root (and not in a chroot environment).  I need to prevent this process from accessing some sensitive data files.

According to this post, it seems SELinux can do this:
Restrict access to a specific directory on Linux

However, I do not know SELinux and I am trying to find out if my specific scenario is possible on such an old RH distro and with the process running as root.  If it is, I'll need to read up on SELinux (unless there is an easier way to accomplish this).

Is this possible?  If so, some details / pointers would be great.

There are two solutions:

Use a tool like SELinux. It's designed specifically for this particular task, but it takes some real understanding to use effectively. You'll need more than just a few pointers, you need to go read and understand the documentation.
Use a virtual machine. The "root" program runs in its own VM on your server and can't see anything outside its own little world.


How do I deal with a compromised Active Directory? We suspect that our Active Directory infrastructure in the company has been compromised. If this is in fact true, this will be a huge headache since we have a few thousands of users.

If indeed it turns out that we've been breached, how do we implement a password change for users in the company?

Obviously this is going to be difficult since the supposed attacker might try to regain access to the network as we push the change of passwords out to users.

The first step should be to follow your organization's Information Security Incident Response Plan.  If you've never tested it before, it will likely be lacking in some things, so be sure to take notes as you go and update it after the incident.  Your company's next step should be to bring in an outside security response firm to help navigate the problem.

Until they arrive, you need to start by locking the attacker out completely. Isolate the entire forest of Active Directory servers from the rest of the network.  Create brand-new dedicated accounts for your domain admins to use strictly for domain administration purposes going forward, and then remove domain administrator authority from all users, including yourself.  Take a copy of the Active Directory logs, so you can figure out which accounts he may have accessed, changed, or used.  Those accounts are obviously your priority for password changing.

Now you can reconnect your AD servers to the network.  From this point forward, use only those special accounts for domain administration tasks; and never use those special accounts to log in to any machine that isn't an AD server.

Never grant domain admin privileges to any account that can be used to login outside of the AD servers.  Instead, use the new accounts to manage the domain by local login only.  The reason for this is it's likely the attacker compromised a workstation that one of your domain admins had logged into.  The attacker then used a pass-the-hash attack to log on to your AD servers, and that's when it was game over for you.  You never want your domain admin credentials exposed outside of the AD server environment.

Next, close down the attackers entry and exit points. Shut down or disconnect from the network any compromised machines; depending on the data in those machines you may have to preserve them as evidence.  You'll also have to figure out what he took, gather evidence, report it to the appropriate authorities, send out breach notifications if required, etc., etc., etc.

Only after you've done those first response steps is it time to think about having your users change their passwords.

There is an easy way to get the rest of your people to change their personal passwords: send out a notification to everyone that you will be requiring them to change their passwords, then set the "User must change password at next login" flag on all accounts that allow interactive login.  A few days after you've notified them, you should lock out any accounts that still have unchanged passwords. Any remaining affected users will have to call your help desk to unlock their account before they can log in.

You'll also probably have a lot of non-user credentials in your organization. These are the service accounts for all your back end systems, and they all need to be changed, too. You'll definitely need to find the technical owners of each of those systems, and work with them to make the changes. Changing dozens of non-user passwords is one thing, but changing thousands of them is way too big a task for one person.  You'll need organization. You'll want to assign security people to each handle one or more of the various divisions and departments. If you don't have enough security staff, you'll have to deputize some of your trustworthy technical folks.

You also will need to scan all the machines in your domain; review every member of the Administrators groups you find; and discover any local accounts (administrators or not.)  The local accounts need to have their passwords changed, too.  You could enforce this by sending a group policy to the domain-joined machines to require local accounts to force a password change.

But don't involve your users until after you're absolutely sure you've secured your systems, and you know the intruder can't return. You are not only wasting their time if you have them do it twice, but you're appearing to them like you're scrambling. There is a huge psychological blow to people when they've been violated, and you will need to outwardly project an image of situational control. "Uh, hey guys, can you all change your passwords again?" is not a confidence builder among the troops.


Simple Hydra test with Windows RDP I am using VMware and have 3 VMs all on the NAT network with DHCP. All three machines can ping each other. From one windows to the other windows, I can RDP into the 192.168.190.130 windows machine just fine.

I want to confirm that hydra works, so back on my Kali VM, I try the following command hydra -t 1 -V -f -l username -p password1! rdp://192.168.190.130. After hitting enter I get two [DATA] messages, 1 [ATTEMPT], and then it pauses for a long time and prints [STATUS] messages to the screen for example:
[STATUS] 1.00 tries/min, 1 tries in 00:00h, 0 to do in 01:00h, 1 active

I am looking for the indication that there was a successful attack, but I never see it.

When I open up wireshark and view the traffic, I see TCP traffic on 3389 port happening back and forth, but it never returns with a successful notification.

If no firewall is blocking packets between Kali Linux and the Windows Box, Hydra should be able to successfully notify that the provided credentials worked

root@kali:~# hydra -t 1 -l username -p password1! rdp://192.168.190.130
Hydra v8.3 (c) 2016 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.
Hydra (http://www.thc.org/thc-hydra) starting at 2018-05-24 11:05:56
[DATA] max 1 task per 1 server, overall 64 tasks, 1 login try (l:1/p:1), ~0 tries per task
[DATA] attacking service rdp on port 3389
[3389][rdp] host: 192.168.190.130   login: username   password: password1!
1 of 1 target successfully completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2018-05-24 11:06:00


how free internet proxy works I tried to get free internet bypassing my mobile network's ISP using a proxy setting in my mobile. I got the instructions in some trick I read and it actually works. When I browsed the proxy page, it opened.

1) How my mobile network ISP is allowing packets to proxy?

2) I read that they create an ssh tunnel between my machine and the proxy but there is no application on my machine to forward http data into ssh tunnel
so then how http traffic is redirected to ssh.

Try searching "free internet airtel proxy" for better understanding.

First and Foremost the "trick" you are using is an exploit of your ISP's poorly planned infrastructure. As such it is most likely just as illegal as joining your neighbors WiFi because they left the default password enabled.

Why it works:

Your ISP is only monitoring HTTP/HTTPS traffic either via a transparent proxy of there own, or deep packet inspection.  For whatever reason, they are not monitoring (or more likely monitoring but not charging) for other forms of network traffic ie VoIP services.  This means if you setup your device to tunnel its traffic through to an external proxy via sock5 or socks5 over ssh ... your packets will be logged as non-HTTP(s) traffic and thus you will not be charged (yet).

Why this is Dangerous:

The "FREE" proxy you are using is most likely doing nefarious things.  Your ISP works with in the limits of the law ... this means they will not do things like steal your sessions, rewrite client-side javascript, steal your credit-card information ... etc.  I would recommenced watching this video for examples of what vulnerability you are exposing yourself to by doing this.

Also, as I mentioned already ... use of this exploit is illegal.  There is a very high likelihood that your ISP is tracking this bandwidth and while it is not currently charging you for it ... could retroactively charge you for it in a future bill.


Why are signatures considered a valid authentication method? Why are signatures considered valid methods if identification when paying with a check or credit card? For that matter, what do those credit card readers do with my signature when I sign them? Are they validated or compared to my signature stored at the DMV?

Extra points for people who can point to ways that companies are trying to better validate that I am actually authorizing payment for something.

Why are signatures considered valid methods if identification when paying with a check or credit card?

Historically, we didn't have anything better. In theory, signatures are very good authentication methods, since hand musculature is relatively unique and it's quite difficult to forge someone's signature accurately without a lot of analysis and practice.

However, in practice, the people who check these signatures work in high-street stores. They aren't security people - they just want to process your order as quickly as possible and move onto the next customer. As such, even if your signature is only vaguely reminiscent of the one on the card, they will likely accept it.

On the plus side, many stores do store the stub with your signature on it, or send the stubs off to the bank for archiving. This means that you can go back and look at the receipt later if fraud is claimed.

Is this acceptable? From a security perspective, it isn't. It's not very strong, and in practice can easily be exploited. From a business and cost perspective, it's good enough and saves them a lot of money in terms of buying new equipment. The cost of fraud to the retailers is less than the cost of rolling out a better system, so they don't do it.

  For that matter, what do those credit card readers do with my signature when I sign them? Are they validated or compared to my signature stored at the DMV?

I can't say I've had any experience of the DMV, but I've used similar systems at the bank. From what I can tell, they display the signature on-screen for the cashier, with some kind of overlay of the stored signature. It looks like it tries to point-match the two for a better idea of whether or not it is genuine. Arguably it could be defeated, but it does seem to be a better solution than a purely human validation. Of course, I'm also relatively sure that the cashier could accept or reject the signature regardless of what the computer shows - it's simply a visual aid.

One thing I have seen done, which does increase the strength of a signature as an authentication method, is directional matching. When you write your signature down, you do so in a very precise order. The direction of the loops and changes in acceleration / deceleration as you write are very difficult to forge. Observing a signature on paper and attempting to forge the way in which it was written is much harder than just forging the final product.

  Extra points for people who can point to ways that companies are trying to better validate that I am actually authorizing payment for something.

Most countries (especially in Europe) now use chip + pin, which is significantly more secure and, as a bonus, much more eco-friendly! Less pens, less paper, less waste. I'm personally surprised that it's taking so long for the USA to adopt it.

Another new technology that has come out recently is contactless payments, which a few banks have adopted in the UK. It's a balance between the security of chip + pin, and the convenience of just using your card without any authentication. Essentially the card contains a small NFC radio, and you can make payments of up to £10 without entering your pin just by holding them against a payment system. There is usually a limit of 3 transactions before you have to enter your pin again.


Can we use one CA to revoke certificates generated by another CA? I have a hierarchy of certificates which contains:

root-cert

server1-CA (issued from root-CA)

client1-cert (issued from server1-CA)

server2-CA (issued from root-CA)

client2-cert (issued from servier2-CA)

I need to generate one CRL file and use it in both server1 and server2 (or in other servers).
Can I revoke client certificates using root-CA (to have a unique CRL file)? Or is there a way to merge multiple CRL files ?

No, not in pratice.
No, you can't. CA can revoke certificates it signed/issued only. There is a number of reasons of this choice. Although, RFC 5280 supports delegated revocation authorities (through registering it in the Issuing Distribution Point CRL extension), in practice it is not implemented by crypto clients in most cases.
One simple example: two CAs issued certificate with matching serial number (serial number uniqueness must be provided for each separate CA key, technically, two CAs may have certs with the same serial number) and you revoke it. The question: which certificate did you revoke?
The only thing you can do is to revoke subordinate CA certificate (effectively revoke all certificates down in path of that subordinate CA).


Why is my Apple keep asking me to change my password for no reason? is it hacked? Just changed into a new password like three months ago, and it keep ask me to change into a new password, and the system is very stupid in denying that my new password is correct and constantly ask me to set up a new one after another new one. Is my iphone hacked?

This type of thing sounds to me like something somewhere has an old password stored someplace and is trying to use that password to log in resulting in the account being locked. This could be iTunes on a computer, iCloud or even your web browser or password manager if you are trying to log into an Apple related web service. It could even be some other iDevice like an iPad or iPod. If that is the case you'd have to locate what ever it is that isn't using your new password and make sure to change it there the next time you change your password.


Any not totally insecure browser vulnerable to BEAST? People still worry about BEAST quite a lot when configuring web servers to the point of preferring RC4 over AES-CBC. But most browsers mitigate BEAST even while using TLS 1.0.

Is there a browser that:

Is vulnerable to BEAST or to Lucky Thirteen
Doesn't have known vulnerabilities which are much worse, such as remote code execution
Has a non negligible user base

Is BEAST still a reason to avoid CBC? What about Lucky Thirteen?

It should be noted that BEAST requires some hostile code which runs on the victim's browser, code which is able to send arbitrary requests to the target Web site, with enough "control" on the sent bytes to pull off the CBC-related calculations. In particular, this cannot be "just text". The BEAST authors had to find some sort of channel which would evade the Same-Origin Policy. They found two:

one in Java, which has been fixed soon afterwards (and unfixed Java plugins have other, bigger holes);
one in a draft version of WebSocket, which was never widespread (being draft) and has been fixed; actually, it was already fixed when the attack was published, although the fix was serendipitous (it was a change which was meant for protecting against something else).

Arguably, BEAST cannot be exploited nowadays unless another SOP hole is found. Moreover, even if such a SOP hole is found, current browsers to the 1/n-1 split which also prevents BEAST from being applicable. This method has been applied in major Web browsers more than one year ago (see this) and I don't believe that there was no remote-execution bug found in these browsers in the last year. This would mean that, indeed, there is no reason to worry about BEAST anymore. Switching to TLS 1.2 would still be good nonetheless.

The Lucky Thirteen attack is, arguably, not an attack on the browser but on the server. It requires the browser to engage in a lot of requests to the server (in a BEAST-similar setup), but the leak comes from the server: the server processes an incoming record, and the MAC verification will fail, but some subtle timing measure may reveal whether the PKCS#5-like padding was correct or not. It is claimed that almost all vendors (at least the open-source ones) fixed their code to avoid the leak that Lucky Thirteen relies on.

Web browser brand and version has little relevance to the Lucky Thirteen. Theoretically, one could reverse the setup and attack the processing of records sent by the server to the client, but it would require that the attacker has sufficient control over the server's responses to make the attack work, and that seems quite hard.


How does GnuPG encrypt secret keys? When creating a secret key with GnuPG, you are asked for a password to protect it. Which encryption algorithm is used to achieve this? The handbook only says that a symmetric encryption algorithm is used.

GnuPG 2.x has a separate gpg-agent that is the custodian of secret keys and that offers no control whatsoever over the encryption parameters of the secret keys within.

Furthermore, --s2k are accepted but ignored when setting a passphrase or exporting a secret key.

There is an issue on the bug tracker about this and, when followed up on the mailing list, the answer was

  No, that is not possible.  Right now the agent always uses AES and S2K
  paremeters which require on the running machine about 100ms for decryption.

So I believe the current situation is that keys are held by the agent as the agent decides is best to meet its speed target on the running machine and there is no way to control it or to export differently. All exports I have tried result in key attributes that you can see like this:

$ gpg --export-secret-key DEADBEEF | gpg --list-packets
iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: ...

This reveals the symmetric-key (algo) and hashing (hash) algorithms in use, as defined in RFC4880. The above shows that algo: 7 is AES with 128-bit key and hash: 2 is SHA-1.

The iter+salt tag is the string-to-key mode that GnuPG uses to convert the passphrase (string) into a key. The default value iter+salt means that a salt is added to the passphrase and that string is hashed multiple times (a technique called key stretching which aims to increase difficulty of brute-forcing passphrases).

So that illustrates how GnuPG encrypts secret keys and highlights the fact that you have no control over it if you're using version 2.x due to its use of the gpg-agent.


Chrome inline JavaScript string interpreatation If you have an HTML file that contains the following code :

   <!doctype html>
    <html lang="en">
    <head>
        <meta charset="UTF-8">
    </head>
    <body>
        <script type="text/javascript">
            var a = '</script><script>alert("xss")</script>'
        </script>
    </body>
    </html>

when opening it in a browser, it will incorectly (?) alert "xss".

Is this normal behaviour for browsers (in my case the latest Chrome) to interpret JavaScript strings as being valid tags ?

Yes it's normal.

HTML is parsed first, then JavaScript. So, after encountering a <script> start tag, the browser will look for the closing </script> tag. When that's found, the collected string will be parsed as a script if the type (usually and defaults to JavaScript) is recognizned.

If you use the DOM inspector (F12, or right-click -> Inspect Element), then you'll see the following tree. In the JavaScript console, you'll also see that a script error has occurred (the first string is not terminated).

The third </script> tag is not visible in the screenshot, because the DOM parser did not find a corresponding start tag. So it's omitted.


How do I protect an application from malformed packets? I'm running an application behind a Linux firewall, and I'm afraid that it might be vulnerable to malformed packets (eg. a webserver that is vulnerable to malformed HTTP requests). How can I filter the packets so that they are conformant to some format I define (eg. a formal grammar)?

How can I filter the packets so that they are conformant to some format I define (eg. a formal grammar)?

As far as I know there is no general purpose filter software you could use to normalize the traffic based on a formal grammar.  For specific protocols like HTTP you might try to use IPS (or inline IDS) like Snort, Suricata, Bro or commercial firewalls but in my experience they are very tolerant to protocol errors. For HTTP you might also application level gateways (i.e. reverse proxy) which in my experience are a bit more strict and at least normalize the traffic, i.e. implicitly remove some malformed data. A special type of these HTTP gateways are web application firewalls (WAF) which are usually more strict than normal HTTP proxies.

But none of this solutions filters everything, i.e. your application should be robust enough so that malformed data will not cause security problems. If this is not the case I would not make the application accessible from the internet.


Finding Security Loopholes and reporting ( web applications specifically) The people who get a place in the hall of fame or get acknowledged specifically for attacks like XSS, rce and some common type of attacks which can be detected by scanning tools such as owasp, Nessus, vega, etc. Do they report these vulnerabilities only? Or they find something apart from what the scans cant tell?

I'm new to finding vulnerabilities and need guidance, a dedicated enthusiastic and passionate person towards information security but no direction

Scanners are useful for a quick, basic security scan of a system to give indicators of vulnerabilities, their reports should never be trusted without validation and they often over report giving false positives.

It seems your question is geared towards bug hunting programmes / bug bounty schemes and if you just submit scanner reports to these programs you are unlikely to be acknowledged. In fact many schemes ban the submission of automatically generated reports if they even allow the use of  such a tool, remember they could do that themselves easily!

The people that are successful in these programs, those that receive bounties or are entered in the halls of fame use other tools and techniques to discover vulnerabilities that won't be exposed by a standard wide spectrum scanner.


Qubes and DOM0 being Fedora 25? Is it safe to run an unmaintained version of Fedora in dom0? Fedora 25 went EOL on December 12th, 2017. Qubes is currently based on Fedora 25. From the Qubes FAQ,

  Dom0 is isolated from domUs. DomUs can access only a few interfaces, such as Xen, device backends (in the dom0 kernel and in other VMs, such as the NetVM), and Qubes tools (gui-daemon, qrexec-daemon, etc.). These components are security-critical, and we provide updates for all of them (when necessary), regardless of the support status of the base distribution. For this reason, we consider it safe to continue using a given base distribution in dom0 even after it has reached EOL (end-of-life).

It seems like the Qubes team is essentially saying that they're maintaining the Kernel and Xen from the Fedora 25 branch themselves. Looking at some of the Qubes Security Bulletins I found this one, Fedora os-prober considered harmful. The solution there was to remove that package from dom0. How many other packages are in dom0? It seems like the average install of Qubes includes running a window manager in dom0. If so, does Qubes repackage KDE/Xfce and the like or do they use the EOL'd stuff in FC25?

Dom0 has been designed in such way that it is (or should be) impossible to have any Internet connection other than when downloading updates for various dom0 elements (kernel updates, template VMs to name a few) only through the updates VM, it's usually the Net-VM or some other VM that is using the Net-VM for network access.

Considering that the update repos are not compromised, the only way Dom0 and essentially Qubes could get owned is by installing any third party software on it. *

So any bugs on potentially outdated software on Dom0, like the Xfce or KDE Plasma are irrelevant to a machine that has no network connection and uses only software trusted by the Qubes Team.

*I should note that I was referring to potential compromise through action directly from Dom0. If you're wondering about privilege escalation from another VM to Dom0 you're probably looking at GUI agent exploits.

For example, one of the core files of qubes-gui-daemon is programmed to prompt the user whenever a VM attempts to pass an invalid/very large value to a specific window size, marking the behaviour as suspicious and as an attempt compromise Dom0 (line 156).


Is showing your IP address in the URL a bad practice? Someone told me that showing your IP address in a URL (like http://192.0.2.34/default.html) is easier to hack. Is that true? I could trace any domain name and get its IP number as well.

Easier to hack?   No.  Easier to DoS?  Potentially.   Using an IP address instead of a host name with a DNS entry means you're giving up a layer of routing flexibility that can be very beneficial.

For example, if malware targets your IP address in a DoS attack, if you're using a domain name, you switch the IP address of the site and in the DNS record, and the attack is over without your users knowing the difference.  If your users are making requests directly to your IP, however, that isn't an option.  You're tied to that IP unless you want to inconvenience (and possibly lose) your users along the way.


Is there a list of default, standard or third-party "users" for Oracle? When installed, and depending on which options it is installed with, there are a bunch of standard users pre-created in Oracle. Additionally, third-party software often has its own set of schemas/users that will be created in the database as part of the application install or setup.

Is there a list of these users, preferably with the 'source' (such as Standard oracle user, Application XXX)?

This would assist me in auditing which users are needed and which might be superfluous. Default passwords would also be useful to confirm that the defaults are not usable.

An excellent starting point is the list on Pete Finnegan's website.
[I'm not employed by him or his company. ]

Usernames in the format APEX_nnnnnn or FLOWS_nnnnnn (also APEX_PUBLIC_USER) are associated with the Application Express component of Oracle. This is an optional component in 9i and 10g, but is part of the standard install for an Oracle 11g database (and the XE edition of 10g).

http://www.petefinnigan.com/default/oracle_default_passwords.htm


Is there any reason a password and pin combination isn't more popular? So one of the problems with password is that users reuse them or use some weak password. For the latter, even enforcing pattern does not work as users will simply go for something like P@ssw0rd1 that is easy to guess.

So instead of a user or email and password login, why not a pin and password? The pin will be generated during sign up (It can be as complex as the webmaster makes it to be and not necessarily a 6 digit pin like your bank card).

This way, even if the user decides to make a simple password, the account will always be protected by a secure and unique passphrase whether the user likes it or not.

Some banks actually do this. The issue is the same as with just generating a random password for the user and not allowing them to input one. They will inevitably write it down. Also, using a pin as username frustrates targeted attacks but for short pins and large sites, attackers can pick a random pin and chances are it will belong to some user. You would need to make it longer to be effective.

Finally, if the pin is ever leaked, it can be difficult to change, if it acts as the username.

At the end of the day, pin and password are the same type of authentication: using something the user knows. Therefore anything you can do with a pin, you can also do with a password, just append the two for a longer password. Using it as username unnecessarily complicates things.


How sqlmap tests/injections are seen by the victim? I wonder if the normal webmaster can get some information about SQL injection into their sites. I guess that it is written in some log, and only if you happen to see the logs you'll see that activity, am I wrong?

Should the attacker be using some TOR proxy in order to be hidden when performing some tests, or it isn't as exposed as to be considered?

What will be seen by the defender in this situation largely depends on what logging they have in place and where the injection is located in the HTTP request.

If the injection is in a GET request (e.g. http://vulnsite/vulnpage.php?id=5 ' OR '1'='1) then this would show up in most web server logs as they usually log the full GET request.  So a defender would likely see a large number of requests to the vulnerable page with unusual data in the parameters.

If the injection is in an HTTP POST (so as the result of a form submission) then most web servers won't log that by default. The web server log would still show a large number of requests to the page in all likelihood, but the detail of exactly what was happening wouldn't be immediately apparent.  Additional logging could be deployed but (AFAIK) this isn't the default in most set-ups.

On the second part of your question.  The IP address that the connection is made from would be logged in both cases, so if this is the genuine address of the attackers system then it may be possible to trace this back to a specific location or person.  As such many attackers do not come directly from their own systems but go out via a VPN or another compromised host.  TOR would be another option but from what I've seen the performance of TOR may not meet the requirements for speedy exploitation of SQL Injection issues.