hey, do i smell history repeating itself? bots on irc used to be useful too, and then used for local flooding. only later did they become the botnets that they are today.

so, from automated playing when you are not around to keep stuff active (rings a bell?) to botnets that throw… privates at people.

http://www.boingboing.net/2006/12/21/second_life_griefers.html

worth a read. i always love when the real world and the virtual meet, whether by marriages or by physical world police taking complaints because “someone stole my weapon on world of worldcraft!!”

we do live in interesting times.

gadi evron,
ge@beyondsecurity.com.

a few months back i released a post on where i think anti-botnets technology is heading. now it’s time for what happened in 2006, and what we can expect from here on.

i am not a believer in such retrospective looks, as often, they are completely biased and based on what we have seen and what we want to see. this is why i will try and limit myself to what we know happens and is likely to get attention, as well as what we have seen tried by bad guys, which is working for them enough to take to the next level.

what changed with botnets in 2006:

1.botnets reached a level where it is unclear today what parts of the internet are not compromised to an extent. count by clean rather than infected.
2. botnets have become the most significant platform from which virtually any type of online attack and crime are launched. botnets equal an online infrastructure for abusive or criminal activity online.
3. in the past year, botnets have become mainstream. from a not existent field even in the professional realm up to a few years ago, where attacks were happening constantly reagrdless, it has turned to the main buzzword and occupation of the security industry today, directly and indirectly.
4. websites have returned to being one the most significant form of infection for building botnets, which hadn’t been the case since the late 90s.
5. botnets have become the moving force behind organized crime online, with a low-risk high-profit calculation.
6. new technologies are finally being introduced, moving the botnet controllers from using just (or mainly) irc to more advanced c&c (command and control) channels such as p2p, or multi-layered, such as dns and irc on the osi model.
7. botnets used to be a game of quantity. today, when quantity is assured, quality is becoming a high concern for botnet controllers, both in type of bot as well as in abilities.

what’s going to happen with botnets in 2007:

botnets won’t change. all will remain the same as it has been for years. awareness however, will increase making the problem appear larger and larger, perhaps approaching its real scale. the bad guys would utilize their infrastructure to get more out of the bots (quality once quantity is here) and be able to do more than just steal cash. maximizing their revenue.

further, more and more attackers unrelated to the botnet controllers will make use of already compromised systems and existing botnets to gain access to networks, to facilitate anything from corporate espionage and intelligence gathering, to shame-less and open show of strength to those who oppose them (think blue security), in the real world as well as the cyber one (which to the mob is one and the same, it’s the income that speaks).

meaning, the existing botnets infrastructure will be utilized both in an open fashion, due to the fact online miscreants (real-world mob) face virtually no risk, as well as quiet and secretive uses for third-party intelligence operations.

gadi evron,
ge@beyondsecurity.com.

Bogus hotspots aka ‘Evil Twins’ was found in the first class lounge of an international airport, and in garages that specialise in expensive cars that offered Wi-Fi while you wait, reports Iain Thomson of Vnunet.

The article defines the evil twin like this:

So called ‘evil twin’ attacks involve putting a wireless access point near a commercial hotspot and giving it the same name.

The company interviewed by the reporter sees this threat as ‘Wireless phishing‘.

This The Guardian article is quite confusing:

A [Manchester] man who used MP3 players to bug cash machines and steal the personal details of unsuspecting bank customers has been jailed for 32 months.

The report continues that 41 years old man and his team attached MP3 players to the backs of _free-standing_ cash machines in bars and bingo halls etc.

The data they recorded was the sound familiar from acoustically coupled modems and when you call to fax machine phone line!

The team had a special software for decoding the tones to readable information. It is easy to guess – yes, they cloned several credit cards with this mean.

So-called Budapest Declaration on Machine Readable Travel Documents has been released by FIDIS – “Future of Identity in the Information Society” recently.

It is worth of reading in days of these RFID threats.

Link: www.fidis.net/press-events/press-releases/budapest-declaration/

In this declaration, researchers on Identity and Identity Management (supported by a unanimous move in the September 2006 Budapest meeting of the FIDIS “Future of Identity in the Information Society” Network of Excellence[1]) summarise findings from an analysis of MRTDs and recommend corrective measures which need to be adopted by stakeholders in governments and industry to ameliorate outstanding issues.

