How is PowerShell's RemoteSigned execution policy different from AllSigned? I'm still pretty new to PowerShell, and recently read this in a blog posting about creating and using PowerShell scripts.

To prevent the execution of malicious scripts, PowerShell enforces an execution policy. By default, the execution policy is set to Restricted, which means that PowerShell scripts will not run. You can determine the current execution policy by using the following cmdlet:
Get-ExecutionPolicy
The execution policies you can use are:

Restricted - Scripts won’t run.
RemoteSigned - Scripts created locally will run, but those downloaded from the Internet will not (unless they are digitally signed by a trusted publisher).
AllSigned - Scripts will run only if they have been signed by a trusted publisher.
Unrestricted - Scripts will run regardless of where they have come from and whether they are signed.

You can set PowerShell’s execution policy by using the following cmdlet:
Set-ExecutionPolicy <policy name>

To me, the notation of "unless they are digitally signed by a trusted publisher" in the description of Remote Signed seems to imply that it operates the same as AllSigned.  Is there a difference I'm missing somewhere?

Obviously AllSigned requires all modules/snapins and scripts to be code-signed. RemoteSigned only requires signing for remote files.  What are remote files?

The canonical answer is on the PowerShell blog:
http://blogs.msdn.com/b/powershell/archive/2007/03/07/how-does-the-remotesigned-execution-policy-work.aspx

But the bottom line is: RemoteSigned only requires code-signing on modules/snapins and scripts which are flagged as from the "Internet" zone in the 'Zone.Identifier' alternate data stream, unless you have "Internet Explorer Enhanced Security" activated, in which case it also includes "Intranet" flagged files and UNC paths.


MS Active Directory vs OpenId Connect? I have to setup a user authentication system which shall be used for more than one application. Coming from Windows background, Microsoft Active Directory came to mind naturally.

But I have heard about OpenId Connect protocol as well. Interestingly, it act as, not only as authentication server but, identity provider server as well. It seems to be default choice for modern day applications.

If I don't have any organization to support, I see no reason to go with proprietary Active Directory.

But yet, I could find nowhere formal comparison between the two. I am not sure if I am making a correct choice.

What could be different considerations which can help me to zero-in on one among those two?

The reason you can't find a formal comparison is that you're comparing apples and oranges: AD is a server application while OpenID Connect is a protocol. Consider the following sentences:

Clients authenticate to Active Directory using the Kerberos protocol.
Clients authenticate to _____________ using the OpenID Connect protocol.

If you want a comparison of Kerberos and OpenID Connect in terms of protocol things like bandwidth used, ease of working with the API, etc, that can be done. If you want to compare Active Directory and _____________ in terms of application things like usability for end-users, flexibility of config for admins, etc, then you'll need to find one or more vendors who sell authentication platforms that support OIDC and compare the application as a whole to Active Directory.

One obvious point that I'll throw in is that OIDC vendors tend to be focused around "single sign-on" or "authentication-as-a-service" meaning that they are cloud-native, integrate easily into all kinds of websites, and someone else takes care of the datacentre part. That said, I think Azure AD also does all of those things, while being a full Active Directory ...


Is originating number tied to an SMS from a mobile phone? I've been working with an SDR (software-defined radio) as part of a computer security class project. We've been wondering if, let's say a mobile phone associates with the SDR (which is operating as a fake BTS), and then tries to send an SMS, then would the SDR be able to pick up the originator address (as the mobile phone number) from this number?

In the first place, does a mobile phone know its number at all? Or does it only know its TMSI number? How does it identify itself when it sends an SMS to its GSM provider's BTS then?

Phones don't even know their phone number. Sure, there is a number field in the SIM card that can be updated remotely by the carrier, but most importantly there is no guarantee that field is even set or is set to the correct number. Phones identify themselves to the network using the IMSI of the SIM card (and proves that it indeed is the card associated to that IMSI by crypto based on the card's symmetric KI key) and from there use the random TMSIs assigned to them by the network.

