How to combat and prevent a lpcloudsvr302 and bk-coretag.js Virus?

Let me use a example of how we combat infections over where i work.

we mostly begin with analyzing, so lets say we found the bk-coretag.js virus, which is classified as an adware or malware virus... an innocent little bugger that annoys mroe then it does harm (if lucky!).

note that these virusses mostly appear through the installation of programs (i.e. when you install a program like CCleaner, it will ask you to "install this totally not obvious crappy adware tool you will never use", its easy to miss that, and click yes too hasty, BAM! you're infected).

these are common, you can remove them by running a virus scan (i prefer Malwarebytes for this task, since its powerfull and trusted: http://www.malwarebytes.org )

after you scanned, remove the program you think its attached to, since it has to come from somewhere (the indentifying is the tricky part).

after that, go to your browser, and reset all the setting for search engines and such, then restart your pc.

if it still occurs, you may have remoed the wrong program, so keep on digging till this works.

how to prevent? simple, when installing, read everything carefully, and WATCH WHAT YOU INSTALL, when installing random programs from the net, search around on google if theyre not "malwareliscious", and always keep your anti-virus up to date, and always a copy of malwarebytes on your PC, which runs nicly next to most anti virusses.


What is considered the simplest (or lightest) secure development lifecycle?

Great question.
First, the "minimum" you quoted refers to Microsoft's minimum requirements policy, not necessarily the "industry best practices" minimum. Not that I'm saying its wrong, but the MS-SDL itself does go on to say that their SDL is not necesarily fitting for any organization outside of Microsoft... In fact the MS-SDL architects, such as Michael Howard is oft-quoted saying:

  Don't do what we do, do what we did.

Which is to say, its not so much the prescribed requirements as they specifically appear in the document (though they might be mostly very good), but they repeatedly performed studies, including risk-based analysis, historical metrics comparisons, trend analysis, root-cause analysis, trials in different teams to see what "takes", etc.

There is not a well-defined, simple SDL you can just download install and go be secure. That point from MS is spot-on - you really need to tailor your SDL according to your specific organization, your teams, their proficiency, the types of products they're building, the current development process, the risk profile, etc etc. And that's really the best solution to "try out"...

Moreover, SDL is not a one-time thing, or even a question of defining and implementing the correct policy. Building an SDL is itself an ongoing process, which admittedly can take several years to implement completely. Microsoft did quite a few iterations till their SDL reached something exemplary... And it took another couple years to get it really ingrained in (most of) their developers. You can't really "try out" an SDL, because the benefit will typically not show within the first month or two - it really is a long term investment.

So, for orgs just starting out, and looking to define their SDL - I would suggest taking it slow, have someone with experience guide them in the process:

Start by mapping out the current situation, process, teams, experience, flexibility, etc.
If the teams + management are not 100% convinced of the need for SDL, and security in general, consider doing an initial security review just to drive home the problems... A pentest is often most useful here, simply because it can be quite visual (NOT because its needed for the SDL itself at this point).
Ensure at this point you have buy-in - both from an executive sponsor, and from the teams themselves. Without either, the SDL is doomed to failure.
Training! Developers like to do things right, if they know how.
Slowly add minimal additional security activities, according to the benefits you will receive for them, as compared to the effort invested - and the disruption to the dev teams. Remember, the point of the exercise is to get EVERYBODY involved in security, and not turn them off right away.
Set up security expertise, either in your team (as a security champion) or in a central team that everyone can talk to - and get them talking. Better yet, is a hybrid model of both (as in the MS model).
According to your capacity for additional security investment, in each cycle add minimal additional activities, on top of the previous ones. The point is to get them so used to doing one-two small li'l things, that it becomes second nature (almost) and it no longer "takes so very long to do this security stuff". Then you'll have bandwidth for more...
Gather metrics along the way, so you can tell what is working and what is not, and also to show the benefit from the SDL investment to management.
More training!

Now, the real problem is that list above, looks like a lot.
But it really isnt, since most of those bullets are "meta-activities". Some of them should probably be done by an experienced security guy/gal/consultant, with experience in implementing SDL in a similar type of environment as yours. Admittedly, still not so simple, but when I do this I put the emphasis on minimal disruption and ongoing investment. It can be done lightweight.


Is there any way for server side to verify the application integrity during OAuth2 workflow

Regardless of OAuth2 PKCE flow or any other flow, the question boils down to "can the server check the application integrity?". The answer to this question is simply NO.

The application resides in user land, meaning that an attacker has full control over the application. The attacker can install it on his device, patch it, dynamically change its behaviour (hooking) or change values in-memory etc...

The only thing you can do is to make it hard for an attacker to mess with your application. A few counter measures are:

Root/jailbreak detection.
Code obfuscation: includes obfuscating method/variable names, control flow obfuscation etc...
Something called Runtime Application Self Protection (RASP): this usually includes hook detection & debugging detection.
Encryption: for example in Android it's possible to dynamically load a DEX file, some apps load an encrypted DEX file in memory and decrypt it.
Device finger printing: check for example if device is run inside emulator.

The above counter measures can be implemented in different ways. There are products out there that can do this for you. In the end, it is possible to bypass all such measures but it requires some effort. The question usually boils down to threat modeling: What are you trying to protect? How much do you want to spend on such solutions? What can an attacker achieve if these solutions are bypassed? How easy/hard is it?

Also don't forget about communication hardening. You can implement all above measures but an attacker can for example also use a mitm proxy like Burp to intercept and change data in transit. So using TLS everywhere might be a given, but don't forget about hardening measures such as TLS-pinning. To be honest, this is easy to bypass if you ask me. I've seen some people get creative and do stuff such as: encrypting and signing the payloads sent to the server, using binary protocols instead of HTTP and much more.

Remember, at the end of the day, a motivated attacker can overcome all these hurdles.


An "ESTABLISHED" connection seen in the output of a netstat command reffers only to the TCP connection. If the port was accepting connections from any remote IP, anybody could stablish a TCP session, where the SSH daemon would ask for login and password, but it does not mean a SSH session is stablished.

You could easily try it yourself: login to your machine via SSH and then, from your local PC use telnet, netcat, socat or any other similar tool open a TCP session to your remote machine on port 22. Then in your logged in session, get the output from the netstat: you will see 2 connections from your local PC as stablished, the one with a SSH session and the pure TCP connection from the telnet.

Search into /var/log/auth.log for SSH sessions. Try looking for "session opened", which should only correspond to your connections.

Also, I would recommend doing a few extra configuration steps on your VPS: first, if your local PC has a fixed IP address and you only plan to connect to the VPS from that PC, restrict via iptables to allow connections only from that IP (NOTE: doing it wrong could lock yourself out of your VPS, caution needed). If it is not fixed or you need to connect from other sources, that option is out of the list. Second: to reduce bruteforce (fail2ban is nice, but it relies on logged events to work, so you will always have some attempts from new sources), I would change the SSH port from 22 to something else.


What can a hacker do with a card number without CVV?

The only fields required to charge a credit card are the number (also called a PAN or personal account number), the expiration date, and an amount. Without the CVV it is still very possible to charge the card.

Many merchants will require the CVV and/or postal code as basic anti-fraud mechanisms. There is also an incentive for many merchants as providing these can qualify them for lower interchange rates, the service fee paid by merchants to the card network.


Is starting an AWS instance with only ssh to port 22 significantly insecure?

The answer depends on your risk appetite. Restricting access to the SSH port to only known IP addresses reduces the attack surface significantly. Whatever issue might arise (private key leaks, 0-day in SSH, etc.), it can only be exploited by an attacker coming from those specific IP addresses. Otherwise the attacker can access the port from anywhere, which is especially bad in case of an unpatched SSH vulnerability with an exploit available in the wild.
It is up to you to decide, how important the system and its data is to you. If it is not that critical, the convenience of an SSH port open to the world might be appropriate. Otherwise, I would recommend limiting access, just in case. Severe 0-days in SSH do not pop up on a daily basis, but you never know when the next one will.


Is it a bad idea using two firewalls on the same PC?

Keep in mind that firewalls generally use one of two approaches to filter network traffic in Windows:

Classic way by installing own driver (used by, for example, Kaspersky).
By using OS mechanisms, specificaly "Windows Filtering Platform" - an internal, kernel-level packet filtering (similar concept to Linux NetFilter), which is available via API since Windows Vista (used by, for example, F-Secure).

In the first case, when you have two drivers installed, there could be a potential problems with prioritization and order of processing. Also, those drivers can install own hooks and do some other hacks which could result in incompatibility or system instability.

In the second case, when two firewalls use API, it will result in messing around the same, built-in mechanism.

In the third case, there will be an driver and Windows Filtering Platform.

It is good that you want to add another level of protection, but I suggest to do it on the edge of your network (or inside the network). Today everything is much more complicated than in the old times, so I wouldn't install two firewall's or antivirus programs on one system, because they are too critical system level applications which interfere with OS very much.

The best solution is to use Linux NetFilter or BSD's pf, but it generally requires another machine running. Take a look on MikroTik devices - they are essentially Linux boxes enclosed in small devices. They wouldn't be as good as native Linux, but are better than most other routers.


Why do web users still use password manglers though password is sent in ciphertext

It's possible you're misinterpreting one of the variations.

One useful variation, known as Challenge/Response, is that the website login, instead of asking the user for a password, sends a nonce (a number used once, that is an ad hoc random number) to the user. The user then replies with Hash(user password + nonce + whatever else the website knows).

The website performs the same calculation and compares its computed hash with the hash returned by the client. A match proves that the client knows the password, without ever having to send the password itself.

Sure, the communication is encrypted, but security should be thought of like an onion. The more layers the harder it is to crack, but only if you don't get sloppy on some layers figuring that the other layers will carry the load. Even if you know you're on a "secure" channel, talk as if you think it might not be secure. Even over an encrypted channel, not sending the password is more secure than sending it.


How sufficient are these steps to prevent deleted SSD files from being recovered?

Either you're serious about deleting your data, or your serious about keeping your system functional as it were. The distinction between user data and operating system state is kind of weak, especially on Windows' questionable ecosystem with myriads of third-party things that shouldn't be a system service, but are.

You'd want to enable hardware disk encryption, then wipe that password, leading to the SSD safely discarding all data (or ways to decrypt it).

You'd lose your running Windows.

Honestly, when buying a used computer, first step, wipe the SSD and re-install the operating system from clean slate. Have no interest in continuing to run the malware that the previous owner (most likely involuntarily) ran.

So, a "already working" Windows 10 installation adds exactly nothing to the worth of a laptop to me. A Windows License, however, might. So, clearly mark that you're selling the laptop with a windows 10 license, and deliver it with the product key (which, afaik, you can somehow extract from your running windows). You can pre-install Windows if you want, up to the point where it starts asking for customization.


Complex password rules - is there any sense?

Two points to note:

It is good practice to assume that other security steps have failed. You can' say that insecure passwords should be allowed because sites shouldn't allow details to leak, or that you should assume that there are brute force protections in place. Password requirements require users to deviate from established behavior and create passwords which are further towards the edges of the bell curve of frequency. The less common the password, the harder it is to break in a dictionary attack. Increasing entropy fends off brute force.
Using the argument that "I can make a word that you cannot guess, therefore the general rule should be to allow everyone to make their own free passwords" is a fallacy. Most people do not make passwords assuming adversarial intent. They make passwords based on what they can remember, and security is a secondary concern. Password requirements force the consideration of security, or force them not to use the frequent offenders of password lists.

Password rules are one level of multiple levels intended to keep people secure, under the assumption that others fail/are not followed, the more of these we have, the more likely we'll actually make enough work to matter.

Now, the relative benefit of password complexity rules in comparison to other routes of similar effectiveness is another question entirely, but the question of whether they are better than no requirements, then the answer is yes.


Why would an encrypted file be ~35% larger than an unencrypted one?

Most likely, the encrypted file is base64 encoded which would account for 33.3% file increase (you encode three bytes of data in four bytes of base64 data).  Inserting a new line every 64 characters to make it easier to read (as is done by ASCII armor in openssl, GPG, PGP) will increase the size by 65/64.

Combining these two effects results in the new file being (4/3)*(65/64) = 135.4% of the size of the original or an increase in file size of 35.4%.

I've gone through the calculation in this answer here.

You are correct though that encryption should not need to significantly change the file size.  It possibly adds a couple blocks of data if there is a header, an initialization vector/nonce, some padding to make it a full block and/or MAC to check integrity, though these changes will be insignificant for large files (e.g., adding four blocks to an AES encoded file that is 1 MB would make the file 0.006% larger).

However, to not increase the files size, you need to be fine with storing and passing around the encrypted data as an arbitrary binary.  Arbitrary binaries are often blocked over email to prevent spreading computer viruses, and are often difficult to open outside of hexeditors.  Base64 encoded files are easier to pass around and is a more portable format than binary files of an unknown file type.


Very strange gibberish strings with Cyrillic characters that appear in random websites and elsewhere

I was looking around websites with the same problem as you.

One of them is a french website and here is the text inside:

  Mon banquier ne mР В Р вЂ Р В РІР‚С™Р Р†РІР‚С›РЎС›appelle plus pour mon dР В РІР‚СљР вЂ™Р’В©couvert, nous Р В РІР‚СљР вЂ™Р’В©changeons dorР В РІР‚СљР вЂ™Р’В©navant sur mes nouveaux projets

The non-alphanumeric characters (not a-z/A-Z) are replaced by the 'Cyrillic' characters.
In this text there are ',é ...

In this case, it looks like an ASCII encoding problem where a multi-byte character is considered multiple uni-byte characters. So a two-byte character will become two one-byte characters.

I wandered around and found out that it could be linked to database encoding databases format. But I'm not an expert in databases and maybe someone with greater knowledge can complete the explanation.

So as @james-k-polk said, the characters you're seeing are either not supposed to be displayed as characters orz in my opinionz they are just badly converted from one format to another.


Isn't it dangerous to allow users to change email?

Everything is dangerous, including breathing and eating.  It's all a question of balancing the risks.
You are looking at a case where the username and password of an account got compromised.  At this point the attacker has full access to the account.  What you are now looking at is what recourse a legitimate user has.  How can they reclaim access to their account?
Emails are historically used as a reasonable stop-gap.  If you have access to an email account, you're probably the intended owner of the account.  It is nice because it is automated.  However, if push comes to shove, and you really need to get an account back, the last line of defense is always to contact the company and talk to a real live person.
On the other hand, the need to be able to update credentials is very important.  Many of us nowdays keep an email account from cradle to grave, but it wasn't always that way.  Many people still use an email address provided by their ISP.  If you couldn't change the email address associated with an account, you would be forever bound to an ISP -- quite the conundrum if you were to move to a new state with different ISPs!
So the decision is that the rewards outweigh the risk.  Maintaining a solution for all customers using a service, even as they have to update their contact information, proves more important than the risk of a hacker using this to steal an account away.


But, we discovered that if the user has the 7zip and opens the appliance (.ova) he can navigate by the folders and get the PHP Code.

An .ova file is simply a tar file containing configurations and disk images for the appliance. 7zip allows the user to open the tar file and since 7zip supports various disk image formats the user can also look whats on the disk, i.e. your PHP files.
There are other ways to do this without using 7zip so it would not make any sense to develop any 7zip specific solution.

The cause of the problem is that you distribute the source code of your application to the user, even it is packed inside multiple containers (disk image, tar). You do this because your web application in the appliance needs to have access to these files. Encryption of the .ova or disk image inside will not help because in order to run the application these data need to be decrypted and once this is done the user can again access the data.

It is also not possible to encrypt the PHP code itself because the PHP interpreter needs the decrypted code. The best possibility to hide the code from the user is probably to obfuscate it so that it is still usable source code but unreadable enough for simple reverse engineering.

At the end you face the question tools like DVD players and other DRM solutions faced before: once you have shipped the application to the use you loose the control over it. As long as you have no control over the system of the user you can not limit the activities of the user. This means you can make the reverse engineering only harder but not impossible.


I would recommend doing a little reading on the OSI model. It might help shed a little light on this, but I will give you a brief overview so this makes more sense. Remember that these concepts can blend together and a firewall could have all of these features.

A traditional network firewall operates at layer 3 and layer 4 of the OSI model, which is IP addressing/ICMP and TCP/UDP. In its simplest sense, it's a hierarchical rule chain that blocks or allows specific packets which match a specific criteria. This type of firewall implementation has little to no awareness of "higher" layers of the OSI model.

An application proxy is typically said to exist at layer 7 of the OSI model, the application layer. These proxies must understand the protocols that they proxy, such as HTTP. A firewall can often have these features as well. A web proxy, with its awareness of web protocols, can have content filtering features which could filter ads. A device or software package described as a firewall could have these features. These are typically called application firewalls or layer 7 firewalls.


Can I trust a session Id for uniqueness?

Although there is an accepted answer here, it is somewhat misleading.

  Can I trust a Session ID for Uniqueness?

If uniqueness is the only constraint, then the short answer is yes. If you are Facebook or Google, then due dilligence would require that you take some time to assess how likely collisions are based on the algorithm and the architecture of the application. For applications where the concurrent userbase will be less than a million, the method implemented in common platforms should be sufficient.

However uniqueness just addresses the functionality of the system. From a security viewpoint you need to ensure that the session id is not predictable - i.e.

that cannot be inferred from available data; md5(CLIENT_IP) would be a poor session id
that attempting to brute force guess the session id is difficult; next_session_id=last_session_id+1 would be a poor choice

If you really must implement your own session id generation, then use a good random number generator. Have a look at the size of the session ids your current system is generating and aim for at least that size in your implementation.

user52472 said:

  Storing session tokens in the database could allow an attacker to impersonate other users if they can gain access to these tokens via a SQL injection attack

Given that the whole point of server side sessions is predicated on server side storage, this can be better stated as:

Storing session tokens on the server could allow an attacker to hijack sessions if they are able to inject code which reads the storage

....although the nature of SQL is such that it is usually the low hanging-fruit of code injection.

One solution is to not store the session data against the session id, but a transformed representation of it (e.g. sha1(session_id + salt)) but this is only provides limited benefits - if the salt and mechanism are exposed, the mechanism is inneffective. OTOH this easily translates to other storage substrates.

If the sessions are stored in a relational database then its possible to protect against enumeration via code injection by disallowing direct access to the underlying table by the account used by the application - instead restrict reads and writes to a single record based on the key (session id) supplied as an argument to a stored function with privilege separation.


What kind of security is needed for simple REST API on Amazon's AWS

As the most basic security principles, you need to consider the CIA triad: Confidentiality, Integrity, Availability.

Your say that the information hosted on the site is public information, so confidentiality to your company isn't priority. However, you need to consider also the user's perception of confidentiality might not necessarily be the same as your company's perception of confidentiality. Even though is public information, many people don't want their browsing habit to be tracked for various reasons, many people are searching publicly available information about medical issues they might consider embarrassing, maybe an LGBT still in the closet don't want anyone to know they're browsing certain sites that might tip other people off, maybe a husband want to hide his researching for a surprise vacation plan research from his wife. Modern best practice usually considers this to be too difficult to evaluate properly since you can't always guess the motives of your users, so end up just encrypting everything with HTTPS.

How about Integrity? How important is it that the public knows that this data is published by you, and not have been altered by any other entities? If integrity is somewhat important, then you should consider using HTTPS, and possibly also publish cryptographic signature of the data you published. How important is it that the user knows that the data is up to date? You might want to add signed timestamp of the data publication date, to ensure users can tell if they're setting outdated data (replay attack), in sine circumstances, you might even want to notarize the timestamp by publishing the hash of the data in, say, Bitcoin's blockchain.

You suggested Availability is important. Availability risks that you need to consider is attacker doing a DDOS attack to overwhelm your site, or for the attacker to trigger account lockouts by using incorrect passwords. For basic availability, you'd want to implement firewall and monitoring and alerting systems, you'd want to ensure legitimate users have a way to reset account lockout that the attacker won't be able to do. How important is it that the data is available in case of deliberate censorships like say Great Firewall of China? Depending on the level of availability that you are targeting, you may want to consider using a network of mirrors, CDN, Tor, or Freenet to distribute the data.


Can someone steal cookie contents via a phishing attack?

Assuming a pharming attack rather than phishing... This is where the domain name is redirected to a fake site rather than Typosquatting or tricking the user into visiting a totally different site that is made up to look like the target.

The difference here is crucial - the effective domain of the fake site as seen from the victim that is actually the same as the real site will cause the browser to treat the fake site as the same Origin.

This means that cookies, local storage, et al, will be available to the fake site.

Two mitigating points:

If the Secure Flag has been set on any auth cookies, they will not be sent to the domain unless it is accessed over HTTPS.
If HSTS has been set for the domain either because the user has visited the site before and has an HSTS entry for the domain in their browser, or the site is in the HSTS pre-loaded list, the user will not be able to connect to the fake site over HTTP (nor over HTTPS if the certificate causes browser warnings).

If neither of the above apply and the user had an authenticated session against the fake site, then the cookies will be sent to the fake site, including any used for authentication. Hopefully a bank will have taken either of the above precautions but not always the case.


That depends. What is the risk you see with having some unknown entity be able to see your switch configuration?

By capturing SNMP v2 traffic (unencrypted) a potential attacker can map out what your network looks like, probably matching VLANs to departments and server networks, etc.

It is an information leak. You are not allowing write so they can't change anything, but they could get a very good idea of how your network works, and where to focus on attacking.
If you set it up such that the observium station across the internet connects via VPN that terminates on a management VLAN so that the traffic is contained, you could minimize who might have access to the traffic between the switch and observium.


How can we find server location and IPs?

It's easy to know the IP address of the host your application is communicating with.  This is, as you comment, just the destination IP of the communications.

But knowing that IP address doesn't get you much. There is no way of knowing if that host is a web server/other server, a gateway or proxy, a network load balancer or content distribution network node. It might be, and often is, multiple hosts. It might be one IP today, and another IP tomorrow; or one set of IP's for the US West Coast, and another set for the US East Coast. Content Distribution Networks have changed the way we deliver content from servers - most app services of any size have large distributed networks of content making up what you'd call a "server". All you know from the IP is the peer that your client is communicating with, and nothing about what kind of architecture is hiding behind it.

Location is yet another problem. Geolocation is inexact, and sometimes very inexact. You might be able to tell what country an IP is coming from, or at least what region of the world. It depends on what information the ISP's are revealing, how dynamic the network is, whether measures are being taken to conceal location, etc.

In short, the answer is "sometimes, maybe, but don't depend on it".


Is SQLi via a "Long" variable possible in Java / Hibernate?

In your Java example:

Query query = entityManager.createQuery(
        "SELECT UPPER(request.attributeValue) FROM PreOrderedRequests request
         WHERE request.status = :status AND request.report.id = " + var1);

If var1 is a byte, short, int, long then there is no security exploit. These will be interpreted by the SQL server as the developer intended.

If 'cached prepared statements' is enabled, then such code would degrade the cache's effectiveness, but that would not qualify as a security issue.

If var1 were a double, float or char then an attacker could likely cause an SQL syntax error (with Infinity, -Infinity or some unexpected charactor), but it would be rare for that error to become a usable SQLi attack. This would primarily be a means of gathering information. (i.e. error pages could reveal a vulnerability in some edge cases)

If var1 were a String it is obviously a serious issue.

If var1 were some other Object, then the risk would depend on the Object's toString method. (i.e. Integer is safe, but CharSequence is unsafe, and Collection is probably unsafe)


Can PKCS#12 files contain multiple certificate chains?

PKCS#12 container may contain multiple encrypted private keys and public certificates. The upper limit is not strictly defined.


Is there any benefit to hashing sortcodes + account numbers?

Be wary of hashing things where people might determine characteristics of the input. One company used MD5 of taxi IDs for anonymizing, which was quickly reversed. Yes, you could try some home-baked hash modification that would make it less obvious than just a straight MD5, but that's security through obscurity. Solving almost any hashing function for every 8 digit account number is trivial, at which point your data is as good as plaintext. Concatenating account numbers with the sort code isn't going to be much better.

What you should do instead is to make a table/program/whatever that maps your sensitive data to random IDs. Your system would require access to that table/program to do the conversion, you can take steps to secure that table/program (like storing it in a truecrypt volume) while you work with the truly anonymized data.


You have to consider what an attacker might do. He can grab your update file, inject it with malware, compute a SHA hash, deliver it to one of your clients, and infect them. Their computer would not reject it if it's only looking at hashes.

If your app only accepts signed files, he cannot infect them.

But checking individual files may or may not be enough, depending on your code. If you only test your code as a whole version, the attacker could possibly find an interaction bug by mixing an older version of one of your modules with your newer code. You should consider signing a collection of modules at the same grouping you are willing to test and deploy at. That way, you deploy only the tested change as a whole, never piecemeal.

This kind of attack was perpetrated against Microsoft Update. Someone could download the list of modules but then interfere with the downloading of the actual modules.

Not only could this approach reduce your attack footprint, it could serve to improve your end user experience by ensuring they are installing complete packages that are exactly what you tested. It might even help keep them out of "DLL hell."


Can nmap (or another tool) detect hardware/system information such as amount of RAM, number of processors, etc.?

This is called TCP/IP fingerprinting and can also be accomplished with tools such as p0f. With this technique, you can detect things like approximate uptime, topographical distance, or even estimate the level of traffic the site is serving by analyzing IP sequence IDs, but you cannot detect the amount of RAM or number of processes as those do not affect the networking stack in any observable way.
See the nmap documentation and usage information for more information on OS fingerprinting.


Bash: Why would sourcing a file be less safe than bashing it (executing in another session)?

I don't know the exact statement and its context so I can only guess what was meant: if a script gets sourced instead of executed in a separate shell then any variables or functions defined in this script or any changes to variables will be visible in your shell after the script was done. This might be intended in some cases (and that's why you can source a script) but it might also be an unintended pollution of the current environment of your shell with unwanted side effects.

Thus, unless you explicitly want to let the script make changes to your local bash environment you should execute it as shell-script (i.e. separate shell) and not source it.

And note that this is actually not a problem of information security: from a security standpoint the sourced script and the script executed in a separate shell  can  both execute malicious code with the permissions of the user.


Why do web browsers provide websites with plain text passwords?

What are the downsides? None, really, aside from significantly increased complexity1, which is rarely a good thing, as well as high migration costs for literally every website with a password field, which is also not a good thing.

But let's consider the implications anyway, to see if they outweigh the costs. There are two ways you could handle this hash:

Don't hash it on the server side. Now a database leak immediately gives attackers access to everyone's accounts, because they just pass the hash in like they'd have passed the leaked password in before.
Hash it (again) on the server side. This probably won't hurt security, unless your hash functions happen to interact in extremely weird and unlikely ways. But now everything is basically the same; the only difference is that instead of directly knowing your password, they only know the browser's hash of your password.

In neither case do you gain any advantage. #1 is obviously wrong when you consider malicious clients, and #2 only protects you from attackers who sniff your password and reuse it elsewhere. But that shouldn't even be possible, because you shouldn't be reusing passwords at all. There are so many other attack vectors -- keyloggers, phishing sites, and so on -- that it's a good precaution to take no matter how your password is handled by the websites you're a part of.

1: Some questions any implementation will need to answer include:

Where to store salts (or, if they're not stored -- as seems necessary -- how to generate them in a way that can't be trivially parallelized to defeat the entire purpose of salts)
What hash algorithm (and parameters) to use
How to handle it when hash algorithms weaken over time and need to be replaced
Where to actually implement the in-browser hashing step, which seems simple until you actually sit down and think about it
How to securely handle this cross-platform, so that the same user entering the same password sends the same hash to the website
How to provide password fields without hashing, since that's often useful for entering sensitive data like SSNs or credit cards, and needs to be known in plaintext by the webpage, in a way that bad websites won't abuse to keep their original bad code

It's incredibly complicated, and all that complication adds plenty of room for bugs. In security code, that's especially dangerous.


What risks do Cookieless sessions have?  What are the mitigations?

The basics

First, I assume you understand the most basic session ID security right:

you are using an ID with sufficient entropy, and
you use transport level security (HTTPS).

Any approach to session ID (URL, cookies, whatever) that does not get those right is vulnerable, your question is specifically about ID in URL, so I will not discuss that further.

Web-browser leaks

The most obvious risk of ID leak is with the Referer HTTP header. The simple solution to this is either:

to forbid outgoing all links (<a href and others), all external embedded content (<img>, <object>...) and other external dependencies (<script>...), or
to change all outgoing links to go to an internal redirection page (which could be another security issue, depending on how you implement this).

Many Web application have zero outgoing links, and no content (esp. HTTP resources) from other users (which often has potential security/privacy issues, like Web bugs in emails).

This issue is usually described as a serious risk, but I disagree; if well understood it is easily managed.

User-behaviour related leaks

Voluntary sharing of URL with other users

Another practical issue is that users could fail to recognise the URL as the access key to the page, and share it with others, via email or in a forum. The risk is even higher if the document is public but the user might have some privileged access to it (like in SE), so sending the URL is the most obvious things to do to share a page with a friend.

When the page is by nature private and contains sensitive personal informations, such as the interface to manage your account, the risk is lower, but still exits.

I have personally witness more than one case of non-public URL being posted on a public forum, where the URL designates a web page random users could not ever legitimately access:

link apparently to a webmail: the link was not working, I presume because the session was cookies based and not URL based;
link to the configuration page of a modem-box in the administration Web application of the ISP; the administration application is on a public Web server and requires authentication (this allows ISP clients to view or change some of their account information from anywhere). Giving others access to this interface includes: giving bank account information, ability change account password, change account email contact address, buy optional features, terminate account ... or just click the "disconnect" button to terminate the session.

The issue I am pointing out here is not the web application design, but that the behaviour of a few uneducated users is to copy URL and post it even when the account manages some serious stuff (not just a lame forum account).

In the second example, it clearly shows that some user simply to not think about what they are doing: the shared URL was either useless for people willing to help, or a security risk. This is just simple logic, and zero technical knowledge was necessary to understand that: either an information is sufficient to access some other information, or it is not, so obviously this link was useless or a serious risk.

Usually when such URL is posted in a public place, some nice guy sees the URL, copies it and if the session is still valid, clicks "disconnect"; then he explains that serious issue to the user. Most people are honest, but there is a risk.

Sharing of screen shots (revealing URL)

Another risk is when users want to share some data shown on one administrative web page (and not their access to such page), so they make screen shots of an administrative web page, failing to realise that the cryptic information in the URL bar is a secret. Making the URL very long so that it is not visible on user screen lowers this risk.

This case is very different, as the sharing of information is voluntary but the fact is contains the URL is not realised by the user.

Technical and user issues

Some technical issues exist with ID in URL; other issues exist with ID in HTTP cookies. In both cases it is up to the developer to understand the issues and fix them.

A user expectations issue exists with the "secret in URL" approach. The issue is not that the user can see the secret information, it is the fact the URL bar does not usually contain a secret.

You could think of a social engineering attack were the user is convinced to install the (very nice) Firebug plug-in, then activate it, go to the cookie panel and copy session cookies from there. But even a user willing to do everything you tell him might not be able to correctly accomplish each of these steps!

Copying the content of the URL is not just very easy (downloading malware on the Web and installing is easy enough for many users too); the user is used to copy and send URL. Some more experienced user may have explained a beginner how to send a link to a news article. The beginner might assume he can do that on any website and any webapp (even if the more experienced user never told him anything like that).

The problem here is that you can review your webapp design, you can get help from security experts and pay them to do a complete analysis of your application (complete from design to every line of code), but you cannot do a security analysis of your users (unless this webapp is only intended for your highly qualified employees and security consultants).

Combination?

You could combine both ID in cookies and ID in URL, if:

both ID are different, independent cryptographic random numbers
and each ID contains sufficient entropy for secure protection if the other ID is leaked.


There is typically a line that shows something like "Not shown: 1494 closed ports, 496 filtered ports", so in this case it would be "Not shown, 1 closed port"... but you're only searching for one port which gives me the filtered or closed result by that port, so can't say what you're seeing. I tried it with debug on and it gives results like what you're looking for. Try:

nmap -d -d -p 443 -iL ip.txt


Is Certification path construction algorithm needed for SSL/TLS?

The algorithm is used on the Certificate chain in order to verify it - it would be a terrible idea to trust any received certificate [chain] without verification, wouldn't it?


How can I make sure Linux only uses secure connections?

To browse the web, I can use Firefox with the plugin "HTTPS Everywhere" set to "block every unencrypted request", and if I'm not mistaken I guess that should be enough for surfing the internet.

-

  basically not trusting anything between my laptop and the destination, especially not trusting the local network (and not trusting VPNs either). Some exceptions could be made for example for Google's DNS, I can trust their services, but not everything that's between me and them (unless the connection is secure). So you see why the question is about "secure connections"

This doesn't make any sense at all. Why would you trust a TLS encrypted connection to random sites, but not trust a VPN solution?

TLS will not protect you against malware. It will protect you against eavesdropping and MiTM-attacks.

Ubuntu, for instance, uses signatures and timestamping to secure updates against tampering, even though it's transmitted over plain http. At worst, an attacker can force you to not get updates; he can't really give you malware via the update mechanism.

If you have a remote device you have to access securely, set up a VPN to that service, terminating as close to the service as possible. Drop all other other outgoing traffic from your laptop.

Oh, and I'm very curious about your chain of thoughts leading to your conclusions about security...


"You have new mail" in a terminal is a very old Unix behaviour: the shell (the software which interprets the commands you type in the terminal) regularly checks whether the file /var/mail/username (where username is, you guess it, the name of the current user) has been modified (precisely, whether its last modification time is ulterior to its last reading time, the mark of a new but as yet unread data).

On a machine which is not an email server, reception of emails that way usually means that the email was generated locally. This is typical of cron jobs: you register some commands for regular execution, and when they get executed, their output is sent to you by email (that's purely local, the data never exited your machine).

See the contents of the file with: more /var/mail/my_user (in a Terminal window). This will give you some information as to the provenance of such emails. My guess is that they are totally unrelated with your Google story. Note also that I regularly receive (meaning several times per day) a lot of fake emails which purport an alleged security breach, and try to entice me into entering my login and password on some site which may or may not "look like" the genuine site for Google or a bank or whatever. This is common practice among attackers. Your emails might be of the same persuasion: fake emails which do not come at all from Google. Detailed inspection of the header and contents of such an email may reveal the foul play.

If unsure, reset your Gmail password (with a new, strong password); this won't make any harm.


Encrypt Different Users with unique keys

To do this, you're gonna need to do some learning, I'm afraid. Googling "how to do field encryption in a database?" will probably get you started.

In essence, you're gonna need to do the encryption (probably AES-GCM-256 encryption) in your application layer. Data comes in, application uses the AES key to encrypt it, and stick the encrypted blob in the database. When you retrieve a field from the database, the application uses the AES key to decrypt it and then use it. Once you have that infrastructure in place, using a different AES key based on the ID number of the record should be easy.

The problem you're going to run into is how you securely store the AES keys. You can't put them in the database, because storing the decryption key next to the encrypted data is a big no-no. So do you just put the key in a flat file on disk of the application server? Do you use some obfuscation trick to obscure the key on disk? Do you buy a server with a good TPM on the motherboard, and write vendor-specific code to store your keys on the TPM? Do you buy a full HSM?

These are tricky issues that don't have a good universal solution. If you're going to design and build such a system, you should become familiar with the tricky parts, and design a solution that fits what you have available.

EDIT addressing comments:

HSM

In comments you say that you have access to an HSM for storing the encryption keys. In that case, I'm imagining that the data flow is something like this:

Encryption:

App ---data---> HSM ---ciphertext---> App ---ciphertext---> DB

Decryption:

DB ---ciphertext---> App ---ciphertext---> HSM ---data---> App

In that case, the chances of the decryption key becoming compromised are very very small and realistically you probably have bigger security issues to worry about elsewhere in your network than creating a new key for every 1,000 users.

That said, if you want to do it, then you'll hit the problem of running out of key slots in the HSM. One good trick for this is "key wrapping"; you have one master symmetric key in the HSM, which you use to encrypt the keys you actually use. The flow would look something like this:

Encryption:

# fetch key_i from the DB and get the HSM to decrypt it.
DB ---ciphertext(key_i)--> App ---ciphertext(key_i)--> HSM ---key_i---> App

# encrypt the data and store it in the DB
App: encrypt(data, key_i) ---ciphertext---> DB

Decryption:

# fetch key_i from the DB and get the HSM to decrypt it
DB ---ciphertext(key_i)--> App ---ciphertext(key_i)--> HSM ---key_i---> App

# fetch the encrypted data from the DB
DB ---ciphertext---> App: decrypt(ciphertext, key_i)


Accessing a site (which is) under a DDoS

Many operators (most I hope) use back-door network connections, such as a modem through a terminal server at the site. There are lots of variations on this theme, but that's the easiest way to do it, and has the advantage of giving you access to your network if there's a network or hardware problem affecting your connectivity.

Another option is working with your ISP to shut down all traffic except traffic coming from your particular netblock or IP address; that's a simple change, and most tier-1 ISP's will be able to help you with this under emergency circumstances.

There are also commercial cleaning services like Verisign's DDoS prevention product that can divert all of the traffic, remove the DDoS traffic in particular, and send the result back to your network. This can be done via DNS or (better) BGP.

Finally, not all DDoS attacks are just packet cannons. If you're being attacked with something like an SSL resource exhaustion attack or one of a bunch of similar high-level attacks, your SSH connection into your webserver may still work just fine. Then again, it may not, if it's that server itself that's overloaded and spinning at 100% CPU. A solution to this problem is to get an SSL offload device and put it in front of your server(s). Planning a high-availability site like this takes some thought, but you will definitely get better results.


How dangerous is a virus introduced to a malicious website in chrome?

First you have to understand what a sandbox is. It is not like a virtual machine where the things running inside can do whatever they want. The Chrome sandbox controls access to the outside by providing a limited set of APIs with stricted parameters. Some Chrome sandboxed processes are not allowed to write to disk or display anything to screen.   What exactly they can do is controlled by an explicit policy.

Escaping a sandbox means doing things that are not specifically allowed by the sandbox.

Read more about Chrome's sandbox from the Chromium homepage and The Security Architecture of the Chromium Browser

You said:

  This would mean that the virus can only sneak passwords etc. in the
  tab (process) where the virus exists.

"Sneaking passwords" means that the exploit has access to memory and can execute code. That means it can do anything on the system. Read more about the concept of sandbox.

In the context of sandboxes, the closest thing you talk about is a partial sandbox escape where an exploit (the generalization of what you call a virus) for example, can read arbitrary memory of the process it is running under. This is still a vulnerability and it can be combined with other vulnerabilities to realize a full sandbox escape. Google will pay you money for a partial exploit.

  $60,000 - “Full Chrome exploit”: Chrome / Win7 local OS user account
  persistence using only bugs in Chrome itself.

  $40,000 - “Partial Chrome exploit”: Chrome / Win7 local OS user
  account persistence using at least one bug in Chrome itself, plus
  other bugs. For example, a WebKit bug combined with a Windows sandbox
  bug.

  $20,000 - “Consolation reward, Flash / Windows / other”: Chrome / Win7
  local OS user account persistence that does not use bugs in Chrome.

Flash is not completely sandboxed in Chrome, so some exploits can be contained by the sandbox while others not. The contained ones will not be allowed by the sandbox to access your sensitive data. The other ones will run free on your system.


SHA1 hash encoded with base64 results not consistent?

You've generating the base64 encoding of the ASCII hex string, rather than the raw bytes of the hash function's output.


Security of sending information to stdout

Really, stdout is just a unix pipe.  Essentially, it can keep some amount of the data in memory, and then blocks on input until the other end of the pipe is read from.  Often, this is the user's shell, which will read from the pipe and print to the user's terminal (or pseudo-terminal).  Of course, it can also be redirected to file output or to another program.

In the normal case, where the output is displayed on the user's terminal, the data is of course in memory, so if the memory is swapped to disk, it might be recoverable.  Also, if you have the running system, it might be possible to recover in-memory if it hasn't been overwritten yet.


As others have already noted, filtering by MAC doesn't work because MAC addresses are not routable, only IP adresses are.

Filtering by MAC address wouldn't really work, anyway, because MAC addresses can be easily spoofed (changed). I can give my computer the same MAC address yours has, and as long as they're not on the same network segment, everything continues working just fine, except that if there was a way to look at the MAC address of a request in a routed network, I'd now look just like you.

What you can do is filter IP addresses by IP address block. There are services that provide geolocation services based on IP addresses; usually whole blocks of IP addresses are assigned to specific institutions. So you could in theory lock out anyone from china by blocking all IPs registered to chinese internet providers, chinese firms etc.

This won't be foolproof, however, because a) the geolocation lists are never perfectly accurate and perfectly up to date, and b) there are services such as proxies, VPNs and anonymization networks which can hide the actual origin IP of a request.

You'll have a bit more success if you whitelist IP blocks. For example, if you want people at your school to have access to your network service, but nobody else, you can whitelist the IP block assigned to your school.

But again, you should only consider this a first step. It also doesn't allow you to grant access to individual persons; IP addresses for the most part can't be reliably tied to people.

So if you really want to only allow specific persons / computers into your network, you'll have to secure it with an authentication and authorization step. For example, you could set up your own VPN and hand out access credentials to only those people whom you want to be able to access it.


First, start by reading the answer to this question-> https://crypto.stackexchange.com/questions/18311/how-does-a-rolling-code-work
This answers your first two questions.  Also, the transmitter does not periodically send an RF signal, as what starts the authentication conversation is a key fob, not the car.  The only way to break out of the sequence would be to repeatedly press your fob while out of range of the car.

The sequence is generated from a psuedo-random number generator (there is no true random number generator) with a seed.  Each receiver and transmitter have different seeds, so one transmitter will no work for another, and vice versa.  Also, even if two receivers and transmitters have the same seed, they are most likely at different spots at the sequence, and thus (most likely) wouldn't be able to work with each other.  However, there are a multitude of attacks still possible, as shown here -> http://alrabady.com/images/Analysis_Keyless-entry.pdf (page 3)

This is what the rf signal looks like:
http://www.ni.com/white-paper/13192/en/
The numbers are sent, and also a little bit of other information.

The algorithm is not made to stop an attacker (A) from grabbing the numbers, but is made so that if and when A does grab the numbers, A can't do anything with them.  Proximity doesn't matter unless A is trying to do a jamming attack, as outlined by http://hackaday.com/2014/03/17/hacking-rolling-code-keyfobs/


Can clients visit my site, and spam socket.emit(something); to my server, or is there some security behind socket.io?

A bit of a loaded question really. However;

While that is a possibility, it is the nature of HTTP(S) & the WS(S) protocols. Making requests is just that, a request. In regards to the underlying question being posed regarding security...

For browser restrictions you are relying on the same origin policy, for injected content via MITM attack vectors you should utilize the wss (Web Socket Secrurity) protocol which would then leave you with the typical XSS attack vectors.

These can be mitigated by using a combination of the HTTP Security Headers implemented with the HTML5 specification and sanitizing your input and output which is best done with character encoding.


Malicious PHP code can run in cache. Solution?

The solution is to not cache like this. For a start, <? is only one of several ways to inject PHP, including <script language="PHP"> and <?php. Blacklists are always a bad idea.

Your caching system doesn't work in the first place in terms of performance because, by the time your PHP serving becomes a performance problem, your disk performance becomes a problem too. At that point you're not improving performance at all.

For proper caching, you want in-memory storage. Take a look at memcached (and the PHP module), APC, or an in-memory NoSQL solution like Redis. These are mature projects that were designed to do exactly what you're trying to do.


Creating a private key with OpenSSL and encrypting it with AES GCM

Updated Answer:

According to: https://groups.google.com/forum/#!msg/mailing.openssl.users/hGggWxfrZbA/unBfGlsfXyoJ the gcm support is currently broken in v1.0.1f (what Ubuntu currently uses). There should be patches out for Version v1.0.1.g which then should have a workable GCM mode. However, currently I would just stick with the CBC mode, as for key wrapping  it is fully supported from openssl genrsa and openssl genpkey

  Old Answer:

  According to the docu: https://www.openssl.org/docs/apps/ciphers.html

  AESGCM
  AES in Galois Counter Mode (GCM): these ciphersuites are only supported in TLS v1.2.

  The changelog of openssl for ubuntu states for a prior version:
  openssl (1.0.1e-4ubuntu2) trusty; urgency=low   * Re-enable full
  TLSv1.2 support (LP: #1257877)
      - debian/patches/tls12_workarounds.patch: disable patch to re-enable
        full TLSv1.2 support. Most problematic sites have been fixed now, and
        we really want proper TLSv1.2 support in an LTS. Currently I have installed 1.0.1f-1ubuntu9.1, so at least in theory it should
  work. But I can assure you, it does not. Maybe the modes are still
  considered broken, but I'm just assuming.


PCI server room on premises: how to handle office visitors?

A little late to this question, but just for the sake of this one having some sort of on-the-books "answer":

My read of 9.4 has always focused mainly on the 'visitor" element, as you imply.  And I think that the list of four common-sensical measures you offer are definitely good ones  But, keeping in mind the intent of the rule, let me suggest one more:  For all visitors who your office people have never seen before and cannot vouch for, get on the phone with the services who supposedly sent them (don't use any phone numbers they give; look them up online) to verify their identification, that they are an employee of the service, and that somebody in the office is expecting a visit from them. The impostor third-party contractor/worker who talks his or her way into the facility is sort of the main threat scenario the rule aims at.

But as the commenters wisely said, ask your QSA.


Why would password managers provide support for OTP codes?

Password managers want to also manage OTP because they're in the business of making authentication easier.
But there's a trade-off.
Managing OTP (or any other truly additional factors) in the same place as your passwords shifts the risk model. It pools multiple independent factors into a single attack surface. This turns the system(s) running the password manager into a higher-value target.
The increased risk may be acceptable for general users, but it is riskier for targeted / high-risk users. (The rest of my answer takes the high-risk users as the more interesting case.)
If OTP codes are stored on an independent device, by contrast, then compromise of the system(s) hosting the password manager (while still obviously bad) does not provide instant unfettered access to all accounts stored in the password manager.
Of course, a user can always check the "don't require OTP on this system" checkbox. High-risk users can skip that option, and require the OTP at every login. If they do so, then if they surf the web from their laptop but use a phone-based OTP app, an attacker must compromise both endpoints - the surfing system, and the phone - to authenticate as the target user on OTP-enabled websites. (Which is the fundamental value proposition of MFA.)
And it's important to remember that storing OTP in your password manager is not an "either/or" situation. Some users might choose to store low-value OTP codes in the password manager, and high-value OTP codes somewhere else. (Corollary: it would be great if the password managers could advise users about the trade-offs, so they can make informed risk decisions!)
Not storing OTP separately decreases the cost of (targeted) attack. But as always, whether or not that matters depends on your threat model.


Sounds like nothing big - DNS poisoning attacks and random other attack-like packets from the 'net are an every-day occurrence. I'm surprised your AV caught them though, unless it's a combined AV and firewall solution.

If the malware managed to run at all, however, your machine is compromised. Nuke it from orbit and start over. Now would be a good time to dust off your backups. You do have backups, right? ;)


JTR is not cracking XP SAM password(s), why?

It appears that John has cracked the Lan Manager (LM) hashes (the first parts) rather than the NT hashes (the second parts). As they are null in this case, there is nothing to crack and John has returned saying they are cracked.

You need to pass the --format=nt or --format=nt2 argument in order to crack the NT hashes.


Why can I log in to my Facebook account with a misspelled email/password?

Facebook is allowing you to make a handful of mistakes to ease the login process. A Facebook engineer explained the process at a conference. The gist of it is that Facebook will try various permutations of the input you submitted and see if they match the hash they have in their database.

For example, if your password is "myRealPassword!" but you submit "MYrEALpASSWORD!" (capslock on, shift inverting capslock). The submitted password obviously doesn't match what they have stored in their database. Rather than reject you flat out, Facebook tries to up the user experience by trying to "correct" a few common mistakes such as inserting a random character before or after, capitalizing (or not) the first character, or mistakenly using capslock. Facebook applies these filters one by one and checks the newly "corrected" password against what they have hashed in their database. If one of the permutations matches, Facebook assumes you simply made a small mistake and authorizes your session.

While worrying at first glance, this is actually still perfectly secure for a few reasons. First and foremost, Facebook is able to do this without storing the password in plaintext because they are transforming your provided (and untrusted) input from the form field and checking if it matches. Secondly, this isn't very helpful for someone trying to brute force the password because online attacks are nigh impossible thanks to rate limiting and captchas. Finally, the odds of an attacker/evil spouse knowing the text of your password and not the capitalization are abysmally small and so the risk created as a result of this feature is equally small.

Should you be worried? No, probably not.

Further reading: https://www.howtogeek.com/402761/facebook-fudges-your-password-for-your-convenience/


How can a rootkit infect Windows without signed driver file?

TL;DR: Privilege escalation or bypassing

Generally, these droppers will exploit bugs in the OS. While it should not be possible for this dropper to write into parts of the kernel, there are ways bugs allow them to do so. For example buffer overflows can be exploited to increase privileges to the point, where you can do almost anything.


Do incident response plans include playbooks?

The primary industry standard for playbooks is the Integrated Adaptive Cyber Defense (IACD) Research group, out of Maryland (John Hopkins).
These can constitute any type of cybersecurity response, at the event, alert, notable, or incident level -- for indications and indicators. Playbooks could be part of a CIRT (and therefore IR/DFIR planning), but they could also be part of other structures, such as Cyber Threat Intelligence, Threat Hunting, Security Operations, Security Engineering, Red Teaming, Cybersecurity Analytics, Cyber-Risk Management, and potentially many other specialty areas.
Playbooks are conditions, indicators, and controls that drive the need for cybersecurity responses [as] captured [via] orchestration services [for monitoring and execution].
Playbooks are process-oriented and:

Reflect an org's policies and procedures
List activities that may require human interaction
Made sharable from organization to organization

At the highest level of abstraction, playbooks are a set of process
oriented steps that enable an organization to meet the requirements
specified in their policies and procedures. They are a set of human
understandable actions that document an organizational process
performed in response to a cyber-event or other defined trigger
condition. Playbooks are meant to be generic enough for broad
applicability between organizations while detailed enough to meet
specific situations. Playbooks may invoke other playbooks, operate
either serially or in parallel, or initiate a workflow depending on
the situation or conditions facing the system.


How can I use WHOIS data for security purposes?

From a defensive point of view, the WHOIS database might tell you:

that you are exposing too much information about yourself in your own domain info (owners name, address, phone number, etc.)
how long domains have been registered so that you can use automated tools to block domains that are very young (and likely to be malicious if suddenly appearing in emails)
who to contact in the event that a legitimate domain is sending spam or hosting malicious content


Social security and bank account numbers in plain text in web app

There are 2 things here, them storing the data in a readable format and them showing you. They do need the data to be in a readable (by the program) format because it is needed to send people money and for tax reasons or to put on wage slips.

They should however not show you sensitive information that you don't need to see. If you wanted to you could use all that information for malicious activities. It is their responsibility to reduce the attack vectors without reducing functionality, giving you this info is making an unnecessary attack vector for little or no functionality.

The fact that the server farm is the same as the CIA means nothing. Its like saying that you live next to a police station so you wont get robbed. Additionally they should not know that they are in the same farm as the CIA because that now tells you one place the CIA have servers and that is info the CIA dont want anyone to know due to possible attacks against them. Lastly I wouldn't trust any government bodies with my data, most of the data breaches from whistle blowers are of data that the whistle blower should not have access to (Edward Snowden, Chelsea Manning, Harold Martin)


Can a website detect remote operation of a computer?

There is no API or simple test a website can perform to know if there is a remote desktop involved. So they easy answer is no.

But I would guess that your mouse movement and maybe also your typing is slightly different when using a remote desktop, due to lag. In the same way that Google reCAPTCHA uses mouse movement and typing data to differentiate humans from bots, it is concievable that you could spot a remote desktop user. But it would require training some sort of AI, and a lot of work, for no clear benefit.

So is it possible? In theory, maybe. Does it happend in practice? No.


You should read the wiki entry on Mask Attack.
In particular, you want custom charsets and the examples.  First, you define up to four custom character sets, -1 through -4.
Then, you put your mask together.  For each character position, you can use

a fixed character (19, in the first example, is a literal)
a standard charset, like ?a or ?l
a custom charset, like ?1 or ?2

command: -a 3 -1 ?l?u ?1?l?l?l?l?l19?d?d
keyspace: aaaaaa1900 - Zzzzzz1999

Or, with two of them (you can use up to four)

command: -a 3 -1 ?dabcdef -2 ?l?u ?1?1?2?2?2?2?2
keyspace: 00aaaaa - ffZZZZZ

Note that once you get much beyond 8, you need to use very restrictive masks (i.e. checking for date and phone number patterns), and then you need to start using rules-based dictionary attacks; start with common dictionaries and the rulesets that came with Hashcat, like Best64.


Doubt on Android permissions mapping with UIDs/GIDs

Things usually needs permission because the permission protects a shared resource. When there is shared resource in a Linux based system, that shared resource is usually assigned a name by the kernel as an object in the filesystem. For example, as regular file, Unix socket files, device files, or special files in sysfs/procfs. A lot of native system daemons in Android are represented as a socket in /dev/socket, and hardware device drivers represent themselves to userspace applications as device files. These sockets/device files are used by applications to talk with a native system daemon or a kernel driver.

The filesystem in a Linux (or any Unix-based system) is essentially a namespace that user space applications can use to refer to kernel objects, and the kernel enforces Unix file permission to control access to interact with these kernel objects. In Unix file permission, each objects in the filesystem belongs to exactly one Owner UID and Owner GID.

If you were to assign the permission object directly to the UID, then you would have needed to create one socket file for each user/application that needs to talk to the underlying shared resource. When you add more applications to the system and when the system is updated to add/remove a daemon, you'll need to recreate those socket/device files for each combination of system service and applications. This would have been clunky and error prone.

Instead, because permissions are assigned indirectly via GID, what happens is that multiple applications can all talk to the same socket file. The system daemon would only need to listen on one socket file, but only applications whose supplementary group includes the socket file's GID would be able to talk to that daemon or kernel driver. This file permission mechanism is enforced by the Linux kernel.

Note that the Android framework also contains a number of higher level permissions that are enforced by the permission system, at system applications level, rather than by the kernel. These application level permissions works differently than the kernel level permissions, they query the Android package manager and/or an application code to decide whether or not to grant permission. What's described in the previous paragraphs applies to permissions that are enforced at the kernel level, not these application level permissions.


How to effectively detect a rooted device on Android?

There is no general answer to this questions as this completely depends on the type of the rooting procedure used. This paper (WOOT workshop of USENIX security 2015) gives a nice overview of the different kinds of rooting procedures.

So if you want to implement a root checker, your chances are best if you can detect the majority of popular root methods.


Metasploit - Does the multi handler sends the payload, or just listens for connection

It depends. The exploit/multi/handler is more of a stub for whatever payload handler you need to run. So whichever payload you select (with set payload ...) is responsible for doing whatever it needs, just like if you were running it from a regular exploit module.

So yes, from a multi-handler, any of the following could happen:

A simple socket listener/connection, like netcat (for plain shell payloads)
A handler for stager payloads that uploads Meterpreter (for meterpreter/* payloads)
A handler for single-stage (stageless?) Meterpreter (for meterpreter_* payloads)


Cyber Security Training v. Cyber Security Education for Middle to High Schoolers

There is a big concern in the industry that there are not enough people to fill InfoSec employment needs and there is a push to try and attract students into these roles. So, when you say "should" there is a scope issue.

We, as an industry, need the kids who are interested to have their appetites "whet". Yes, there is a risk that they might use their knowledge for ill, but then they could also learn the same skills via YouTube. At least by having professionals doing the teaching, we can also pass on values and ethics (the "would you rather them learn this stuff on the street?" argument).

General Education is important to all students universally, but Tactics Training also has a place for those who are interested so that those kids can be guided to use that interest for good.


Why do Facebook and Microsoft make you enter a code when reseting a password?

As a countermeasure against phishing emails.

Such emails will look like legit email asking you to change or update your password, but their link will direct you to a false website (still looking as legit as possible, with URL such as micr0s0ft.com: here the letter 'O' was replaced by zeros '0', it looks like "microsoft.com" but it is not "microsoft.com") which will transmit your credential to malicious people.

By requiring you to copy-paste the code instead of clicking on a link, you will have to type Microsoft/Facebook address yourself in the URL bar (or use your usual favorite link), so you are sure that the address is genuine and that you are not being directed to a false website.


By default, Microsoft Office 2016* uses AES-256-CBC with 100000 rounds of SHA1 for password verification using a 16 byte salt. AES256 is currently considered the industry standard by many for symmetric encryption. SHA-1 isn't considered a very secure algorithm for password storage since it's a fast algorithm and can be accelerated massively using GPUs. However, since a 100000 iterations are used, this weakness is significantly mitigated (although it still isn'tanywhere near as good as a dedicated password hashing function like bcrypt/argon2), and if you use a strong password, it shouldn't matter either ways. So the cryptography used by Office 2016 is strong enough to be currently uncrackable provided a sufficiently strong password is used.
Does having strong encryption make Office a good choice for storing financial information?
Probably not. Word creates lots of temporary files when it opens a document which probably aren't encrypted. These files will usually be recoverable for some time even after they have been deleted and could easily leak the contents of your file unencrypted.

*Office 2013 uses AES-128 which is also secure


There appear to be two main defenses:

Detect application crashes. The Blind ROP attack works by repeatedly sending queries to the application-under-attack and observing which ones cause it to crash.  It is not at all stealthy: it can easily be detected by the number of application crashes it causes.  Therefore, a helpful part of a defense is to monitor application crashes, and if multiple crashes are seen, notify a sysadmin.  Sysadmins need to be aware that a high rate of crashes might indicate a potential Blind ROP attack.  Unfortunately, this provides only detection, not prevention.
Re-randomize whenever the application crashes. It would be more effective if we could configure our systems so that, whenever an application crashes, it is automatically re-randomized (i.e., so that the layout is re-randomized, using fresh randomness for ASLR).  Currently, ASLR re-uses the same randomness for an extended period; depending upon specifics of the operating system, new randomness is generated only after reboot or only periodically.  The Blind ROP attack exploits this: it relies upon the fact that it can send multiple requests to the application-under-attack, and each time the application crashes, it will be automatically restarted and will end up with the same address space layout (ASLR randomness won't be refreshed).  If we disrupt this assumption, we will disrupt the Blind ROP attack.

Unfortunately, there appear to be two issues with this defense:

Issue: It is not clear to me how to implement this defense on current platforms, or even whether it is possible to do so.  It appears that Linux and Mac OS X only re-randomize on each boot.
Issue: On Linux and Mac OS X, this defense won't work for server processes that fork worker processes; some extra something is needed to protect them.  The problem is that many servers are structured as a parent process, which forks a bunch of worker processes (children) to handle requests, and if a worker process (child) crashes or dies, the parent will fork a new one.  Now, suppose that there is a buffer overrun vulnerability in the code that handles requests.  The Blind ROP attack will repeatedly send a request that triggers a worker to crash, and the parent will fork a new worker.  Since the parent process never dies, it has the same address space layout throughout.  And, the way that fork works is that the child inherits the same address space layout as the parent.  Thus, no matter what you do, all workers will have the same address space layout, for the lifetime of the parent (e.g., until reboot or until the service is manually restarted by a sysadmin).  Thus, re-randomizing on each crash won't help protect this kind of server.  Windows doesn't have fork(), so it might get somewhat better protection against Blind ROP -- I'm not entirely clear on that.

Ultimately, it is not clear to me how to protect or harden forking servers against Blind ROP attacks, at least on platforms other than Windows.

There are some additional possible hardening measures that I wouldn't rely upon as the sole defense, but that might stop Blind ROP attacks in some cases:

Enable stack canaries. If your compiler doesn't automatically turn on stack canaries, set the appropriate compiler flags to make sure applications are compiled with stack canaries.  The Blind ROP attack as described in the published paper only works against stack overflows (buffer overrun vulnerabilities in stack-allocated buffers), and can in some cases be stopped by stack canaries.

If you are using gcc, you might want to enable strong stack protection, i.e., -fstack-protector-strong (details) -- or even -fstack-protector-all if you are paranoid (but this might have performance implications).

However, stack canaries have a significant limitation: they don't help protect forking server processes, as the canary will remain the same for all worker processes throughout the lifetime of the parent.  This is unfortunate.
Use load balancing, if convenient. If your load balancer sends each request to a different random server, and if you have enough back-end servers behind the load balancer that might help make Blind ROP harder.  The reason it might help is that each request goes to a different machine and thus a different instance of the application with a different memory layout (assuming you use stack canaries and full ASLR, i.e., PIE).  No guarantees, but it might help.
Use standard hardening measures. As always, compile with full ASLR (-fpie on Linux/gcc).  This won't stop Blind ROP, but it will prevent simpler attacks (and simpler variants of Blind ROP) from working.


ASP.Net usage of the Machine.config file

Is this fully safe to use and safe to store key values like this?

It is not a good idea to save your symmetric keys in a machine level config file. Main thing is , it can be accessed by any admin level user in your system and it is not private to your application only. This key in the config file is in plain text which is pretty bad in terms of security stand point.

Apart from that in a Web farm situation you need to replicate these keys in every host machine you are using. Hence, the key rotation and updates will also become a problem.

  If not what are the other alternatives we have ?

The best way to secure your symmetric keys in a server is by using a secure key store or a HSM ( Hardware Security Module).

Since you are using the .Net you can take  look at the Data Protection in .Net. If you are using the .Net Core the best way to deal with this is using the Data Protection API .

If you are deploying your application in a cloud environment like Azure, Then you can use Azure Key vault .

More Reading


How to protect Authentication API from a DDoS attacks?

Just use a CDN to deliver the webiste, that will be the best protection against a Distributed DOS attack.


OCSP, CRLs, crlset - Revocation Delivery and Attacks

I asked a question about CRL and OCSP yesterday and then read up on it and I for one came to the conclusion that there is no "perfect" solution at the moment.

In a perfect system the browser would verify the revocation status at the CA itself at least once EVERY session but for that to work every CA would need to create huge server clusters with great redundant connections spanning around the world to ensure minimal response times.

Because that's not really feasable (you can't expect every CA to create such a big infrastructure) OCSP stapling was created in the first place with the downsides you stated.

Google's crlset is basically something in between, it acts as a CRL-cache. The upside is that Google has a huge server infrastructure in place that is less prone to DoS attacks, so in theory this is a good thing. The downside is that you are reliant on Google with all the privacy concerns and other problems that come with it.

In my opinion certificates should include a "mandatory revocation check on every request" boolean field which forces the client to update the revocation status on every request.
So basically critical infrastructure and high security applications like banking sites always enforce an up-to-date revocation status at the start of every session and less critical sites just don't and opt for usability instead of (higher) security. Also users should have the option to set this individually for every site (just like cookie options etc.) unless it is enforced by the server (so deactivating it when the server enforces it shouldn't be possible).

This is as much a political thing than a technical, it needs regulation to get something like this in place.

But then again, the attack vector for this scenario is pretty slim in reality if you think about it. Because basically you have to first attack the server and corrupt the certificate (which should be very unlikely for high security applications) AND simultaniously DoS the root CA with a huge attack so nothing comes through and then use that small window to perform your attack, this is very, very unlikely and can be migitated even more if the nextUpdate period was even smaller (which it should be in high security environments).

So it's also a matter of "Who is responsible for the integrity of a server?" because when someone gets hold of your server's private key, the revocation status of your certificate isn't exactly the biggest problem you have but some one having root access to your server (or even worse getting your key without root access).


Unsafe sanitization? Is this code SQLi vulnerable?

Yes it is vulnerable. Depending on the input mechanism and the implementation I can simply append a UNION and continue the query to select additional data. I cannot give you an exact scenario without seeing the implementation and the query this string is concatenated with. Fact is that you allow input beyond the scope you will need or want.

Just use parameterized SQL, I'm sure VB supports adding parameters to your queries.

See this


best to have security implemented closest as possible to the data (...) in the database it is ideal.

Why?  What?  Where?  How?

No, the idea that you want to safeguard data has nothing to do with the data layer (e.g. database) in a layered application.  In the vast majority of cases that would a terribly bad thing to do.

The idea that you want to safeguard the data is the reasoning where you place the safeguards where the data is kept and processed in each layer of the application (including the database layer if the given data to be safeguarded lies there).  If any layer of your application that can perform data requests is compromised then it will bypass the safeguards in the lower layers.

For a simple example: if you have an application where the database access is protected with a password and the application layer stores and reuses that password on connections, then compromising your application layer is all it takes.

Addendum

A scenario where the idea that safeguards shall be close to the database  makes some sense is an application layer that can process encrypted data.  For example, where the data is stored encrypted in the database and operations that use this data are performed externally (e.g. in an HSM).


Bypassing CVE-2010-4478 (J-PAKE parameter validation) in OpenSSH 5.1

It's unlikely that the server actually supports J-PAKE - it has never been enabled in any shipped version of OpenSSH. I don't know of any OS distribution that enabled it either.

Unless the server's admin manually enabled it by setting an undocumented build-time preprocessor flag, then the server won't support it.

You can check by running "ssh -vvv user@host" and looking for a line:

debug1: Authentications that can continue: ...

And looking for "jpake" in the list.


Setting a limit on password recovery attempts

You're right that a cookie is a bad idea, but the approach itself is misguided.

The problem with these kinds of hard limits is that they make it easy for an attacker to create a DoS condition for the legitimate user, simply by putting in 10 incorrect email addresses. Even if you time-delay the attempts, the attacker can simply send a request every time the time limit lapses.

The way I'd implement it would be to time-limit the requests on a per-IP, per-account basis, with no delay after the first and second attempts, but increasing delays on consecutive attempts up to a limit of 45 seconds. Another useful measure would be to enforce 45 second delays on any request coming from an IP address that has seen more than 10 incorrect attempts in the last 15 minutes across any number of accounts, in order to protect against attacks that scan the entire list of usernames against a single known email address. I might also consider requiring a CAPTCHA after a certain number of failed attempts, to protect from automated attacks.

This provides the following benefits:

A legitimate client will always be able to use the feature (i.e. no DoS condition can be reached) as long as the attacker is using a different publicly-facing IP address.
A reasonable number of failed attempts can be performed without the user being hindered by lock-out mechanisms.
Both targeted attacks and low-hanging fruit attacks are hindered with minimal negative effects on legitimate users.
The worst-case scenario is that an attacker generates a DoS condition when on the same network as a legitimate user. Not exactly critical or likely.

This would involve storing failed attempts in a log on the server side, perhaps in a database table or in-memory cache.


It's really that insecure to have POP3 enabled in my gmail account?

If the password is strong, then there is no worry whatsoever.

POP3 does not open new ways for cracking passwords IF you use it sensibly, i.e. within SSL/TLS. Otherwise, depending on the underlying authentication mechanism, a hash of your password may transit on an unprotected connection (bad !), or maybe even the password itself (worse !).

A feature of POP is that the emails are removed from the gmail servers once you retrieved them, so:

you can no longer read them through the gmail Web interface;
you no longer benefit from the disk redundancy and automatic backups of the Google infrastructure;
you can read your emails locally even when deprived of an Internet connection.

Therefore, this is not only a problem of performance and brute-force attacks.


Wow, I am very unimpressed with that PyNaCl doc page that you linked to; Among other things, they don't explain what this nonce is being used for internally. That makes it hard to answer your question. That said, the example code has some comments that give some hints about what it's doing inside, so I think we can puzzle through it.
Usually, a "nonce" is a random string that you insert into the message before hashing / signing it to make the hash unique each time, and prevent replay attacks. You don't usually see nonces with encryption functions.
The actual documentation lists both encrypt and decrypt as follows:

encrypt(plaintext, nonce, encoder)
decrypt(ciphertext, nonce, encoder)

with no evidence that nonce or encoder are optional, and no explanation of why an encryption function needs a nonce, but then the example code goes and does this:
# Encrypt our message, it will be exactly 40 bytes longer than the
#  original message as it stores authentication information and nonce
#  alongside it.
encrypted = bob_box.encrypt(message, nonce)

...

# Decrypt our message, an exception will be raised if the encryption was
#   tampered with or there was otherwise an error.
plaintext = alice_box.decrypt(encrypted)

So:

It appears that both encrypt and decrypt can be used with 1 or 2 parameters missing. It would be nice if it explained exactly what the behaviour is in those cases, but no matter.

The nonce will be stored inside the ciphertext, so you shouldn't need to send it separately.

The comment "an exception will be raised if the encryption was tampered with" leads me to believe that the ciphertext is MACed, which would explain why they need a nonce - it's for the MAC hash.


Windows Server 2019: Add CHACHA20-POLY1305 ciphersuites for IIS

Below are snippets from the Microsoft Security blog post Taking Transport Layer Security (TLS) to the next level with TLS 1.3 (published August 20, 2020).

Transport Layer Security (TLS) 1.3 is now enabled by default on Windows 10 Insider Preview builds, starting with Build 20170...

TLS 1.3 now uses just 3 cipher suites, all with perfect forward secrecy (PFS), authenticated encryption and additional data (AEAD), and modern algorithms...

We highly recommend for developers to start testing TLS 1.3 in their applications and services. The streamlined list of supported cipher suites reduces complexity and guarantees certain security properties, such as forward secrecy (FS). These are the supported cipher suites in Windows TLS stack (Note: TLS_CHACHA20_POLY1305_SHA256 is disabled by default):

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256

The protocol enables encryption earlier in the handshake, providing better confidentiality and preventing interference from poorly designed middle boxes. TLS 1.3 encrypts the client certificate, so client identity remains private and renegotiation is not required for secure client authentication.

TLS 1.3 is enabled by default in IIS/HTTP.SYS.

TLS 1.3 support will also be added to .NET beginning with version 5.0.

For more information about TLS 1.3, refer to the Microsoft TLS 1.3 support reference.


Verify SAML Response is from a Trusted Source

The signature should validate against a key. You should have a corresponding key for any entity that you are exchanging data with. Unauthorized entities will not have keys, and the keyspace of any widely-accepted good cryptography protocol will make brute-forcing impossible.

From the wording of your question, I think you may wish to read up on the concept of digital signatures.


A firewall its self is not an ACL. Typical firewalls are simply a hardware appliance with various interfaces on it. Firewalls use ACLs to filter traffic. By configuring different rules in the ACL you change the behavior of the firewall.

Software firewalls do also exist (windows firewall) but the behavior is much the same. It still has its own ACL that allows or denies traffic based on source, destination, and port.


The best ways to persist the license client information in the database

You need a timestamping service.  The license server should track information about the client that ensures that the same client can not request a license more than once.  You can use any number of factors for this such as hard drive serial numbers, windows activation codes, etc.

When an evaluation license is issued, you can timestamp the key and have the application check against a clock to see if the license is still valid.  (Use an asymmetric algorithm on the license server to sign a timestamp and the information that identifies the computer.)  Note that they may still alter their local system time, so the best bet is to use an external clock.  Your client then simply needs to know the public key of the license server so that it can verify the start time and computer ID for the license are valid prior to launching.

Do not rely on security through obscurity.  Things like putting the values in an unmarked DB column, using symmetric encryption like AES or other such measures where the information to generate a license is stored on the client can easily be broken by doing a simple trace of the program's behavior to see what it accesses.  As soon as someone comes to what looks like an AES key or a license being loaded in to memory, they will know what it is.  This kind of thing is child's play for an experienced reverse engineer and will take a matter of minutes in most cases.

Instead, make sure that it doesn't do them any good to tamper with the license and deny them the ability to generate a valid license.  Use asymmetric algorithms (public/private key) so that only the server knows how to generate a license and all the client knows how to do is validate it.  Make sure that a time check is made against the signed timestamp in the license and that the license also contains a hard to fake identifier of the client machine so that it can't be used for more than one client.  That way, copying or modifying the license is very difficult.

At that point, the most successful attacks against your system will either be reverse engineering the code to disable the license check (doing it multiple times throughout your application will make that harder) or figuring out a way to fake the client identifier checks to make multiple computers look the same (or make the computer look different so another trial license can be obtained.)


Diagnosing possible svchost.exe thread on Windows 7

Spawning a shell usually means someone dropped a reverse-shell exploit into your process.

Do a memory dump of the process:

procdump -mp <processID>

This might lead to an unstable system, so save your work and close all apps first.

From there, you can load the dump into WinDbg and analyse it. However, this isn't a trivial process - even setting up WinDbg can be a pain if you've never done it before. If you can upload it somewhere (public dropbox?) I can probably take a look and discover what's going on.


Is there anything I can do about IDN homograph attacks?

My suggestion would be to use two-factor authentication. If you chose not to use two-factor auth I would suggest getting out of the authentication game and using "login in with *" where * is facebook/google/yahoo etc, this moves the burden of preventing fishing attacks to companies that have the money and resources to do it well.

See https://stackoverflow.com/questions/5087005/google-authenticator-available-as-a-public-service for an example of an easy and cheap second factor to use.

As a last resort you can use a two password scheme, also known as password plus secret question. Where the second password you only collect certain letters of the password, and which letters you collect change on each login e.g.:

Username: ......
Password: ......
3rd, 6th and 7th letter of secret word:
          3rd .. 6th .. 7th ..

This will increase the chances of the user noticing a fishing attack before the attacker has found enough information to login as the user.


proxy servers and restricted work computers

So if I understand correctly you can work from home, and that IP address is OK. You need to setup a VPN or SSH tunnel at home, through which you can connect to your work network. You probably need to buy a router or cheap server (older laptop) that can do this.

Can you set VPN on your work laptop? If so, you can connect to your home VPN and work from there. If you cannot setup VPN, you can setup a router that handles this, to which your work laptop connects. You should buy a separate router for this, connect only your laptop to it, so no other devices connect to your home VPN - which will resulting in a slow connection.

For work, do you use VPN? Then your laptop should setup the VPN connection to work, automatically using home VPN and possibly abroad VPN.

That means you have to handle two or even three VPN connections. I have no idea how that works, if that works, if the connection is stable and fast enough. Your home VPN should be very stable, ADSL or cable very fast, upload and download.

You may have to get professional support for this.