Sitting at a security conference in Boston, I wrote down a quick and dirty script that just listen for ARP requests and responds to any such requests with … Hay That is Me ™ … The things you can find using that… here is a summary:

1) SNMP community names
2) SMB keypairs (you need to use fakesmb)
3) DNS queries (if you answer them it is even more fun)
4) HTTP requests for odd stuff (once you answered the DNS queries, and have set Apache to answer incoming connections you are all set)

I am sure a lot more can be done… I will leave it to your imagination

#!/usr/bin/perl
# Writen by Noam Rathaus, Beyond Security (r)

use Net::Pcap;

my $Interface = “eth1″;
(more…)

Mr. Adam Laurie, UK has recently posted the demonstration code (Python) which

…will exchange crypto keys with the passport and read and
display the contents therein, including the facial image and the
personal data printed in the passport. Currently the data read is
limited to the following objects:

…..

Project site www.rfidiot.org (it stands for “RFID IO tools“) has other RFID passport related material as well.

This week with reported vulnerabilities in First-Generation RFID enabled credit cards is not good news to RFID technology! These NBC Today video and YouTube demonstration video show the skimming attack etc.

I’m not saying “Enjoy!”, I’m saying “Be careful!”

As reported on Bugtraq list last Friday:

However, it seems that the encryption keys are hardcoded directly in the EXE file. So, they are easily recoverable and all these CFG files can be easily compromised.

This case is related to encryption level of configuration files (.CFG) when installing several workstations at the same time with centralised management tools. SafeGuard Easy is for encrypting hard drives.
Company’s response entitled as Statement on SafeGuard Easy Articles regarding Configuration File Vulnerability is located here [2-p PDF]:
(more…)

in the public hacking world, so far we have mostly seen usb technology from security vendors… not the attackers side.

a few years ago we had discussions on pen-test, and later bugtraq and fd on these risks, following an article in 2600 and a post from me on the risks digest. on pen-test, harlan carvey and others also followed up.
since then there have been multiple threads everywhere. this was not new back then, either, imo.

back then i mainly addressed the risk of driver attacks (now more acknowledged since blackhat 2005 and blackhat 2006 presentations on the subject appeared), and didn’t get much attention. hackers did not know usb technology that well and most did not see what the heck drivers had to do with it.

what did come up were the risks of autorun technology (which is a simple solution to making usb devices execute code). these were not as easy as they first appeared, and did not work if windows xp’s screen saver was active. still, things were interesting and my fav quote of: the janitor is the richest person in the organization, got some interest.

today, with several usb buffer overflow discovered (mostly in the linux kernel) and driver attacks getting more attention, i came across the following blog entry by xavier ashe.

in his blog he discusses a usb autorun technology which is actually an hacking tool, (more…)

dd had a nice post today by halvar on an atm fraud:
http://home.hamptonroads.com/stories/story.cfm?story=110889&ran=223062

according to a nathan landon who provided with more details:

they showed it on the news here in virginia. they have security camera footage of the guy who they believe is the perpetrator trying to pull out $250 and getting $1000. he did this twice apparently. he doesn’t look like the “engineer” type. they reported that he was able to turn on the glitch through a series of entered numbers. doubtful he knew what he was doing otherwise he could have turned it off between attempts. (more…)

Things are going on related to new biometric e-passports. This news published recently is worth of checking:

…group of security experts says the American passports could be used as potential bomb triggers.

There is a summary, technical analysis [PDF] and video “RFID Passport Shield Failure Demo” of 4min 28sec available from firm Flexilis.

We have switched to new biometric passport [picture] here in Finland today. Although The Ministry of the Interior declares that the case mentioned (passport about a half inch open) is not related to Finnish version of passports I have not so safety feeling…

In IT security we often borrow ideas, theories and experience from the physical security world. In this case, I’d like to give the airport security people some advice from the IT security world. Guys, whoever told you security and usability were opposites was wrong. Dangerously wrong. Whenever security comes without usability, whenever you put in place a device or procedure that makes it harder for your users to do what they’re trying to do, you are more likely to be weakening your overall security rather than strengthening it.

In the 1980s password policies were all the rage. We were trying to prevent attackers from guessing legitimate users’ passwords, and since we couldn’t trust the users to choose strong passwords by themselves we put in place programs that checked the passwords strength and prevented users from choosing ‘weak’ passwords.