The numbers are added by the mobile network infrastructure down the line. You can very well have multiple numbers tied to a single SIM card and phone, and you can theoretically change your number in a matter of seconds (though in reality most mobile network infrastructure is legacy crap that won't allow it, but technically there is nothing preventing this from happening if carriers were using decent software).


Are there different characters that appear exactly the same in browsers' url lines? I've heard of phishing scams using misspellings of urls. But can a url look exactly the same as a legit one in the address bar, while actually being a different url?

But can a url look exactly the same as a legit one in the address bar, while actually being a different url?

Yes, that can occur. It's an advanced phishing technique known as IDN homograph attack.

Homographs (or homoglyphs) are characters that look very similar or even identical. When browsers started supporting internationalized domain names, it became possible to display non-latin characters in URLs, so you could theoretically mix different languages in one domain name.

Can you tell the difference between these?

http://exаmple.com/
http://example.com/

(The first a is actually cyrillic.)

As a response to homograph attacks, browser vendors have established their own IDN policies (e.g. Google Chrome, Mozilla Firefox). They mitigate the problem mostly by blacklisting potentially confusable characters and displaying URLs with non-latin symbols as Punycode under certain conditions. That's why your browser will display the first URL as http://www.xn--exmple-4nf.com/ when you visit it.

Converting potentially misleading URLs while maintaining usability (e.g. you would still want to display a literal ä to someone in Germany) has turned out to be somewhat elusive which is why even in 2017 there are still new homograph attacks being reported.


Stackpivoting techniques I'm practicing exploit development and one of the scenario I am haing most difficulties with is stack pivoting besides the "ADD ESP, XXX" or something like that.

The question is, during the writing of a ROP chain, when you don't have any usable gadget that mess with ESP register (like ADD, MOV something in it) what can i try to move ESP back to my buffer and so start the ROP chain?

Im on a Intel IA-32 in a Windows environment (7+ with DEP enabled).

Assuming you're building a ROP chain that needs to manipulate the stack, you can always go for semantically equivalent gadgets, e.g. PUSH/POP, MOV ESP XXX, (SUB,ADD) ESP instructions to build the stack:
https://www.corelan.be/index.php/2010/06/16/exploit-writing-tutorial-part-10-chaining-dep-with-rop-the-rubikstm-cube/#chainingbasics
http://neilscomputerblog.blogspot.com/2012/06/stack-pivoting.html

Also, for XXX/actual constants (immediates) for SUB/ADD ESP XXX, you can always LEA a register then even MOV ESP, XXX/REG:

https://web.archive.org/web/20171107030509/http://x86.renejeschke.de/html/file_module_x86_id_176.html

Last, depending on the DLL/EXE you're searching for gadgets in, if you can't easily ADD/SUB ESP you could do a slew of things (using volatile registers):

;ADD/INC ESP SEMANTICS EQUIVALENT
POP EBX      ;semantically same as MOV EBX, ESP; ADD ESP 0x4
XOR EBX, EBX ;zeroes EBX if you wanna reuse the register

;SUB/DEC ESP SEMANTICS EQUIVALENT
PUSH EBX     ;semantically same as MOV ESP, EBX; SUB ESP 0x4

You can even get fancy and mov values into a volatile register, SHL/SHR/ROL/ROR it and then use LEA/PUSH. It's all up to you to be creative!


Which is the best way to sanitize user input in PHP? These are things I do when users submit data:

substr if extra characters found.
htmlspecialchars() + ENT_QUOTES + UTF-8
str_replace '<' '>' in user input

What more things need to be done?

“Sanitisation” is an unhelpful and misleading term. There are two different animals here:

Output escaping. This is an output-stage concern. When you take variable strings and inject them into a larger string that has a surrounding syntax, you must process the injected string to make it conform to the requirements of that syntax. What exactly that processing is depends on the context: if you are putting text in HTML, you must HTML-escape that text at the point of making the HTML. If you are putting text in SQL queries, you must SQL-escape the text at the point of creating the query.(*)

Input validation. This is an input-stage concern, making sure that user input is within the accepted possible values for a data item. This is primarily a matter of business rules, to be considered on a field-by-field basis, although there are some kinds of validation that it makes sense to do to almost all input fields (primarily checking for control characters).

Input validation does have security impact in that it can mitigate the damage when you've made a mistake with your output escaping. But it is not enough to rely on input validation as your only text-handling measure because you're always going to need to allow the user to use some characters that are special in some syntax or the other. You're going to want to be able to have a web page about fish & chips and a customer in your database called O'Reilly.
“Sanitisation” confuses these two concepts and encourages you to address them at the same stage, which can never work consistently. A common anti-pattern is to HTML-escape all your input. But you don't know if each input element is going to be output to HTML (and only output to HTML) at that input processing phase. If you do this:

you end up with HTML-encoded material in the database, that can't be cut up and processed without the entity references getting in the way;

if you need to create content from that data that isn't HTML, like send an e-mail or write some CSV, you've got ugly mangled text in it;

if you get content in your database from any other source it might not be HTML-escaped and so outputting it straight to the page still gives you XSS vulnerabilities.

“Sanitisation” as a concept should be destroyed by fire, then drowned, cut into little pieces and destroyed by some more fire again.
(*: in both cases it is wiser to choose a method that does the processing for you implicitly so you don't get it wrong: use an HTML templating language that escapes output by default, and a data access layer that uses parameterised queries or object-relational mapping. Similarly for other kinds of escaping: prefer a standards-compliant XML serialiser to manual XML escaping, use a standard JSON serialiser to pass data to JavaScript, and so on.)

substr if over limited values found.

Do you mean truncating too-long input strings? That's OK as a form of input validation where your business rules have valid reason to limit the length of an input. But you might prefer returning an error to the user if you have a too-long input string, as depending on what field it is it might not be appropriate to quietly discard data.

htmlspecialchars() + ent_quotes + UTF-8

This is output escaping. Do it on the values at the point you drop them into HTML, not on input. If you are using native PHP templating you may like to define yourself a shortcut to make it quicker to type, for example:
function h($s) {
    echo htmlspecialchars($s, ENT_QUOTES, 'UTF-8');
}
...

Hello, <?php h($user['name']); ?>!

str_replace < > users input

What for? If you are HTML-escaping correctly, these characters are perfectly fine, and unless your business rules says otherwise may be quite valid to include in a field—just as both characters are valid for me to type in this comment box for SO.
Of course you may want to disallow them in input validation for specific fields—you wouldn't want them in a phone number or email address.


Should I implement access control on databases inside a trusted network? Excerpt from Redis' security article:

  Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.

AUTH command aside for a minute, I think this makes sense--if your program is only designed to operate under trusted conditions, why bother adding authentication to it? I believe this is the route micro services typically take. Each service is free to communicate with other services in the same network.

But are databases (MySQL and the like) a different story? Typically, I will configure multiple user accounts, one for each micro service that only has access to its own database (under the entire database server). However with the route Redis is taking, is this still necessary?

Are access controls redundant, or is Redis less secure than classic databases?

Yeah, "designed to operate in a trusted environment" is a fairly common thing for backend servers, though you usually see it as justification for not using TLS between services, or for new nodes to join the cluster with no auth. In the Redis case, they are using it to justify a port with no auth by claiming that an attacker would need to be able to ping the port directly to do any damage. Basically, this is a way of shunting responsibility for security away from the software and onto the network engineers. Maybe you're comfortable with that and maybe you're not, but Redis is being up-front about it so you can decide whether Redis is an appropriate technology for your security goals.

With databases an attacker can sometimes attack the db through your app (for example if you have an SQL Injection vulnerability), so we talk about the Principle of Least Privilege; ie each node has has only the minimum amount of read/write access that it needs to do its job to limit the damage that a compromised node can cause. So do your due diligence and see if the "designed to operate in a trusted environment" argument applies to your scenario, but if I was the appsec engineer responsible for your product, you'd have have a hard time convincing me that it's safe to ignore the Principle of Least Privilege here.


Are there any reasons for Kerberos being based on symmetric cryptography? Kerberos is an authentication protocol that is famously built using only symmetric ciphers.

As a direct result of this, there are several attacks possible, such as

AS-REP Roasting
AS-REQ Roasting
Kerberoasting
Silver Tickets
Golden Tickets

While some attacks require specific conditions (e.g. AS-REP Roasting requires disabling pre-authentication), other attacks like AS-REQ Roasting cannot be prevented at all.

It seems odd to me to use symmetric cryptography for a task that just screams "Please use asymmetric cryptography for this!". Is there something I am missing? What are the reasons for choosing symmetric ciphers?

Full disclosure: I was the Program Manager overseeing Kerberos for a while, and am currently a developer actively working on it at Microsoft.

What you're describing is not strictly accurate. Kerberos as originally spec'ed does rely on symmetric crypto for authentication. However, there are widely used extensions to this spec that enables support for PKI authentication and defeats client *-roasting. Windows for instance uses the PKINIT extension for smart card auth and Windows Hello.

Additionally, the weakness is not that secrets are symmetric, but that the secrets are often user-generated which means easily guessable or they've chosen a weak cipher suite.  Switching to an asymmetric crypto-based protocol just moves the problem from "how do I generate keys" to "how do I store and protect keys". In practice both are equally difficult problems for different reasons.

Asymmetric keys also don't solve golden ticket-like problems. If you're in the position to steal the krbtgt symmetric secret, what stops you from stealing the asymmetric secret? Not a lot. If you're in the position to protect an asymmetric key, why aren't you in a position to protect a symmetric key? In fact many systems today use symmetric secrets for protecting these types of tokens, such as session cookies or refresh tokens because of the performance benefit. Making it asymmetric doesn't directly improve things (though app architecture could dictate otherwise).

Silver ticket problems do benefit from moving to asymmetric because a service would never need to know the private key, which reduces the likelihood of it leaking.

However, in doing so you give up a guarantee of mutual authentication. Symmetric algorithms have the property that because both parties know the secret there's mutual authentication (the system falls part when multiple parties know it). With asymmetric keys there's no guarantee the party that receives the ticket is actually who they say they are. You need to explicitly authenticate both parties now, which can be done by adding another asymmetric key, but now you have at least doubled the total number of keys required in this exchange. You're still stuck protecting a secret on both sides.

The alternative of switching to another protocol is also practically difficult to accomplish. There are systems that simply will never move, and the systems that will move will do so over many many years. This requires involving lots of standards bodies, software implementers, and companies, and convincing them all that  is best. That's not to say it's impossible or even a bad idea. Just that the effort required to do so and succeed is enormous.

Alternatively you can make minor adjustments to how Kerberos is used today and have Really Good (tm) security.

Ditch Passwords (smart cards, Windows Hello, FIDO, etc.)
Use strongly generated service account passwords (gMSA, etc.)
Disable weak ciphers (DES, RC4)
Enable compound authentication (armoring)


Are unbranded home security camera secure? I plan on buying a couple of cheap cameras for my home. I plan to put them just inside the doors like the laundry door, I won't be putting them in the bedroom or living room.

My major concern is how secure are they ? Can it be used to hack my wifi or devices on my network ? Is there a possibility of a backdoor where someone can see the video ?

These cameras are made in china. (I'm not being racist to chinese but there have been reports of some unbranded Chinese products that hack your wifi)

Here's an example of a camera: https://www.mydeal.com.au/wireless-1080p-hd-security-camera

My major concern is how secure are they?

Probably not very secure at all. Why would a cheap no-name wifi-web-cam be secure? The main development time/energy/money probably went into creating the desired functionality with little regard for security.

  Can it be used to hack my wifi or devices on my network?

Sure, it's always a possibility. Whether or not this occurrence is likely depends on what you mean by "hack" as well as the unknown specifics of the camera such as the platform, the os, the applications, the infrastructure, etc.


Are weak entropy sources worth it? I maintain an operating system that can be deployed to embedded devices with highly diverse capabilities. One of the aspects of porting the OS to a device is declaring the available entropy sources (including, but not limited to, dedicated TRNG peripherals) which will be used to seed the CSPRNG. The security goal of this part of the software is to ensure that the CSPRNG is seeded with sufficient entropy after each instantiation. (There may also be a way to save a random seed across reboots, but here I'm concerned about the case where no saved random seed is available, so the RNG is only seeded with entropy sources.)
The configuration mechanism allows sources that are considered “weak”. Weak sources are mixed into the entropy pool, but their contribution counts for nothing: they don't increase the counter that measures available entropy. The documentation suggests declaring the current time at micro- or nano-second resolution as a weak entropy source.
I'm considering removing the concept of weak entropy sources, and only recommending strong entropy sources. I can see qualitative arguments in both directions, but I don't know how to weigh those arguments.

Pro: even weak sources may be useful. If the adversary doesn't have access to the initialization time of the device, a fine-grained clock value could add maybe 30 bits of entropy, which is insufficient on its own but could help compensate a source that is a proper TRNG, but is not as strong as it should be (e.g. due to suboptimal temperature or voltage).
Pro: since the system expects the same amount of entropy from strong sources whether weak sources are present or not, there is no direct loss of security from including weak sources, so we may as well include them.
Con: any feature is added complexity, so for security the default choice should be not to have a feature. But in terms of system design, the cost is practically zero: a weak source is just a source that systematically returns an estimated 0 bits of entropy, whereas a strong source is one that normally returns 1 or more bits each time.
Con: Weak sources reduce testability. It's easy to detect if a system has no entropy by instantiating it twice and checking that get_random() returns different values. If a system has both a weak entropy source and a strong source, and the strong source is misbehaving, this is hard to detect by testing. For example, the infamous Debian OpenSSL PRNG seeding bug would have been discovered a lot faster if the PRNG had only been seeded from /dev/urandom, and not from the process ID as well.

Are there other important arguments that I've missed? On balance, are weak entropy sources worth it, or are they counterproductive?

You haven't clarified the device requirement for entropy, so I'll assume that it's to participate in some sort of secure exchange over an otherwise open channel.
I think you have actually hinted at a way of quantifying things in your question, where you mentioned that a high-resolution clock could contribute up to 30 bits of CS-entropy, but this not being enough.
We'll, if you know what protocol you're participating in (assume TLS 1.3), then you know the requirement exists for at least 32+32 (for the ephemeral client key and the client randomness contribution) and then another 12 bytes of high-quality entropy (for the nonce in the ChaCha20Poly1305 symmetric cipher).
(Visit Michael Driscoll's very helpful breakdown of TLS 1.3 https://tls13.ulfheim.net/ for more info.)
... so an observation in support of an argument for including weak sources: in the absence of a high-quality source of randomness, the device client can't contribute to the shared entropy in any protocol like TLS, that has some sort of randomised IV or forward-secrecy.


SSLStrip performs DOS I was trying SSLstrip on my Windows PC as a target since Internet Explorer seems to be the only browser vulnerable to this attack.

I deleted all my browsing history and when the site gets stripped to HTTP the browser just sits there waiting for the connection but never makes it, i.e a DOS of some sort. Is this a result of the site using HSTS; I though if the browser's history was cleared HSTS didn't work? Why does this happen?

And when it does work I get this error message :

exception.runtimeerror : request.write called on a request after request.finish was called

since Internet Explorer seems to be the only browser vulnerable to
  this attack.

That is the false assumption which is largely responsible of your situation because on February 2015, Microsoft already released  HTTP Strict Transport Security in Internet Explorer 11. It is clear, regarding the error message you got, that your IE version is 11 or higher.

  i.e a DOS of some sort

No, SSL stripping has nothing to do with DoS.

  exception.runtimeerror : request.write called on a request after
  request.finish was called

It is normal you got that error since you know the purpose of HSTS and which not not only makes your connection fails, but  can also, in case you attempt your MITM on other users, inform them (your potential victims) that they have been  tampered by a third party.

  And when it does work I get this error message :

Now you can guess you misinterpreted the events: since the error message by itself warns you that the connection failed.

Now, a question you may ask: is this the end of SSLstrip ? Luckily (or unluckily, depending on the colors you wear), there is an other opensource tool that uses an updated version of SSLstrip called mana. If you are running Ubuntu, Kali or any other Debian distro, you can install it by runnin:

  apt-get install mana-toolkit

So in addition to HSTS limitations, mana overcomes and tricks HSTS.


What is this kind of low-intensity, non-hacking attack on a web service? I am seeing for about 10 days now a bunch of EC2 machines (about 30, distributed in all regions) which are attacking a server of mine.

The interesting (or uninteresting, I do not know yet) fact is that

they target an open web service on a non-descriptive port (which was probably found through an earlier scan)
this port replies with a 200 to a HTTP request
the queries are only on the root of the URL ...
... which brings them an empty page

In other words, they are continuously doing a GET / on that web service.

It could have been a DDoS, except that

the number of machines is very limited and well defined
there are 4 queries per minute, all of them neatly grouped (within ~5 seconds) around the middle of the minute

So this not a DoS (the rate is insignificant), not a DDoS (beside the rate, the population is small), not hacking attempts (the request is stubbornly on one URL, I looked at the traffic and this is the only port targeted).

I will classify it as "rich (many EC2 machines, they may also use the free tier) but dumb not-sure-what" if nobody has an idea about what this is.

This sounds like the behaviour of an uptime service. These connect from multiple locations at a regular interval, and are designed to alert the server owner in the event of problems.

In this case, it looks like the server owner had set up such a service, and then forgotten about it, since the server didn't have any problems - the alerting service wouldn't send alerts unless there were issues, so it's easy to forget about them.

Answering question in comment: why perform extra checks? Several reasons:

Verifies that an issue exists on the target server, rather than on the testing server
Allows for geographical testing, by making requests from multiple locations
Allows for more complex tests, such as response times, whilst avoiding network problems which might affect individual servers
Ensures that the uptime service itself doesn't suffer outages from single servers going down!


Tracking an IMEI or device from an IP address If I access a website and complete an online form using 3G on my iphone, can my actual phone be traced back to the IP address?
For example if the website can see what IP address was used, how easy is it then to match the IP address to my IMEI

No, the website cannot, but the phone company can. They will know which account was using the IP and what IMEI is used with that account.


Exception handling in multi-tier applications Error and exception handling in web applications can introduce security issues, often in the form of denial of service (i.e., when a service crashes because of poor error handling) and information disclosure (i.e., when an exception containing sensitive details about the system is propagated to the user/attacker).

To combat this, the system needs to fail gracefully, revealing little details about the failure and recovering as much as possible. When it comes to exceptions, managed languages have simple and well-understood mechanisms for exception handling. However, throughout my research I have failed to find advice on how to construct a proper exception handling mechanism in modern web applications that include several layers of logic between the database and the client applications.

For example, the Spring framework has the controller (that provides the APIs and handles HTTP requests), the service (that contains the majority of the business logic) and the repositories (that handle communication between the application and the database). Additionally, the service can interface with utility components and modules that offer various functionality (i.e., file access, algorithm calculation). The following data flow diagram illustrates this architecture.

By examining the origin of exceptions, we can see that the Calculation Engine, Repository, and File Access Utility can (potentially) reveal some details about the system, should an exception be thrown when interfacing with the different datastores (i.e., information about the SQL database, knowledge base schema, etc.).

The questions then becomes, where should developers handle these exceptions, and reduce the risk to both information disclosure and denial of service?

An approach that seems suitable for me is to handle exceptions as they arise and wrap them into application-specific exceptions. The parts of the application that have data flows that cross a trust boundary (e.g., to the file system, the Internet) should sanitize all exceptions by wrapping them into "more friendly" custom exceptions (created by the developers) to stop any risk from information disclosure being propagated further, as well as to localize any component failure.
The internal components should then know how to handle application exceptions more suitably.

The main drawback of this approach is that the exception handling mechanism is more complex, as it requires the introduction of application-specific exceptions for each category of native (and applicable) exceptions.

Does this approach have any other pros and cons, and is there an alternative design that handles the balance between security and workload better?

Voting to close this as it is not a question about security. It is a question about software engineering and architecture:

The best place to handle the exception is as close as possible to where the exception occurs - the separation of functionality is all about abstraction - the remote higher levels are separate because they don't know about what is going on in the lower layers hence they cannot provide meaningful messages about the event not handle an automated response. Having said that, it is essential to track the (potentially distributed) transaction in order to

accurately log the connection between cause and effect
resolve data issues

And that means the entry point has a very specific role to play in case exceptions occur; it needs to tag the transaction with a unique identifier propagated with the sub component messages.


Can an error page (like 404) served without X-Frame-Options be exploited? I'm checking some HTTP headers in the server response.
I get a 404 error page. Could in some scenario an attacker leverage a missing X-Frame-Options header in a 404 page?

There is nothing inherent in a 404 response which protects against attacks like clickjacking (i.e. what X-Frame-Options tries to address). While most response bodies send with 404 are likely not vulnerable to clickjacking in the first place due to the shown content (i.e. just some more or less fancy error message), browsers do not add extra protection by themselves just because the response code was 404.


it is possible to decrypt HTTPS with the (private, public) pair if it uses DHE? Assuming you have a PCAP file with HTTPS traffic and having the key pair (private & public), it is possible to decrypt the traffic if it uses Diffie Hellman Ephemeral? Using openSSL lib for example.

As far as I know the answer is no because DHE generates a new pair for each connection, so it do not uses the key that we put in our apache configuration, isn't it?

My task is, knowing the private and public keys, decrypt the traffic. Of course there are many CipherSuites. I'm studying the limitations of this objective.

When TLS/SSL handshake starts, the first step is, server is authenticated using a private key associated to the server's certificate. In a 2nd step, client and server exchange a session key used to encrypt the payload of the connection. The session key is used for one session means when the session is closed the same key can't be used to encrypt the traffic of another session. Now the problem is SSL/TLS often use RSA cipher suites in which the session key is derived from private key. So the session key can be calculated in future if the underlying private is known.

DHE and ECDHE provides Perfect Forward Secrecy(PFS), means session keys are not derived from private key. So the attacker can not decrypt the traffic even when he has the private key used in the session handshake.

In DHE(not DH) the session keys are calculated using the Random Numbers.

Conclusion

You can't decrypt the traffic using private key when DHE or ECDHE is used.


TLS connection to untrusted server - client reaction for dropping connection standardized? I played around with a man-in-the-middle proxy tool and connected different smart phones to it. As the proxy uses a self signed certificate the tested smartphone apps did not accept the presented server certificate.

The interesting part (from my perspective) was that different smartphone platforms used totally different messages and strategies for making sure that the TLS connection can not be established.

Some just sent a ALERT message with description bad_certificate(42) or certificate_unknown(46). Other phones just continued the handshake but later the key exchange deterministically failed.

I found especially the last case interesting as it is unclear how the client force the handshake phase to fail and if an adapted server/proxy may still be able to "save" the handshake phase and establish the connection...

Are the actions a client should perform somewhere written down in an RFC for dropping the connection in case an untrusted certificate was detected?

If no, does somebody knows what mechanism is usually used for willfully sabotaging the TLS handshake phase?

X509 certificate validation is covered in RFC 5280.

Look at section 6 (https://tools.ietf.org/html/rfc5280#section-6)

  Conforming implementations of this specification are not    required
  to implement this algorithm, but MUST provide functionality
  equivalent to the external behavior resulting from this procedure.


I saw a weird url in my logs, dunno how to proceed I'm by no means a security expert. I own a very small personal site which I wrote in php mostly for practice and all that.

I noticed a weird url call in my logs

process.php?d=MV0f+F6R+6Nn/B4VDh1FRJ9fSEjpPw==&b=1

I tried following that url myself but it doesn't go anywhere but a 404.

I don't want to nuke my site from orbit.
What are some steps I can take to at least identify if anything has actually happened.

The site is written in symfony 4(for whatever it's worth)

This isn't a sign of anything to be concerned about.

As a general rule of thumb you should expect to find all kinds of strange URLs in your logs.  This is the normal "background noise" of the internet.  In essence, shortly after a server becomes accessible to the internet, automated bots will automatically start scanning it for any number of well known security vulnerabilities.  In short, if you were to nuke your server from orbit anytime something strange showed up in your logs, you'd have terrible uptime.  99% of the time the exploits that are being attempted are not even applicable to your particular technology/framework.

In this particular case this doesn't even look especially harmful, although it is possible it is targeting some vulnerability that isn't the usual SQLi or XSS vulnerability.

I would say the main take away from this should be that good application security is very important on the internet, but you certainly don't have any reason to worry on the basis of just this.


What are these unknown visits to my private, unlisted webpage? Greetings this is my first time to post a question here so please be forgiving if I do something wrong or did not follow proper etiquette.

Here is my situation:
I created a private, totally locked down, unsearchable, and password protected account and photo gallery on a popular website for hosting photos. The only way this gallery could be accessed was with a private URL and then you would still need the password (its a strong password) to see the photos. Then I sent the private link in an email to ONE person from my gmail account to their yahoomail account.

I am tracking visits with Google Analytics and I know almost all the visits, they are either my own or the person I sent the link to. Except I cannot explain 4 visits from Russia and how this person was able to find my gallery.

I was able to extract some relevant information from Analytics which I listed below. From this information, I can assume that these visits are all from the same computer, yet from 2 separate locations in Russia. Something I can't explain is why all the normal (mine and my friend's) visits have Hostname listed as the URL of the website where I posted the gallery, however, these unknown visits have Hostname listed as co.lumb.co.

Here's the info, I broke it down by city, first city is Samara and second one is Moscow:

> Location: Russia - Samara Oblast - Samara
> Date/Time: Dec 4 - (1st) 5:28am, (2nd) 12:28pm
> Sessions: 2 (1 New and 1 Returning)
>
> Aquisition: Referral
> First Source: ilovevitaly.com
> Second Source: forum.topic57207714.darodar.com
>
> Page URL: /
> Hostname: co.lumb.co
> Screen name: co.lumb.co/
> Second Page: not set
> Exit Page: /
> Exit Screen: co.lumb.co/
> Page title: (1st visit) Co.lumb CoOrdinates yoU (2nd visit) Co.lumb
>
> Service Provider: cjsc company er-telecom samara
> Network Domain: ertelecom.ru
> Language: ru
>
> OS/Browser: Linux i686, Firefox 33.0
> Screen Resolution: 1366x768
>
> ---------------------------------------------------------------

> Location: Russia - Moscow - Moscow
> Date/Time:
> 1st visit - Dec 6, 3:37pm
> 2nd visit - Dec 9, 9:36pm
> Sessions: 2 (Both Returning Visitors)
>
> Aquisition: Referral
> First Source: forum.topic57207714.darodar.com
> Second Source: forum.topic57207714.darodar.com
> Page URL: /
> Hostname: co.lumb.co
> Screen name: co.lumb.co/
> Second Page: not set
> Exit Page: /
> Exit Screen: co.lumb.co/
> Page title: (1st visit) Co.lumb (2nd visit) Co.lumb
>
> Service Provider: hosting telesystems network
> Network Domain: (1st visit) hts.ru, (2nd visit) ht-systems.ru
> Language: ru
>
> OS/Browser: Linux i686, Firefox 33.0
> Screen Resolution: 1366x768

There are multiple possible explanations.

The first one and the most likely (especially if the secret part of your url is not that long), is plain and simple bruteforce. If you're on a popular website, it really shouldn't surprise anybody that they are being scanned in order to find some juicy hidden urls. Given the fact that they are hitting your page with another hostname, I'd guess it's a pretty credible possibility.
The second one is that since you communicate with third parties on your page, your url was eventually leaked & sold (by google analytics, by the website host, etc).
The third one is that at some point, either your connection to the website or your email has been sniffed. In both case, your website eventually ended on a list of urls to scan.


REMME: Does the blockchain offer a real advantage here? Remme is a startup, which seeks to replace passwords with an app. If you want to login on a website, you do this via an app, instead of typing. Similar to the login link logic we know from Slack. So far so good, this makes total sense.

The whole thing however "runs on blockchain" or utilises a blockchain somehow. The argument is, that this way there is no centralised server to attack.

Does this argument have merit?

REMME

Note that this is not a scientific review of what they do.

From the technical side they are essentially doing certificate based authentication (i.e. similar to client certificates in the browser) only that the certificate and revocation information are stored in a public Blockchain (actually they use Bitcoin in the current version) and that they thus try to avoid having a central CA. This idea is not that bad by itself and is actually not that new either.

But there are some signs on the companies site which look suspicious too me:

Their website is full of claims like "unbreakable", "eliminating the human factor from the authentication process", "perfect". I'm very cautious when someone has such claims when talking about security.
The "As Seen on..." sounds more like TV advertisement but not like a serious security product.
Their white paper makes interesting claims like "Various parties (including Google) have tried to solve those issues, but without
success[2]" -  where [2] is simply a link to the web site of the certificate transparency project without any explanation on why this project does not solve the issues. But of course it sounds awesome to claim that they've solved a problem Google could not solve.
As can be seen from their white paper the way they work was changed multiple times within the short time they exist - which does not provide much trust in that they already know what they do. And in fact several more changes are already planned.
And many more. For example their white paper is also a mix of tiny details for specific technical parts one one side and then planning of the companies future (Q1/2018: public sales phase, Q3/2018: sales office in London ...) on the other side, which is just strange for my understanding what a white paper should be. Interestingly they refer in the white paper itself to version 1.0 of the paper released in Q3 and version 2.0 in Q4 2017 - only that the white paper itself says clearly version 0.2, a version number which probably more matches its immature state.

Based on this I would argue that this is more an attempt to make money from the current hype to Blockchain, Bitcoin etc than a product I would trust.


Is it more or less secure when an entity shares it's security procedures? Right now I'm doing a work term through my school and they want me to write a report on something I've worked on. They are really serious about "proprietary reports" and reports requiring destruction after they've been marked. I'm planning to write about becoming PCI compliant and my boss tells me not to worry about marketing it as a "proprietary report". My question is, does making security details public increase or decrease security? I can't find the wikipedia article I read this on but after 9/11 a report found that agencies such as the FBI didn't share information enough, each agency felt that they worked to obtain the information and wanted to keep it confidential and to themselves which ultimately was counterproductive. Can it be seen as the same, the more people who look over a PCI implementation the more likely someone can spot a weakness?

In general, the consensuses within the security community is that disclosing security practices (aka, transparency) leads to improved security. Transparency has many benefits:

It gives you motivation to do security right. Sometimes doing the right thing for security is annoying or costly, and having no one to account to makes it tempting to not do it the right way. When everyone can see what you're doing, you have more motivation to do things correctly.
It means that more people can scrutinize what you're doing wrong. An open system can be analyzed by many more people who can suggest improvements. In general it is assumed that motivated attackers will find these weaknesses anyway, so the more honest people that can see the weaknesses the more likely it is that the weaknesses will be reported in a timely manner. The alternative is living in bliss and only knowing about a problem once the attacker has exploited it.
It means that you are confident in your design. Security is hard to do well, and many people hide their security practices because their practices would appear bad. Making it open shows that you are not only comfortable with them, but that you are willing to fix problems that arise.
It allows others to learn from the things you do right or wrong. This has little direct benefit for you, but it allows others to benefit.

That said, transparency is really only beneficial if you plan to respond to security problems. If you aren't planning on it, transparency can cause problems because you make the attackers work less hard to find vulnerabilities.

PCI is a public standard that a lot of people conform to, so it's unlikely that very many of the details related to your implementation will be very unique. It's possible your boss doesn't think that information about proposed PCI compliance would be harmful.


Switching operating systems for security An operating system is a very important vector in an attack. If someone wants to hack your personal system he needs to know the operating system to know which exploits to use for example.

But if you switch which operating system you use (e.g Debian → OpenBSD → Mint → Arch → FreeBSD → ...) every week; do you become harder to attack?

Advantages:

The attacker would have to search for exploits each time again
Your system would be always up-to-date (newly installed)
Most malware would get deleted at each new install
If someone wants to infect you, he has to adapt code, compile, and infect you in one week.
You're harder to fingerprint
...

Disadvantages:

Security- & Anonymity configuration needs to be configured each time again (error prone: e.g configuring Tor wrong)
If you switch to a weak protected operating system for a week, you're very vulnerable for that week. Kind of a Russian roulette.
Lost of data each time (back-ups from old system can contain previous malware)

I know that when you switch from Linux distribution A to distribution B you still have the same kernel, but yet A can have vulnerabilities B doesn't have. The kernel is often adapted and not the only software in an operating system.

So, is it a good security practice to switch operating systems often considering the following cases separately:

Just normal use (browsing and downloading stuff)
To stay hidden and anonymous
If you know someone wants to hack your system

Would switching operating systems be more secure in one of these cases? Why (not)? Would it be more/less secure than using an updated LiveOS?

Anything else?

tl;dr Is switching operating systems every week a good security practice?

Absolutely not. Using more operating systems simply makes it more likely that you'll use an insecure system, and the attacker only has to wait until he gets lucky. In your example, you specify FreeBSD. Believe it or not, FreeBSD is really not that secure. It does not even have userland ASLR, which is considered one of the most basic of security requirements. If I was going after you, I would rejoice in the fact that you are jumping between systems. The same applies if you have a 0day exploit for a given system. In your very example, you specify Debian. Due to the Debian kernel configuration being so liberal, it enables an option which activates certain insecure legacy subsystems. I actually do have a 0day for it, but it does not work on the other systems you mentioned, as far as I know.

You say that the attacker would have to search for exploits each time. They don't, they just have to wait until you switch to a system that they can exploit. It's as simple as that.

In general, stick to one system. You are playing Russian Roulette each time you switch. Would you rather pull the trigger once, or many times? I would rather take a chance once, than take a chance over and over.


SQLMAP injection point I'm busy testing SQLMAP on a custom app I wrote, but SQLMAP is not detecting the injection point.

For example, http://127.0.0.1/index.php?id=10-1 displays the content of id=9. But SQLMAP is not detecting the injection point under ?id.

Has anyone successfully exploited such an injection point?

Make sure your URL does not contain any SQL injection snippets. The URL should be valid. Also try using * on the parameter like so:http://mysite.com/test.php?id=*
Make sure your request is a valid GET request and not POST. Mixing those up can cause to miss your target.
Try using the -r flag with an intercepted request you've saved from something like burp. This way I know I'm not missing anything important. Do this if you want to test POST method requests.


secure mysql against data tempering? As stated in the title, how do I secure mysql against data tempering? I have been searching the internet for a solution but did not find one that fills my needs.

Let me describe my problem, assume I have sensitive information in a table, and a hacker can easily alter the data if he have the access to my database.

I know there are some solutions where you can hash the values and use checksums, but that can also be regenerated and manipulated by the hacker.

Even encrypting the data won't be enough, because that means that the key must be on the server which can be accessed by the hacker.

Now assume the hacker has access to my cpanel account, server (source code) and database, how can I make sure that the data is not tempered with?

I want to ensure the integrity of my data regardless if a hacker is a random person with limit access or a insider with alot of access.

Is it maybe possible to do something so solid like blockchain with mysql?

In general, you can't be absolutely sure that there have been no changes to your data, especially if you're looking at the scenarios where an attacker has access to your application code. In that case, they can probably do anything which your application does, and you can't tell if they have once they are done.

However, if you work on securing access to your systems, and monitor any unexpected access to them, you can get a pretty good idea if something has changed.

For example, if only your application server can connect to your database server, with a limited privilege user, you can immediately reduce the risk of someone being able to edit the database contents - if they got the code in some way which didn't involve compromising the application server (perhaps from an old backup file), they'd still need to compromise the application server to be able to do anything to your data.

You can also implement things like offline auditing - store each day's audit logs on a read only system, as well as on the database system, and compare them on a regular basis. If someone can compromise both copies, you've probably got bigger problems.

Going to even more extensive levels, you can have devices which allow very limited access to data, and all access is logged. Banking systems sometimes take this approach, but it's probably too expensive to implement for any but the largest e-commerce sites.


How to encrypt data in frontend/backend with a key that is not stored anywhere and is only known to owner? I have read bunch of answers and tutorials on how client side cryptography is not a good idea because of many reasons listed mainly in Javascript Cryptography Considered Harmful article. Some facts

The app will be using HTTPS
There will be server and client side validation
There is no link between user's password and the following scenario
The server side is a RESTful web services (no session whatsoever)
The backend issues JWT to users
The backend might allow both user/password as well as oauth (i.e. fb, twitter, etc.)

What do I want to encrypt in client side?

The user will be inputing some personal information (i.e. name, address, phone number) via a frontend app (i.e. Vue.js, Angular, React, etc.)

How do I imagine this is going to work?

The user selects fields (i.e. personal information bits and pieces), and then clicks encrypt. The user will provide an encryption key. The frontend will use some js crypto library and encrypt the information and replace them in the DOM and inform the user to backup the encryption key.

How do I communicate this information to server?

The frontend will make a HTTP PUT or POST request with the personal information (whether plain/text or gibberish) to the server. The server don't care about incoming data (i.e. except for sql or other forms of injections) and store it in the database right away. This request will not contain the encryption key but, might contain a flag/s to specify that which fields were encrypted.

How to decrypt?

When the user requests for the information, the backend returns whatever there is in the server as is. The information if encrypted will be displayed as gibberish to the user. Using flags, the system will give them decrypt option and clicking that would ask them to input encryption key and does the decryption locally.

Ultimate purpose?

First of all, every effort will be taken to make sure that server and database and everything is bullet-proof but, if for some reason the server is hacked then the hacker would end up with loads of information that is tied to gibberish personal information.

The ultimate question

Reading through internet, cryptography in Javascript is strongly discouraged hence, my questions

Taking into account the scenario and requirement above, what are the risks imposing the above implementation?
Is there an approach that you recommend, where only the user is in control of the key, not stored anywhere?
If I were to encrypt this information in the backend, how can I communicate the encrypt key safely with the user? Maybe encrypt the information using key xyz and then provide a secure link to the user to click and view the xyz encryption key, ... ?
What other suggestions are there for front-end, backend-based encryption?

I would like to give the user's the confidence that only they know how to decrypt the key. How can I achieve that in a more efficient way? Without having to store and manage the encryption key?

Update July 17, 2018

Based on the accepted answer, I wrote a medium post on how I implemented the solution here is the link https://medium.com/@rhamedy/encryption-decryption-of-data-based-on-users-password-using-pbkdf2-aes-algorithms-592f8c1bb79a

Upon initial user registration, generate a strong encryption key using a cryptographically secure pseudorandom number generator; this key will serve as the Data Encryption Key (DEK) to encrypt the user's data. But you don't want to store the DEK anywhere, at least in its plaintext form. You want to derive an encryption key from the user's password, using a key derivation function such as PBKDF2. Use the key that you derived from the user's password (the Key Encryption Key, or KEK) to encrypt the DEK. Then you can safely store the ciphertext of that DEK in the database.

Each time the user subsequently logs in, you must not only authenticate them but also derive the KEK all over again from their password, then use that derived key to decrypt the ciphertext of the DEK. Store the DEK in the session on the server, not in the client. Now you're in business; you can use the DEK to decrypt information on the server side for as long as the session is active, but not after the session expires.  This has the advantage that the user doesn't have to stare at some gobbledegook ciphertext. You can instead have a placeholder container DOM element saying "encrypted" or something, and maybe listen for clicks on that element, which then invoke a call to an API endpoint, which grabs ciphertext from the database, decrypts it on the server with the DEK that you stored in the session, then returns it to the client as plaintext right then-and-there, where you can inject it into the UI for the user to see. No sensitive data need be stored on the client, nor is it necessary to perform any cryptographic operations on the client. This approach also has the added benefit that the DEK can stay constant over time. If the user ever changes his password, just derive a KEK from the new password, and re-encrypt the same DEK as before with the new KEK, and store the new ciphertext of the DEK in the database as before.


What security does nginx provide between server blocks? What security does nginx provide between server blocks?

Here is an example scenario. Say I have two server blocks configured with nginx. Each serves up a web application to authenticated users. I am worried that if one web application is compromised that it could be leveraged to gain access to the other web application.

For example, say one web application has a remote file inclusion vulnerability which allows the attacker to get a shell. That shell would have the privileges of the web server (www-data). With those privileges, the attacker could start reading files from the other web application, right?

Is there any additional separation one could configure into nginx server blocks for added security in this scenario?

There's no isolation (from a security perspective) between server blocks -- server blocks only exist as a namespace for related directives.  Nginx can only have a single user configured, as it becomes that user just after binding to network sockets (which requires root to bind to ports < 1024).

What you can do, and what I have done in the past, is run the applications as different users.  You don't specify what language you're using, but for example, I run uwsgi workers, and run them under per-application users to isolate my applications.  The sockets need to be read/write www-data (I usually do this via group, so the unix socket for the app server ends up as appname:www-data, mode 0660) and static files need to be readable by nginx (if you want to serve static files directly).


In-office Flask app on port 80 - is it safe? The title says it all; I'm just serving data to coworkers as a courtesy via a series of single-page apps that I basically consolidated under Flask, serving Jinja templates.  Presently, I have Apache running, and I just drop static HTML files in the path.  But this was before employing Flask or a template engine and I'm unwilling to let it grow to the point that it becomes harder to maintain as a bunch of static HTML.

So in order to make the switch, I can either set up Apache to forward requests to my Flask app, or (b) just turn off Apache, tell my Flask app to app.run(host='0.0.0.0', port=80) and then sudo python myApp.py, done and done.

So is this unsafe?  I can't speak to the level of security that our sysadmin employs to prevent outsiders from trolling around our local network, except that "it exists".  Our LAN is regarded as inaccessible from the outside, but honestly I don't know anything about this kind of thing.  Seems to me that if I can post on Stack Overflow from this computer, Someone Somewhere can see my app running and do Bad Things.  I also understand this to be the less preferred practice, especially when something is supposed to be publicly available - but again, I'm just in the office here, and if I don't have to goof around with Apache .conf files then I'm happy to leave them alone and just turn Apache right off.

Am I setting myself up for a giant security fail, or is this fine within this context?

We can't verify the security controls imposed by your application but just a few remarks regarding your configuration:

If you are requiring a username and password, you should require SSL. This certificate can be signed by your company's CA or an official CA. This is to make sure your employees credentials (or yours) stay secure.
sudo myapp.py => Big no no here, there are generally no good reasons to run your app as root. You should create a user which cannot login and run it under his name. This user should only have just enough rights to run your application and perform certain file manipulations (for instance write to a certain log folder/file) and nothing else.


Server certificate authenticity validation process I was reading this article about how the Server Authentication is being done During SSL Handshake
https://docs.oracle.com/cd/E19693-01/819-0997/aakhc/index.html

I do understand everything but I have a specific question about the point number 3 when it says

  if the CA certificate’s public key doesn’t correspond to the private key used by the CA to sign the server certificate, the client won’t authenticate the server’s identity.

How using only the public key we know that this public key does not correspond to the private key? do we use the public key to decrypt the signature and make sure it matches some data sent along with the signature?

Thanks in advance

Simply put, the CA creates a signature with their private key. The public key, among other information, is distributed as certificate together with your operating system.

Should the public key of the CA (so the certificate you already have on your machine) not correspond to the private key used to sign a certificate, the signature would be invalid.


What is an indicator of compromise? I'm struggling to understand what is an indicator of compromise.
I found different definitions on the web but I still don't know.

The definitions I found are:
1 - Something (file, network connection) that indicates a system has been compromised.
2 - An information about compromission

Short version: IOC basically are any piece of data that can be considered unsual on a system or network that could serve as a fingerprint of an attack or maybe an infection.

Example:
One of the ways malware writers establish persistence within an infected host is through registry changes.

Imagine that malware.exe ALWAYS create a folder in C:\Tmp\WindowsAdmin666, so, if you have that folder, this could mean that you're infected, this is an IOC (Suspicious Registry Or System File Changes).

Long version:
As "Digital Guardian" says, Indicators of compromise (IOCs) are “pieces of forensic data, such as data found in system log entries or files, that identify potentially malicious activity on a system or network.”

Indicators of compromise aid information security and IT professionals in detecting data breaches, malware infections, or other threat activity. By monitoring for indicators of compromise, organizations can detect attacks and act quickly to prevent breaches from occurring or limit damages by stopping attacks in earlier stages.

Indicators of compromise act as breadcrumbs that lead infosec and IT pros to detect malicious activity early in the attack sequence. These unusual activities are the red flags that indicate a potential or in-progress attack that could lead to a data breach or systems compromise. But, IOCs are not always easy to detect; they can be as simple as metadata elements or incredibly complex malicious code and content samples. Analysts often identify various IOCs to look for correlation and piece them together to analyze a potential threat or incident.

Examples of IOC include unusual network traffic, unusual privileged user account activity, login anomalies, increases in database read volume, suspicious registry or system file changes, unusual DNS requests and Web traffic showing non-human behavior. These and other unusual activities allow security teams monitoring the systems and networks to spot malicious actors earlier in the intrusion detection process.

If theory was confusing, then a good example might help to understand IOC, this document is from SANS: Using IOC (Indicators of Compromise) in Malware

Hope this helps.


PHP registration script, how to check if request is coming from a credible source I've got a php registration script, that just takes all the data as a post request. I've got another page which sends that data to the script using jQuery ajax. How can i be sure, that the request came from that page, and not a spammer that would just send post requests to that script. I thought maybe using a token that's in the data sent by the page or a cookie, but both would be easy to discover.

Fundamentally, you can't.

Because the user has all the code necessary to communicate with you on his device (I.e. JavaScript), he also has the best possible Algorithm Description Document (I.e. JavaScript) one could ask for.

The only way to protect the code is to run it on the server... But this means that every request must go through the server, not just the "valid" ones from your script.

All you can do is raise the bar of complexity.

For example, if you were to hash (e.g. SHA256) the contents of the JavaScript code used to generate the request and all the data in the request and submit that with the request, you could have basic validation. This validation is easy to crack because all a user has to do is figure out what the hash of the JavaScript code is and do the hash themselves, but it makes it a little bit more difficult.

Another option, as mentioned in the comments, is to use a captcha.

Another option is watching source IPs or patterns in the requests.

But. fundamentally, there is no way to validate that the user is running your code vs their own code on their own device.


Is it possible to steal money directly from the systems of a big bank? Sometimes I imagine: My money in the bank is just a floating point number in a mainframe's memory... So, if I just change 1 bit, I will win a lot of money...

The most common way to steal money in banks today is to just ask people for their account information and credentials, through fake e-mails or websites.  However, this would seem to leave a fairly high chance of being identified if the victim catches on.

Alternatively, are there more anonymous ways by which one might steal money directly from the bank's servers?  Or, is this virtually impossible to the point that the only real weakness lies in the customers?

Is a hack like this only possible in Hollywood movies, or can it really be done in reality?  Are there any known cases of this already having happened.

Each transaction needs an audit trail - numbers need to come from somewhere - and bank systems have these checks in place. Are they perfect? Almost, but enough to make it easier to look for other attack vectors, like humans.

Did I mention that I was in jail in a far away country and I need you to wire me money for bail?


Can I be identified across different access points to same ISP? The ISP I use at home also provides access points in cafés etc. Can they, for example with my MAC address, match my identity when I'm using one of these access points to when I'm at home? And what steps would one take to avoid this?

Identification via MAC address is only possible, if your ISP can "see" that. MAC addresses are only seen on the client that are in the local ethernet collision domain, i.e. if they're on the same switch (simply put). This, of course, includes the router that acts as a gateway.

So, if at home you have a router that your ISP can't access, your MAC can't be seen beyond that router. At a public access point, which acts as a router, it can be seen by the owner of that AP - likely that ISP.

That being said, your ISP is likely to be able to recognize you in different café's, but not at home. In order to avoid this, you'd have to spoof your MAC, which is not easy and requires root access.

That much about MACs, someone who wants to identify you is very likely to use some other kind of identification that can be tracked across routers. Cookies, browser fingerprinting, just to name two. There're more than that and it's hard to counter all of them.

One thing I'd like to add:

Though tracking by ISPs is an issue, it's not the kind of tracking that'd worry me most. ISPs are usually specialized on providing you internet access. That's probably because the scope where an ISP can track you, is always limited. As soon as you're in another country or simply logged in to a friend's Wifi, your ISP has little chance of seeing your traffic at all.

On the other hand, if you have, say, a Google or Facebook account that you use across multiple devices - which most people do and of course they're always encouraged to do so, it's much, much easier to use that information for tracking you - and that's only the tracking that's officially done and most likely legal. There're many more trackers out there that have at least a questionable legal status - at least in some countries - and while you actually can refrain from using Google or Facebook (though avoiding them completely is difficult), it is even harder to avoid trackers that you may not know or think of.

Remaining completely anonymous on the internet is a very hard thing. TOR may be a good choice against just about anything but the NSA, but there're issues, too, and you have to know what you're doing.

Yet one more thing:

Most trackers do not know who you are. Usually they do not care. They're not going to write you a letter, so they don't need your address - letters are too expensive anyway. Same thing for phone calls. The police may look for that if they think they have to, but usually that's about it.

For a tracker it's enough to know something like that: "This person - likely male, probably married with an annual income somewhere around $100.000 has been searching the net for information about pregnancy tests. Therefore he might be interested in buying those as well as baby toys, baby clothing, baby insurance, maybe a bigger car and so on, so if that person loads one of our advertisements, it might be a good idea if it's from one of those categories. Since he lives somewhere around Syracuse, N.Y., we may also add some stores for baby supplies from that area." Try it. Google those things a bit and watch your banners miraculously change. It worked in my case. :)


main reasons to disable TLS 1.1/1.2 What is the security risk of not disabling TLS v1.1/.2 ?

I have multiple websites on Cloudflare

Most websites intended for a general audience will want to select TLS versions based on security and browser compatibility. If you have guarantees that the clients used to connect to your website will be reasonably up to date, you may be able to depend on TLS1.3 alone.

The optimal configuration for your website will depend on a number of parameters, and the configuration will need to change over time as support for stronger protocols and ciphers is added to browsers. Likewise, you will want to disable less secure protocols and ciphers as vulnerabilities are discovered or they become disused.

Security Considerations

Newer versions of TLS provide fixes for known vulnerabilities in older TLS versions.

Specific vulnerabilities in TLS1.1 have already been discussed. For instance, a countermeasure to the Lucky13 attack is to use AEAD ciphers which became available in TLS1.2.

TLS1.3 removes support for a number of weaker ciphers and hash algorithms while adding stronger ciphers.

Compatibility Considerations

At this time, TLS1.3 is supported by the browsers of ~81% of global users, which is likely not enough to rely solely on TLS1.3.

You will likely want to additionally enable support for TLS1.2, which is currently supported by over 97% of global users. Depending on the specific demographics and requirements of your websites, you may want to disable support for TLS1.0 and TLS1.1 at this time (as many websites have already done).

Client Support

According to Can I Use, current global support as a percentage of users (as of January 2020):

| Version | Global Support |
| ------- | -------------- |
| TLS 1.0 | virtually all  |
| TLS 1.1 | 97.43%         |
| TLS 1.2 | 97.35%         |
| TLS 1.3 | 81.08%         |

Most popular browsers are phasing out support of TLS1.0 and TLS1.1 in 2020. (Source)

Server Support

Server support, as measured by Qualys SSL Labs (as of December 3, 2019):

| Version | Server Support |
| ------- | -------------- |
| TLS 1.0 | 63.4%          |
| TLS 1.1 | 73.7%          |
| TLS 1.2 | 96.2%          |
| TLS 1.3 | 17.0%          |

Many websites have already disabled support for TLS1.0 and TLS1.1. Some users with outdated clients that do not support TLS1.2 are likely receiving error messages when viewing such websites.

Other Notes

Newer TLS versions also add features that you may want to take advantage of.

TLS1.2:

HTTP/2: TLS1.2 is the minimum TLS version for HTTP/2, which provides additional features to speed up page load time.

TLS1.3:

Faster handshakes: TLS1.3 will reduce latency in establishing a secure connection.
Forward Secrecy: In TLS1.3, all ciphers support ephemeral key exchange. This helps to maintain security of previous connections even if your server is compromised (or, in this case, your CDN is compromised).

For optimal security, you will want to tune additional parameters for your websites. Qualys SSL Labs can help you discover and tune these settings for additional security. To name a few, consider configuring HSTS, downgrade prevention via TLS Fallback SCSV, and forward secrecy. You may not be able to control all of these settings via your CDN - some may need to be configured on your servers.

Also, do not neglect the TLS configuration of your own servers as your CDN will establish an independent TLS connection to your servers.


How can spoofing a certain MAC address enable sending probe requests that I was never connected to? I was wondering how could my computer that uses a spoofed MAC address be sending probe requests for APs that I was never connected to?

Note:- The other computer with the original MAC address was shut down.

My understanding is that your OS is doing what is called an active scan: periodically sending probe requests to discover the AP's around it. The MAC address or the history of your connections is not relevant in that case.


Encrypting the API response in a single page app I am building a single-page(React-Redux on FE, Rails-API BE) application which makes a bunch of REST API calls to get certain information for logged-in users. Some subset of that information (categorization database) is more confidential than other information. Our aim is, to make it as hard as possible for that data to be easily gleaned from the API response or be scraped.

Based on my research, I understand that there is no method which makes it 100% possible to secure the data but I would like to make it as hard and frustrating as possible without negatively affecting the UX. We are also more concerned about the fact the information is essentially plain JSON when it comes from the server to the client which is far easier to exploit than scraping (since the UI in this case isn't the easiest to scrape).

So far, based on my research, it seems like I should do the following -

Use TLS/SSL for API calls that prevents man-in-the-middle attacks, and encrypts data in-transit. But this doesn't solve the problem of a malicious end-user.
To do that, we are going to do some rate-limiting on the API, and we can also temporarily suspend users/scrapers who are show up as 'bots' in the logs (since they are all logged-in). But that can be defeated just by malicious users appearing as more patient users.
The best thing, it seems that I could obfuscate the API response in two ways:

Obfuscate response keys or use which doesn't give away data as easily.
Send encrypted response from the server which javascript decrypts using a key which itself might be obfuscated in the code. This way, the data wouldn't be visible in the Developer Tools or to anyone else making the API call.

So, my question, is the last point above (the second point in (3) encrypting responses) an effective way to achieve my goal? And if yes, what are some things I should keep in mind for the same?

While I understand that none of these methods are foolproof, I would like to better understand the best practices for such use-cases. Any thoughts or ideas would be much appreciated!

Thank you!

Your API should check to see who is making the call and perform any sort of restrictions on the server side.

The way to deal with this is to implement server-side authorization and mitigate against insecure object reference and function level access control.  These should be standard anyway.

If your API returns information you don't want the caller to be able to see, you implemented the API wrong.  There is nothing you can do to protect the data at that point as the end user can simply monitor the network traffic using something like Chrome console.  Even if you encrypt it, the code to decrypt it lives in the end user's browser and can be reverse engineered.  I suppose you could withhold the key from everyone except authorized users, but what is the point in using up bandwidth by returning data that can't be read?  Instead of encrypting it, you may as well redact it, e.g. replace it with completely random gibberish, or replace it with empty strings.  Do it server side.


Correct settings to generate private intermediate CA I am using 'xca' in Linux to set up a private CA. xca only includes templates for the Root CA and End-User CA, no intermediates. What are the correct settings (fields and flags) for an intermediate (and lowest level in this case) level certificate authority to distinguish it from the root and end-user certificates. I know the root is self signed and the intermediate is signed by the root, but I am not sure of the intermediate CA settings beyond that. To be specific, I am not asking about software settings, but rather the differences between the Root and Intermediate certificates.

The only difference between a root and intermediate CA is that the root is by definition self signed.

And the difference between a root or intermediate CA and an end (user) certificate is that first two contain a x509 Certificate sign extension while last one do not.

So that is only a question of self-signed or not and presence of a Certificate sign extension.


What to do about companies that refuse to fix their security vulnerabilities While writing software for an application platform developed by a third party company, I came across a security vulnerability in the framework's code that could allow unprivileged code to perform unauthorized privilege escalation through a vulnerability in a sandboxing solution.

I have notified the company of the security problem and have even developed a patch for the problem within less than a week and the company still has not released an update to the product to fix this vulnerability.

This company has currently sold over 40 million copies of this product, and after several weeks, has still not fixed this vulnerability. What should I do to make people aware of this vulnerability and what they can do to protect themselves, without giving the "bad guys" tools that could be used to attack the platform? Is there anything I could do to convince the company to release a security update faster?

What are the best practices in the security industry for this kind of situation (note: I'm a software developer, not an IT security expert)?

Honestly some people need a wake up call before they take responsibility for their mistakes.

Give the company a set time,  like one month from today to release a patch.  If they do not comply post information about the vulnerability on the Full Disclosure Mailinglist.   By not making this information public then you are risking that organized crime will discover this flaw and exploit it for profit.

(I hate to say it,  but you have already given an attacker enough information to find this vulnerability.  There aren't many platforms with 40 million sales... The clock is ticking.)


Is there a need for SSL on a local site? Do I need SSL for a site that can only be accessed on the local network?

All users log in with windows credentials using Windows Auth with PHP on IIS.

And if I don't: What security is needed to make sure there are no issues.

And if I do: Why?

Short Answer: If you can use it, use it !

It is a good practice to have SSL even on Local sites. There is no such thing as 'ONLY' local network. I'm assuming you use the word 'only' to indicate that only people inside your network can access it. This is a result of the fact that people don't consider insider threats.

But lets say you just have static pages, containing pages of information. In that case SSL is not worth it.

But when you are dealing with web apps, with sensitive information, it is imperative to use SSL, even inside your own network.

EDIT: Definitely USE it. (based on your edit). Same reason as above. Inside attackers can sniff the traffic and possibly spoof another user.


Is secure web-app off-line auth possible? I'm currently thinking about a web-app that can go offline (after being online) and still be able to provide authentication to the user securely.
(For example, in a multiuser environment, it's quite essential to prevent other users' access.)

Right now, I was considering a password-hash authentication with some salt, and just saw this SO question:
https://stackoverflow.com/questions/7879641/user-authentication-in-offline-web-apps

But since this is a web environment, I have to assume that others have access to the source code of the app, and thus the salt itself is leaked.
(Also, the attacker might use the hash itself to bruteforce the password itself.)

So...to summarize, my 2 questions are:

Is salting effective even when it's leaked?
I'm guessing no to the question, since it takes O(X^(m+n)) to bruteforce the unknown...
 and it gets worse when the attacker uses the password hash to bruteforce the passwwd..
Are there any effective (secure) ways to authenticate the user?
Any good way to generate a DES key for encrypting the user's data
 (and provide a way for the server to distinguish between tampered data and real one?)

I'll answer your "2" questions below:

As for the salt: a salt is supposed to be public. Sometimes an extra secret value is used (e.g. by pre-pending to the password). This is often referred to as "pepper".
Try TLS with client authentication. Use the credentials within the client certificate (after successful authentication & session establishment) to provide access control.
Yes, it is possible to derive a DES key "in a good way"; use PBKDF2 with a high iteration count and large random salt. The DES key is however not secure anymore once it is used for encryption because of brute force attacks.


Is there any way to pretend like we are routing our request via cloudflare? There is this Web App which uses cloudflare and to bypass certain things I had to find a way to access the actual web server directly. I tried numerous things and finally I think I have found the actual server's IP but seems like direct access to IP is blocked as am greeted with this error.

Error 1003 Ray ID:
Direct IP access not allowed

What header (or referer's value? ) to supply with our original request so that the web server accepts my request as a request routed via cloudflare's reverse proxy?

In other words, I want the actual server to believe am coming via cloudflare. I believe to do that we have to supply specific header or a specific referer's value but I can't figure out what to supply in actual request. Any help would he appreciated.

Thanks.

You haven't found the IP address of your target server: you have  just one of the numerous IP addresses used by Cloudflare servers.

As Cloudflare assigns the same IP address to multiple sites, you need to tell which site you're trying to reach, there is this text in the error page:

  A valid Host header must be supplied to reach the desired website.

This IP address won't be useful to you, unfortunately.

To answer the original question: when you'll find the real webserver, if it only responds to Cloudflare servers, you might be out of luck, since the server might be configured to respond to Cloudflare IP addresses.

I would still have a look at Cloudflare Workers, since it might allow you to perform HTTP requests as if you were a Cloudflare server, but I haven't tried it some there might be some limitations that prevents you to do that.


How much entropy should passphrases for encrypting ssh keys have? When one generates keys using ssh-keygen one gets prompted for a passphrase to encrypt the generated key with.

How strong should such a passphrase be, entropywise, to withstand a full-blown brute-force dictionary attack?

Also, are there any ssh configuration settings that increase or reduce the advisable strength for the passphrase?  (My understanding is that the slower the encryption algorithm used, the less entropy is required to put a passphrase encrypted with this algorithm beyond the reach of any feasible brute-force dictionary attack.)

It should be as resistant as a good passphrase (obligatory quote of xkcd, even though it does not relate to offline attacks (but another one does))).

The encryption mechanism used by ssh-keygen is slow - which is good. Since the answer will be changing with time as computational capacities increase, make it 25 characters long and you will be good to go for some time.


Downloaded MailMergePro file seems to have virus attached I downloaded MailMerge Pro from http://www.standss.com/emailmerge/download_process.asp website and i scanned it on VirusTotal.com and two of the antivirus flagged it.
I am sharing the link for same, i am not sure if this actual virus or it is a false flag

https://www.virustotal.com/en/file/ba37e35beeb8d28c2a3ca7b99201159f24672ac0181d4cfa0b6fd5754cb46592/analysis/1506994938/

Is it safe to use or not?

I would exercise caution here, although this could be a false-positive, considering that a lot of the other scanners on the site didn't pick anything up.

TR/Dropper.MSIL.Gen, according to Avira's website, is a generic name for specific Trojans that Avira detects that are currently not specifically named.

In this case, I would run this in a virtual machine or on a test machine that doesn't have physical access to your main computer. Install the program, then run a full system scan with various virus/malware scanners, such as Malwarebytes, ESET, Avast, etc..

I rarely recommend this, but you could also try downloading it from other reputable download sites, although your download experience may vary.


SIEM system, what are the benefits? Each person in the company has a unique username/password, and nobody should log in with his username/password but him.

I want a program that would inspect the logs that includes a list of all the people that came to work today, and inspect the list of the logged in users (from the AD or wherever is), to find if there is someone in the logged-in logs that shouldn't be there (since he isn't in the first log). If the program finds that kind of inconsistency it should report immediately to the men in charge of the system.

The above manifest is what my boss wants, and he thinks that a SIEM system could give us that ability. That is just one example of log file cross-referencing that he wants us to have the ability to do.

Right now we have many systems (from many companies), and each one is inspecting different aspects of the company (for example, a system that give us reports from the file servers on what and whom has changed files, how much files, and any abnormality that it found; a system that checks USB insertion on PCs and so on). I would like to find a system that I can feed all of the reports to so that I can generate a cross-reference report.

As far as I have understand from the Wikipedia pages on SIEM (SIM, SEM), this system should give us that ability.

My question is, since I need to select one of the 86 different SIEM systems that are out there, and finally implement it at the organisation, I would like your advice on what is the the system that would fit to my above needs. It should also be easy to work with as much as possible, since at the end of the day someone will have to work with that system and if it doesn't have a meaningful interface and meaningful reports for example I wouldn't get the results I want.

In addition to the above, I would like to know what components I should be prepared for (computer client agent, server agents and so on).

Solely from the information in your question, narrowing down that list of 86 is not going to be easy - I had a quick flick through as I know a fair few of the top names. Some points:

SIEM solutions should all be able to run log correlation type activities
Most include device insertion logging and Tripwire type checks (or can incorpoprate Tripwire or any other SYSLOG logs)
Most of them have reasonable user interfaces
Most have scriptable command line interfaces

What you should do is list out the things you do want/need it to have and select on those items. If you can get it down to under ten you have a much better chance of being able to run comparison tests.


How specifically should I implement CSRF protection? There are a ton of articles explaining what CSRF is and that I should use a CSRF token to prevent CSRF. A few of them mention details such as using SHA256 over MD5. However, none of them explain how to implement CSRF protection in relation to the user flow. For example, am I suppose to store the CSRF token in a database or can it be self contained? Here's how I think I'm going to implement CSRF protection, let me know if there's anything wrong:

User arrives at the page and logs in. They receive an http-only cookie containing a JWT.
I generate a random 128-512 bit value (fixed length, I will decide how long it is). Then, I concat the value and the user's ID and HMAC SHA256 hash the result with a private key. I embed both the random value and the hash in the HTML.
Whenever the user makes an API request, the random value and the hash are appended as either a header, GET variable, or POST variable (there's no difference to security right?).
The server concats the given value with the user's ID and compares it with the given hash. If they match, then the CSRF portion is done.

Is this implementation correct? Some cause for concern is that the user receives a new CSRF token every time they perform a full page load. They can also have multiple valid tokens if they have multiple tabs open. I don't think these will cause issues though.

Edit:
A whole day of reading about CSRF later, I realized I can just put the JWT in the API request header and that's it.

I'd recommend creating a system where an anti CSRF-token is submitted from a hidden input field and is transmitted in the header. Both should be  checked on the server side.

Here's an example in PHP:

function generateToken($key) {
  $token = base64_encode(openssl_random_pseudo_bytes(16));
  $_SESSION['csrf_' . $key] = $token;
  return $token;
}

function checkToken($key, $value) {
  if (!isset($_SESSION['csrf_' . $key]))
    return false;
  if (!$value)
    return false;
  if ($_SESSION['csrf_' . $key] !== $value)
    return false;

  unset($_SESSION['csrf_' . $key]);
  return true;
}

  if ($_POST and $_POST['action'] == "something")
  {
    $header_token = apache_request_headers()['X-Anti-Csrf-Token'];
    $post_token = $_POST['token'];
    $post_token = str_replace(" ", "+", $post_token);

    if ($header_token == $post_token)
    {
        if (checkToken('settings', $post_token))
        {
           // ok; do something

        }
     }
     else
     {
         // wrong; do something
     }

 }

Sending the header before processing it:

   <script>
    $("#some_div").submit(function(event) {
      event.preventDefault();

      var $form = $(this),
        url = $form.attr('action');

      var posting = $.ajax(url, {
        type: 'POST',
        processData: true,
        dataType: "text",
        beforeSend: function (xhr) {
        xhr.setRequestHeader('X-Anti-CSRF-Token', $('#token').val());
    }

This piece of code will generate the token and puts it in an hidden input field.

<input id="token" type="hidden" value="<?php echo generateToken('settings'); ?>">


Is this type of ARP poisoning attack possible? I am wondering if it is possible to paralyze a network by sending out a bunch of fake ARP response packets.

Some basis: I recently read a moderately detailed description of how ARP and ARP poisoning works (which is here, pdf). I think I understand how ARP poisoning works, at least in the level of detail presented in that article.

My question is about a different type of ARP poisoning. Instead of sending ARP response packets that direct all traffic to the attacking computer, could a device send out ARP packets that just jumble the victim devices' ARP caches? It sends out many packets to each device on the network that give a wrong MAC address for every IP the attacking device can find?

Is this type of attack possible? What countermeasures are there against it? Are these countermeasures in common use?

Additional questions: Do ARP packets contain information that would allow the administrator of the network to locate a hidden wireless attacking device? Would there be a way to disconnect the device from the network?

This is actually called ARP flooding. An infected system/malicious user sends ARP replies to all systems connected to the network, filling them with incorrect ARP entries. This causes the systems to be unable to solve MAC and IP addresses resulting in systems being unable to connect to other systems in the network.