But users couldn’t be bothered to remember those passwords, and so attackers learned that the password to the payroll system is either on a post-it note on the monitor or in the top desk drawer. Other users were smarter than us – no matter what password policy we set in place, there was a simple password strategy that conformed with this policy. Non-dictionary word? qwerty. Non-dictionary with numbers? qwerty1. At least 8 characters? qwerty123.

And the fight goes on: Force to change every month? Fine, qwerty128 (8 for August). This went on for about a decade – and eventually the users won. So we introduced biometric identification, smart cards, USB tokens and other devices that made it easier for our users to login, yet made our systems more secure. Wait – this made our systems more secure because it was easier for our users to login.

In the 1970s, programmers would connect with desktop terminals to the mainframe computer. Having natural urges, they would sometimes leave their terminal and come back after a few minutes. To prevent someone from ‘stealing’ their terminal while it’s logged in, the server would detect inactivity and log off the terminal. But programmers hate it when they’re in the middle of writing their COBOL program and as they come back from the bathroom (or lunch) they need to log in again, open the editor and find the line they were working on. Programmers are also smart – so they programmed programs to generate fake activity that prevented being logged out.
The solution came in the form of screen savers – rather than logging off the terminal, just lock it. When the programmers come back, all they has to do is type the password and they’re right where they left.
A little more than a decade later, this screen saver shows magnificent flying toasters. Suddenly it’s a great feature – and both the users and the security people are happy.

As we pat ourselves on the back users begin to realize that if John left work and Alice wants to use his (now vacant) station, she can’t – because it’s locked. Suddenly, the whole department is using pa$$word123 as their personal passwords, so that others can use their stations when they’re away. Sooner than we think this ‘policy’ becomes a part of new employee training. The users are happy, but the security people are going nuts – everyone on the department is using the same passwords, and those passwords are common knowledge (yet they beat our password policy enforcement rules).
All this work for personal home directories and ACLs is down the drain. Users can log into other accounts at will, and Authorization, Authentication and Accounting may be shortened by experts to AAA but is also shortened by our users to no more than an F.

Luckily, the desktop ‘switching’ feature is introduced and makes it possible for two people to share the same PC without knowing each other’s passwords. Some people will call this a ‘usability feature’, but I would call it a ‘security feature’. We’d both be right – there’s simply no contradiction.

Back to airport security. Bruce Schneier wrote a great analysis once on how El-Al airlines does passenger questioning. I fly El-Al a lot and I noticed something else, too – when the airline security person finds a cynic frequent flyer like me, someone who has heard the question “did you pack the luggage yourself” maybe hundreds of times, they stop the questions and say: “you know why I’m asking all these questions, right? It’s because…”. Their voice is not reprimanding. They are clearly trying to invoke my sympathy. They always succeed – I get the feeling that they’re here to assist me, not to obstruct. That we’re all on the same side. That they give me enough credit as a thinking person to clue me in on why they’re doing this. Actually, they are recruiting me to help them find terrorists by helping them eliminate me as a possible terrorist. Sure, I’ll help out!

Most TSA workers are courteous and polite. But they do not invoke my sympathy. By taking passengers’ water bottles and forcing us to take off our shoes they make the passengers hostile, and this in turn makes their job even harder. Now they have to deal with hostile passengers and long queues (that make the passengers even more hostile) rather than focus on finding suspicious people or potentially dangerous carry ons.
These hostile passengers, unlike the programmers from the 70s, are unlikely to try and purposely circumvent the security measures. For example, I doubt that anyone will be trying to intentionally smuggle water bottles on board. But I’m also sure that for many people seeing someone else sneaking a gel tube or a coke can onboard won’t make them call the TSA. They will probably get that feeling you get when you see someone ‘beat the system’ – the same way the person that figures out a way to beat the password policy feels.

Antagonizing your users is not a good idea. Next time someone tells you that security and usability are on two opposites, tell them that the corollary is that ordinary users who want to use the system are the enemies of the security people who try to limit this usage – and that’s probably not a good conclusion.

as predicted in our circles last year, here is a documented vishing case. the wave file does not have a heavy russian accent attached, but it is interesting.

considering this bank also handles some tax refund issues, one would expect the irs to also take an interest in this.

today from dan hubbard at websense and our friends at castlecops pirt:

websense� security labs™ has received reports of a new phishing attack that targets customers of santa barbara bank & trust. users receive an email message that is spoofed and has the subject “message 156984 client’s details confirmation (santa barbara bank & trust).”

unlike the most popular form of phishing where users are lured to click on a url and are directed to a fraudulent site, this lure uses a telephone number. the phone number is in the southern california area code and was answering at the time of this alert.

when victims dial the phone number, the recording requests that they enter their account number.

the phone response does not mention the bank name, which could be a potential indicator that this number is being used for fraud against other entities.

the vishing recording can be found here:
http://www.websense.com/securitylabs/images/alerts/june_vishing.wav

the actual phishing email with the number:

dear customer,

we’ve noticed that you experienced trouble logging into santa barbara bank & trust online banking.

after three unsuccessful attempts to access your account, your santa barbara bank & trust online profile has been locked. this has been done to secure your accounts and to protect your private information. santa barbara bank & trust is committed to make sure that your online transactions are secure.

call this phone number (1-805-xxx-xxxx) to verify your account and your identity.

sincerely,
santa barbara bank & trust inc.
online customer service

gadi evron,
ge@beyondsecurity.com.

us based folks may be more interested in the privacy implications of the recent at&t/nsa “gate”. i am too, but what interests me even more is the detailed technology disclosed on how at&t implemented sniffing on fiber optics, how isp’s handle the logistics of answering the legal call of wiretap needs, as well as analyzing possible security fail points in the nsa’s operation (if indeed it was theirs).

why the nsa did good
it’s been known for years that listening to optical lines is possible. it has been known for years the nsa listens to the internet. it has been known for years that much of the internet’s backbone sits in the us and at&t is a big part of that. it’s been known that us citizens also use the internet.

no one really wrote about how listening to optical lines is possible until now, or how, but my most serious reply to that is carbon-copied from a friend: duh.

how else did the american citizens expect the nsa to do this? there are naturally other ways which we will not discuss today, but the backbone sits on american soil, are you telling me the nsa should not use it? that is just plain silly.

the nsa’s mandate as far as i understand it, especially after the 70′s fiasco’s, is sigint on everything except us citizens/companies/etc. i bet it is very difficult to filter out such possible domestic communication, but that is why they have such brilliant minds working for them. which brings us to the fbi and carnivore -

why the fbi f*cked up working with isp’s
i should probably point out that if i was a major isp often asked to answer the call of law enforcement with legal wiretaps, this could be very annoying as well as technologically a killer to my network architecture.
just sticking some hub somewhere in my network may not cut it, and will certainly not cover all of the communication. what about different lines and locations?

as a large provider, at&t probably had to find better solutions to the call of the law, or reply on the law’s technology to not kill their business.

this indeed happened before. according to one nanoger at the fbi’s carnivore presentation a few years ago, “sticking” just such a hub is what caused his network to break-down.

creating a centralized wiretapping point under strict security may be just the thing to both comply and save costs, not to mention staying on the air.

the technology
unlike with copper lines where you can use the em emissions to “listen in” to the lines, or even cut them in half and connect them to a sniffer, with fiber optics you simply can’t. as you must be aware of, optical lines work by “transmitting” light. in order to listen in on that communication one must somehow see some of that light.
without going too much into how this actually works, the protocols using this layer-1 and layer-2 optical hardware beams a lot of redundant light, which bounces off the “walls” in different directions in the tube until at least one of the beams in the data stream reaches the next repeater/switching point/routing point. a single sustained beam of light is often used in bigger pipes, but these also have a lot of redundancy.

being able to use one photon for each bit of data is what everyone wants to do, but isn’t happening quite yet outside the lab. this would get even more interesting in the future with quantum cryptography.

in this paper released by wired detailing the spying operation from the perspective of an at&t employee, there are also a couple of other papers attached which detail the network architecture at&t used to enable sniffing of the information, as well as some interesting information from a related “legal wiretapping” technology conference, iss world.

operational f*k-ups?
ignoring the privacy and us legal issues for a moment, the nsa does not seem that stupid to me, as to trust the operation and technology to be developed by a third-party localized organization.
my guess is that at&t was asked to prepare the infrastructure where the nsa could use their own gear from. perhaps even under certain guidelines, conditions and rules (such as even security clearance for employees and key-pad combination locks, as the paper mentions).

writing a paper about it so that it can be recreated seems like a good idea.

a security issue which comes to mind here is how the information was handled. this reminds me of an incident in israel where ibm was contracted to do a certain job with the arrow anti-missile project, and some of the code in the system was legacy code which was originally developed in the egypt ibm office. this was a serious security concern in the israeli military industry, and was the result of lack of supervision over third-party contractors.

i don’t see “top secret” on the at&t document, which would at least mean this was meant to stay quiet. if it was, than at&t obviously wasn’t very much following the nsa’s wishes on security. we do see on some of the pages “at&t proprietary” and “use pursuant to company instructions”.

on the physical security level the “secret” room used for the spying seems to be somewhat in paranoid security mode with quite a bit of physical security measurements, probably by nsa decree… therefore i don’t know where the security breach occurred, but was this document supposed to be released? if not, who is at fault? at&t, the nsa or a traitor?

maybe non of the above. this doesn’t seem like a security breach to me.

i tend to believe this information was not a secret, but just a technical solution to a business problem with complying to a potentially hazardous technical requirement by the law.

it is possible although unlikely that the nsa decided the existence of the physical wiretap was not a secret (hey, congressional hearing?), nor was the fact that fiber optics can be sniffed. if that is the case i see no security implications here either.
however, if everything but the existence of the room was to be a secret, from what happens there (physical wiretapping for sigint purposes) to how (breaking the optical line), security was indeed breached.

was this breach critical? not in the slightest.

i doubt the nsa as a serious western intelligence organization, as well as a secretive one would want even that known. still, we don’t know what their technology to gather the data was, how the information was processed, how and where it was saved and where it was relayed to. then we don’t know which of it was actually seen by a human. we don’t know what their interest was, except a vague indication of “terrorism”.

seems like this was run smoothly after all, and we, due to lack of information, run to make the wrong conclusions.

my opinion
privacy implications.. what exactly was done with the wiretap, etc. we don’t know. it is far from me to even guess. it is well within the realm of possibility it was all used legally, but the infrastructure needed to exist for that. i am sure the different investigation bodies who will look into it will come to some sort of conclusions and find some scape-goats if indeed something evil was done.
they will probably even look into better monitoring of what the nsa does (i.e. more people in the know).

i don’t know much about the particulars of this case, nor what president bush instructed. that is for the high-paranoia privacy guys in the us to find out.

i doubt the nsa, fbi and others on their own have any reason to spy on or allow spying of us citizens and/or businesses. than again, i am not a us citizen, what do i know?

i know about logistics with network service providers, the business need to stay on the air and the problems of complying to such requests. i also know such wiretapping is possible and i know that the backbone sits on us soil.

what else do i need to know except that every other country in the world tries the same thing? well, that the internet is not a secure medium and people need to secure themselves. surprise people show sometimes shocks me.

gadi evron,
ge@beyondsecurity.com.

TechDirt reports that:

Last summer, the surprising news came out that Japanese nuclear secrets leaked out, after a contractor was allowed to connect his personal virus-infested computer to the network at a nuclear power plant. The contractor had a file sharing app on his laptop as well, and suddenly nuclear secrets were available to plenty of kids just trying to download the latest hit single. It’s only taken about nine months for the government to come up with its suggestion on how to prevent future leaks of this nature: begging all Japanese citizens not to use file sharing systems — so that the next time this happens, there won’t be anyone on the network to download such documents. Beyond the fact that this is unlikely to have any effect (at all) on file sharing in Japan, it has nothing to do with the actual security breach. It wasn’t the use of a file sharing system that was to blame here, but the security setup that allows an outside contractor to hook up his personal computer to the power plant’s network without doing any kind of security check whatsoever to see if (a) his computer has malware or (b) his computer has file sharing software — while leaving top secret documents available for his computer to access. If this is how government officials react to such leaks (taking forever and completely missing the root cause of the problem, while suggesting a solution that is impossible to implement), it’s almost amazing that such leaks didn’t happen sooner.

Why is this important enough to get mentioned here? because of Japanese government’s reaction was to ask (beg) people not to use P2P, instead of preventing from P2P from working from the inside of sensitive institute, such as any place that has information on the nuclear arsenal of Japan, or even further, make sure that any laptop getting connected to such a sensitive network would have to be hardened and confirmed to not have anything that can be a potently problem.

Conclusion:

• Any laptop connecting to the network has to be scanned for malware and viruses
• Any laptop connecting to the network has to be scanned for vulnerabilities (i.e. security patches)
• Any laptop connecting to the network has to be scanned for unwanted software (i.e. P2P and similar)

Any laptop that fails any of these, should not be allowed to access the network resources.

What’s the connection between Microsoft, Intel and AMD?
The answer is that they are all trying to control code execution, such as the type done by exploiting a buffer overflow or a format string vulnerability.

While I do not think that this should be implemented in the OS, it might have been a good idea to implement it on the CPU level.

But there is another way to solve most of the buffer overflows from happening without involving any hardware or operating system in the middle.

The most common problem that causes buffer overflow related problems, is the use of a specific programming language and specific syntax.
That is, most problems in the security world today still happen because someone was “smart” enough to use the C programming language to do something that resulted in a security risk or just a simple bug.

Sure this is the “standard” today, but it does not mean that it’s a good standard.
I keep saying that the use of C is problematic for many years now, and in return I hear many nice explanation why it is not a good idea to stop using the language.

Sure it is the most widely used language out there, and it became a standard, but the language and language structure (syntax) is so bad, that we see on a daily basis new languages that try to fix it without any real success.

Lets see few problems with the C language (and Syntax):

What do you think about the following code ?

if (1== number)
{
  printf (“And the winner is: %s”, winner);
}

Here we use 1== number because if we used number==1 and forget one “=”, we will place a value into the variable number, and therefor we will have a bug, and maybe a security risk (off by x, limit check, etc..).

Here is another common code in C:

  char dest [10];
  char src [12]
  strcpy (dest, src);

And we have a buffer overflow on our hands !

But these two problems are very easy to solve (for expert developers).

So how about some real problematic code, that even expert developers may not notice that it happens, and most of you never thought it is possible to do:

memcpy (src ,(*)letsExecuteOurBufferContent, size);

Do you know what this code does ? Other then using memcpy in a wrong manner, it just opened a back door on a machine that used this code. Yup, all I need to do in C to make it a security risk is to use two variables, and one function!
Yes I know that it is possible to do it in other languages as well, but in C this type of code is so common, that many experts will look at it and still will not see the problem in front of their eyes, while on other languages, it might cause a big red light bulb to glow even by the average developer, even if the vulnerability itself is not noticed.

The problems with C are so bad, that even when it is used to compile an interpretor for other languages (and most of the interpreters out there have been written in C/C++) it may create bugs on the byte code/compiled result of what the user have created.

Just take a look at Perl as one of many examples:
http://www.securiteam.com/unixfocus/5QP0I15EUK.html
http://www.securiteam.com/securityreviews/6D0042AEUQ.html

Or what about issues with the Java Virtual Machine ? We can even create a Java code that will cause our VM to execute arbitrary code just because it was written in C:
http://www.securiteam.com/windowsntfocus/5DP0G0K8BI.html
http://www.securiteam.com/windowsntfocus/5RP0L0U8AS.html
http://www.securiteam.com/securitynews/5LP0L0U2AQ.html
http://www.securiteam.com/exploits/6L00S2A8KC.html
http://www.securiteam.com/windowsntfocus/5LP0P0K8AI.html

And still we didn’t even scratch the surface of the problem.

Many times there is a code that you need to write in C that look so bad that even using AT&T/INTEL based assembler syntax looks so much clearer and easier to use all of the sudden.

Many times you need to find yourself writing so much code just because you used C/C++, and when you start writing too much code, you start having bugs (the urban legend claims that on every line of code there is at least one bug waiting to surface!)

And many other times “ANSI C” is not portable at all between compilers, so we can experience a lot of problems from data swapping between parameters (thats a security risk BTW!), continuing between code that is unable to be compiled (the best thing we can expect from such problem), DoS condition, or other missbehavior of the program.

And if the above isn’t bad enough, many C/C++ programs out there arrive with some debug information inside, because there are bugs the programmer was unable to locate without a debugger, but to use a debugger you need debug information, but then you find out that things are acting a bit different on the version without the debug information, so you ship the version with the debug information.

So with all of the above problems, and with almost all of the programs and OS’s out there using C, how can you sleep well at night ?!

So lets stay away from C and find better language. TY.